Bug 5749 - Fatal error in mono runtime
Summary: Fatal error in mono runtime
Status: RESOLVED NORESPONSE
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 5.2
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-06-19 11:19 UTC by jesse.attas
Modified: 2013-12-05 18:36 UTC (History)
2 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 jesse.attas 2012-06-19 11:19:00 UTC
While running my application in the simulator, I have started getting a crash in the native code. The application will stop running and go back to the home screen and MonoDevelop will stop debugging it with no dialog. The only indication of what went wrong is a native exception stack trace in the Application Output tab.

I'd never seen this before installing the upgrade this week. I don't have reliable steps to reproduce. It just seems to happen after making some code changes and recompiling. Doing a clean build seems to fix it for a while.

Call stack from Application Output:
===================================
Stacktrace:

  at (wrapper managed-to-native) MonoTouch.ObjCRuntime.Messaging.void_objc_msgSend (intptr,intptr) <IL 0x00024, 0xffffffff>
  at MonoTouch.Foundation.NSObject/MonoTouch_Disposer.Drain (MonoTouch.Foundation.NSObject) [0x0006a] in /Developer/MonoTouch/Source/monotouch/src/Foundation/NSObject.cs:356
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <IL 0x00052, 0xffffffff>
  at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication.UIApplicationMain (int,string[],intptr,intptr) <IL 0x0009f, 0xffffffff>
  at MonoTouch.UIKit.UIApplication.Main (string[],string,string) [0x00042] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:29
  at NationalInstruments.Tablets.DataDashboard.Application.Main (string[]) [0x00000] in /Users/jattas/Developer/tfs/R2-Tablets-Dev/Tablets/DataDashboard/Main.cs:17
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <IL 0x00050, 0xffffffff>

Native stacktrace:

	0   DataDashboard                       0x00095c5c mono_handle_native_sigsegv + 284
	1   DataDashboard                       0x0000afe8 mono_sigsegv_signal_handler + 248
	2   libsystem_c.dylib                   0x91d7a59b _sigtramp + 43
	3   ???                                 0xffffffff 0x0 + 4294967295
	4   libobjc.A.dylib                     0x0380ee3d _objc_rootRelease + 47
	5   DataDashboard                       0x0021121c monotouch_release_trampoline + 380
	6   ???                                 0x0f5e1fc4 0x0 + 257826756
	7   ???                                 0x142d7574 0x0 + 338523508
	8   ???                                 0x09f0916e 0x0 + 166760814
	9   DataDashboard                       0x0000f352 mono_jit_runtime_invoke + 722
	10  DataDashboard                       0x0016f25e mono_runtime_invoke + 126
	11  DataDashboard                       0x0020ba58 monotouch_trampoline + 3416
	12  CoreFoundation                      0x027fae42 -[NSObject performSelector:withObject:] + 66
	13  Foundation                          0x009c09df __NSThreadPerformPerform + 254
	14  CoreFoundation                      0x027cd94f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
	15  CoreFoundation                      0x02730b43 __CFRunLoopDoSources0 + 243
	16  CoreFoundation                      0x02730424 __CFRunLoopRun + 1012
	17  CoreFoundation                      0x0272fd84 CFRunLoopRunSpecific + 212
	18  CoreFoundation                      0x0272fc9b CFRunLoopRunInMode + 123
	19  GraphicsServices                    0x0412a7d8 GSEventRunModal + 190
	20  GraphicsServices                    0x0412a88a GSEventRun + 103
	21  UIKit                               0x01525626 UIApplicationMain + 1163
	22  ???                                 0x0f5e00a5 0x0 + 257818789
	23  ???                                 0x0f5de750 0x0 + 257812304
	24  ???                                 0x0f5de448 0x0 + 257811528
	25  ???                                 0x0f5de59e 0x0 + 257811870
	26  DataDashboard                       0x0000f352 mono_jit_runtime_invoke + 722
	27  DataDashboard                       0x0016f25e mono_runtime_invoke + 126
	28  DataDashboard                       0x00173344 mono_runtime_exec_main + 420
	29  DataDashboard                       0x00178765 mono_runtime_run_main + 725
	30  DataDashboard                       0x0006c555 mono_jit_exec + 149
	31  DataDashboard                       0x00008215 main + 2837
	32  DataDashboard                       0x00003635 start + 53

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Symbol file /Users/jattas/Library/Application Support/iPhone Simulator/5.1/Applications/BD26C744-92E6-4D00-A790-B182BB193C9A/DataDashboard.app/System.ComponentModel.Composition.dll.mdb doesn't match image /Users/jattas/Library/Application Support/iPhone Simulator/5.1/Applications/BD26C744-92E6-4D00-A790-B182BB193C9A/DataDashboard.app/System.ComponentModel.Composition.dll






Version info:
=============
MonoDevelop 3.0.3.2
Installation UUID: 1480f558-ce01-4cc9-8f58-058dda76f061
Runtime:
	Mono 2.10.9 (tarball)
	GTK 2.24.10
	GTK# (2.12.0.0)
	Package version: 210090011
Apple Developer Tools:
	 Xcode 4.3.3 (1178)
	 Build 4E3002
Monotouch: 5.2.12
Mono for Android not installed
Build information:
	Release ID: 30003002
	Git revision: 7bf6ac0ca43c1b12703176ad9933c3484c05c84c-dirty
	Build date: 2012-06-16 04:36:10+0000
	Xamarin addins: 62ad7268d38c2ece7e00dc32960bd3bdab8fec38
Operating System:
	Mac OS X 10.7.4
Comment 1 jesse.attas 2012-06-19 13:35:19 UTC
I just saw this on the device as well.
Comment 2 Rolf Bjarne Kvinge [MSFT] 2012-06-20 05:35:39 UTC
When this happens it is usually because the managed GC freed an object while native code still had references to it.

Can you create a test case or attach your project? That way it would be possible to find out what's going on.
Comment 3 jesse.attas 2012-06-20 10:18:08 UTC
Would it be sufficient to attach only binaries? Or is source code necessary?
Comment 4 Rolf Bjarne Kvinge [MSFT] 2012-06-21 05:05:01 UTC
It would be necessary to have the source code (you can mark attachments as private so only Xamarin employees can see them though).
Comment 6 Rolf Bjarne Kvinge [MSFT] 2012-07-03 21:01:37 UTC
I can't see anything obviously wrong with your code (but these issues are usually not obvious anyhow).

I also tried adding the code to a test project, and with a few modifications it compiled, but I couldn't make it crash.

You should be able to call Dispose as many times as you like, an object won't be freed twice if you call Dispose twice (the second time nothing will happen).

What might help to make it more reproducible is to make the GC even more aggressive, by adding this to the Main method (or anywhere else along the startup path):

new System.Threading.Thread (() =>
{
    while (true) {
        System.Threading.Thread.Sleep (100);
        System.GC.Collect (System.GC.MaxGeneration);
}
}) { IsBackground = true }.Start ();
Comment 7 PJ 2013-11-19 17:05:38 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 8 PJ 2013-12-05 18:36:06 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.