Bug 820 - gdb process does not quit with simulator
Summary: gdb process does not quit with simulator
Status: RESOLVED NORESPONSE
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 4.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
: 851 ()
Depends on:
Blocks:
 
Reported: 2011-09-14 15:50 UTC by Chris Hardy [MSFT]
Modified: 2013-12-05 18:36 UTC (History)
7 users (show)

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

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 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.

Related Links:
Status:
RESOLVED NORESPONSE

Description Chris Hardy [MSFT] 2011-09-14 15:50:50 UTC
If I run monotouch app in iOS Simulator and then I quit the simulator app without stopping my monotouch app from the MonoDevelop, then in background stay gdb procces... and their numbers keep growing... and them cunsume all my CPU resources...
$ ps -ax|grep gdb
7244 ?? 0:26.92 /bin/sh /usr/bin/gdb -batch -x /tmp/mono-gdb-commands.v6DtuR
7307 ?? 0:12.03 /bin/sh /usr/bin/gdb -batch -x /tmp/mono-gdb-commands.DkKKCg
7330 ?? 0:06.38 /bin/sh /usr/bin/gdb -batch -x /tmp/mono-gdb-commands.EQoCBU
Comment 2 Sebastien Pouliot 2011-09-15 17:04:30 UTC
That comes from the mono runtime*. When a crash occurs gdb is called to show the threads and stack traces for each of them (see mini-darwin.c, line 230). 

However it's not clear why this would occur in normal circumstances. I had a few of them running myself, but I could not create new ones ? Can you ?

* MonoDevelop starts 'mtouch', which starts the iOS simulator, that starts the application (that includes the mono runtime). The application PID is available so either 'mtouch' or the MonoDevelop iPhone addin should be able to kill them.
Comment 3 Sebastien Pouliot 2011-09-16 12:23:50 UTC
*** Bug 851 has been marked as a duplicate of this bug. ***
Comment 4 Chris Toshok 2011-09-18 12:35:25 UTC
It happens when runtime code crashes, basically:


Native stacktrace:

	0   NTLM                                0x000d1d8c mono_handle_native_sigsegv + 343
	0   NTLM                                0x000d1d8c mono_handle_native_sigsegv + 343
	1   NTLM                                0x0000ffd0 mono_sigsegv_signal_handler + 322
	1   NTLM                                0x0000ffd0 mono_sigsegv_signal_handler + 322
	2   libSystem.B.dylib                   0x996ff05b _sigtramp + 43
	2   libSystem.B.dylib                   0x996ff05b _sigtramp + 43
	3   ???                                 0xffffffff 0x0 + 4294967295
	3   ???                                 0xffffffff 0x0 + 4294967295
	4   NTLM                                0x0029c0f2 monotouch_thread_start + 110
Comment 5 Chris Toshok 2011-09-18 12:38:25 UTC
The reason it's failing is due to our libmonotouch-fixes.dylib.  At least that's the last thing that's printed to the console:


  Debug info from gdb:
  dyld: could not load inserted library: /Users/toshok/Library/Application Support/iPhone Simulator/4.3.2/Applications/991E21EA-CC58-40B0-88EE-88D00D07A728/NTLM.app/monotouch-fixes.dylib

and then nothing.  If I remove the fixes.dylib code from template.m and reproduce the crash, i see this instead:


  Debug info from gdb:
  unable to debug self

The reason for this is that the gdb stack trace stuff does effectively:  printf ("attach %ld\n", getpid());

but the getpid is the process id of the process that will be exec'ing gdb in just a few lines.  not the pid of the mono process.
Comment 6 Chris Toshok 2011-09-18 12:49:24 UTC
Also, just communicating the pid of the original mono process isn't enough either, as it's illegal for child processes to attach to parent processes.  We need to look at how glib is doing it, but I expect it's something like:

process 1 (mono) forks 2 processes.
process 2 execs gdb and attaches to process 3
process 3 is just a sibling of 2, and doesn't exec anything, so getting the backtrace there will be identical to doing it in process 1.

Going to disable the gdb stack trace stuff in mono/metadata/mini-exceptions.c for the time being until this is fixed.
Comment 7 Chris Toshok 2011-09-18 12:54:20 UTC
added the following to template.m, please make sure to remove it once this bug is fixed (or when someone works on it to make sure they *are* fixing it :)


        // see http://bugzilla.xamarin.com/show_bug.cgi?id=820                                                                                                                                                  
        // take this line out once the bug is fixed                                                                                                                                                             
        setenv ("MONO_DEBUG", "no-gdb-backtraces", 1);
Comment 8 PJ 2013-11-19 17:05:53 UTC
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.
Comment 9 PJ 2013-12-05 18:36:22 UTC
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.

Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.