Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
we encountered a problem where 2 Threads simultaneously execute:
Task.Factory.StartNew(() => new NSObject().BeginInvokeOnMainThread(...));
What we experience is that the App freezes and the system constantly spawns new Threads (what might be the cause for the freezing). The error is reproducible on the iPhone-Simulator with the attached project. In our real life App the crash is causeb by two web requests which respond simultaneously.
We have a workaround for the problem by using a Mutex, but that only solves the symptom and not the cause of the problem.
Perhaps there is also an error or knowledge gap on our side and there is a reasonable explanation for the behavior. So don´t hesitate to tell us if we are wrong.
Created attachment 4276 [details]
Test project to reproduce the issue
I tried the sample and quickly had over 120 threads running.
Marek, is that normal?
The app starts new tasks in a loop. So you can have up to 400 threads running, that's default ThreadPool limit. It should however reuse existing native threads instead of creating new one every time. How did you detect it's creating a new native thread constantly ?
What is the crash you are getting. That sounds more like some missing locking.
Rolf, 120 is good our GC is getting better ;-)
We experienced this behaviour in our App when two Web-Requests triggered their OnResponse-Handler simultaneously. That happens not very often but it is a valid scenario. On the Output-View in Xamarin-Studio we see something like this:
Thread started: <Thread Pool> #xx
where xx counts up very quickly until the App crashes. I will provide a dump of the console output as soon as I can reproduce it in real life.
This behaviour starts exactly after two web requests tried to access the UI-Thread simultaneously (as is simulated in the test project). We do not lock the threads at all since they are only accessing local variables. To post the task to the UI-Thread we use:
new NSObject().BeginInvokeOnMainThread(() => ...)
But the UI-Thread never executes the delegate then (we tried to hit breakpoints in there and also used console output). The system hangs while the thread spawning takes place so the UI-Thread seems to be busy with doing something but it seems that it is not executing our delegates.
We assume that the crash happens since the system is running out of handles for the new threads.
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?
If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
From our point of view we provided all necessary info to reproduce the problem.
I can still reproduce an issue: threads aren't reused, the thread count just goes up and up. I determined this by running the app in the simulator and looking at the Application Output, where threads will be listed when they're created and when they finish: https://gist.github.com/rolfbjarne/8e50ffff2e258b0050a4
The supplied sample is not longer valid. Was the bug fix, if not, please let me know and will reopen it.
We have not received the requested information that Manuel requested. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!