Bug 2866 - sdb fails to suspend threads on iOS
Summary: sdb fails to suspend threads on iOS
Alias: None
Product: Runtime
Classification: Mono
Component: Debugger ()
Version: unspecified
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Zoltan Varga
Depends on:
Reported: 2012-01-12 11:39 UTC by Sergio Fadda
Modified: 2014-11-10 05:04 UTC (History)
6 users (show)

Is this bug a regression?: ---
Last known good build:

MonoDevelop project w/ test case (6.12 KB, application/x-zip)
2012-01-12 11:39 UTC, Sergio Fadda
Same project with class-level NSOperationQueue (8.59 KB, application/octet-stream)
2012-01-16 16:07 UTC, Jeffrey Stedfast
gdb backtrace of running app (9.10 KB, text/plain)
2012-01-16 16:08 UTC, Jeffrey Stedfast
debugger log file (17.75 KB, text/plain)
2012-01-23 06:02 UTC, Zoltan Varga

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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 GitHub or Developer Community 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.

Related Links:

Description Sergio Fadda 2012-01-12 11:39:55 UTC
Created attachment 1174 [details]
MonoDevelop project w/ test case

I don't know if this is an issue of MT or MD, however... 
In the project I'm working on I use NSBlockOperation and NSOperationQueue to handle user input events; one of the action is to start a new thread that manage the HTTP communication layer. 
When I try to set up a breakpoint after the communication thread is started, it looks like the MD catch the breakpoint (the application freezes), but MD does not take the control. 
After various inspection I finally found the trick: if the thread is created and started inside the thread created by NSOperationQueue the issue can be replicated; but if the NSBlockOperation's body is wrapped inside the InvokeOkMainThread (creating and starting the communication thread inside the UI thread) everything works right! 

Is this an issue? Who's responsible of this: MD or MT? 

Anyway, the program works fine if no breakpoint is set up. 

P.S. After the issue is "activated" any breakpoint in any position freeze MD.

Thank you

Comment 1 Sergio Fadda 2012-01-12 12:47:15 UTC
I forgot: the issue seems to be activated when calling GetResponse of HttpWebRequest... actually in my project I use the POST HTTP method and the issue appear when I call GetRequestStream... I don't know if this is usefull.

Thanks again

Comment 2 Jeffrey Stedfast 2012-01-13 17:13:12 UTC
Where do I need to put the breakpoint to make this happen?
Comment 3 Sergio Fadda 2012-01-14 06:49:42 UTC
In the test case I've attached, the program works right; first you have to change the following lines of code:

		void HandleBtnTouchUpInside (object sender, EventArgs e)
			NSOperationQueue queue = new NSOperationQueue();
			queue.AddOperation(() => {
				InvokeOnMainThread(() => {
					// If this code is outside the InvokeOnMainThread,
					// MD hangs up when catch a breakpoint
					Thread thread = new Thread(ThreadProc);


		void HandleBtnTouchUpInside (object sender, EventArgs e)
			NSOperationQueue queue = new NSOperationQueue();
			queue.AddOperation(() => {
				//InvokeOnMainThread(() => {
					// If this code is outside the InvokeOnMainThread,
					// MD hangs up when catch a breakpoint
					Thread thread = new Thread(ThreadProc);

Put a breakpoint to the GetResponse call and make a step: MD should freeze.
Comment 4 Jeffrey Stedfast 2012-01-16 14:25:04 UTC
Okay, thanks, I can reproduce this now.
Comment 5 Jeffrey Stedfast 2012-01-16 16:06:32 UTC
I just noticed that you declared your queue inside the button touched event handler, you really need to declare that at the class level so that it isn't GC'd at the end of the handler.

I'm attaching a fixed up version of the project.

Unfortunately, that's not the cause of this particular hang. Seems like it might be a debugger deadlock.
Comment 6 Jeffrey Stedfast 2012-01-16 16:07:46 UTC
Created attachment 1207 [details]
Same project with class-level NSOperationQueue
Comment 7 Jeffrey Stedfast 2012-01-16 16:08:48 UTC
Created attachment 1208 [details]
gdb backtrace of running app

This is the backtrace of all threads of the running app when it hangs.
Comment 8 Jeffrey Stedfast 2012-01-16 16:09:42 UTC
Zoltan: can you take a look at this?
Comment 9 Jeffrey Stedfast 2012-01-16 16:10:37 UTC
I meant to add: set a breakpoint on line 47 of MyView.cs and then debug the app, when the app comes up just click the button.
Comment 10 Zoltan Varga 2012-01-19 01:33:21 UTC
I think there are two issues here: the possible runtime issue, and md hanging. md shouldn't hang, no matter what the runtime on the device does.
Comment 11 Zoltan Varga 2012-01-19 01:46:30 UTC
It seems like md tries to get a stack trace, and CMD_THREAD_GET_FRAME_INFO () calls wait_for_suspend () to wait for the runtime to finish suspending. which doesn't happen for some reason. md probably calls thread.GetFrames () synchronously, causing it to hang.
Comment 12 Jeffrey Stedfast 2012-01-19 09:34:21 UTC
MonoDevelop doesn't hang for me, is it hanging for you? It just seems to be the app that hangs for me.
Comment 13 Jeffrey Stedfast 2012-01-19 09:35:41 UTC
n/m, Sergio said it hangs MD for him in the first comment.
Comment 14 Sergio Fadda 2012-01-19 09:38:56 UTC
Sorry, my mistake; actually is the app that hang; MD hang only if you try to pause the application after the breakpoint is caught.
Comment 15 Zoltan Varga 2012-01-19 09:50:12 UTC
If I press the button on the app, nothing seems to happen, but if I pause the app from md, md hangs.
Comment 16 Zoltan Varga 2012-01-23 06:00:44 UTC
This seems to be some kind of ios problem, it happens both in the simulator and on the device. Some USR1 signals sent by the debugger to thread seem to get lost. In the attached log file, this happens to thread 0xb077f000. A signal is sent at around line 320:

[0xb08a3000] Interrupting 0xb077f000... 0

but the thread doesn't received it (which is marked by a USR1: <tid> line).
Comment 17 Zoltan Varga 2012-01-23 06:02:21 UTC
Created attachment 1251 [details]
debugger log file
Comment 18 Zoltan Varga 2014-11-10 05:04:49 UTC
This was fixed a long time ago by changing the suspend code to use mach suspend/resume functionality.