Bug 8589 - Random Crash when invoking c# event
Summary: Random Crash when invoking c# event
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 6.0.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-11-26 03:36 UTC by David Leaver
Modified: 2012-11-27 20:12 UTC (History)
2 users (show)

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


Attachments
XCode crash log (32.47 KB, application/octet-stream)
2012-11-26 03:36 UTC, David Leaver
Details


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 FIXED

Description David Leaver 2012-11-26 03:36:43 UTC
Created attachment 3009 [details]
XCode crash log

I had a random crash in a debug build of my game last night. Attached is the crash info.

The line of code the crash comes from is:
BallBeganDisappearing(b);

which is declared as:
public event Action<Ball> BallBeganDisappearing;

This delegate had already been called many times before the crash happened, b in definitely non-null.
There are 4 listeners wired to the delegate, they are all set initially and do not change for the life of the object.

I haven't rebuilt or cleaned since the build with this issue, so I can supply the binaries if useful.
I'm happy to privately provide source code if that would help.

Anything else I can do to help out I'm happy to!
Thanks guys :)

MonoDevelop 3.0.4.7
Runtime:
	Mono 2.10.9 (tarball)
	GTK 2.24.10
	GTK# (2.12.0.0)
	Package version: 210090011
Apple Developer Tools:
	 Xcode 4.5.1 (1842)
	 Build 4G1004
Monotouch: 6.0.6
Comment 1 Sebastien Pouliot 2012-11-26 08:55:22 UTC
8   SimpullsiOS                   	0x00ef5c7e monoeg_assertion_message (goutput.c:181)

^ it looks like the runtime printed something to the device console before aborting.

Can you duplicate the crash again while looking at the Xcode Console for your device ? You'll see the exact error (likely a trampoline limit being reached) along with instructions.

If no instructions are given then please copy/paste the console log into the bug report (it will be meaningful to us).
Comment 2 David Leaver 2012-11-27 03:18:04 UTC
I'm totally not having any luck getting this to reproduce. Just played my game for an hour without quitting and it didn't happen.

I'll rush to a mac to try get console logs next time it happens and I've installed https://itunes.apple.com/us/app/system-console/id431158981?mt=8 which looks like it might do the job.

Is there something I could add to the app that would allow me to log the error?
Maybe an unhandled exception handler that logs to disk? Would be nice if I could get it automatically logging for my testers.

Thanks!
Comment 3 Sebastien Pouliot 2012-11-27 19:39:52 UTC
I never used them but I know there's a few apps that can read the logs from the device themselves. Otherwise Xcode, the iPhone Configuration Utility (iCU) and 'mtouch --logdev' are ways you can extract this information from a computer.

I suspect you're running out of trampolines. The message would confirm this and tell you which type of trampoline (0, 1 or 2) is running out.

ref: http://docs.xamarin.com/ios/troubleshooting#Ran_out_of_trampolines_of_type_0

You cannot catch this from your own application (e.g. the exception handler) since it's written just before the runtime aborts (at least if I'm right about what the issue is). We're working on better solutions for such problems.
Comment 4 David Leaver 2012-11-27 20:12:56 UTC
Awesome, thanks for your help Sebastien.

Will keep an eye out and reopen if I end up with a different cause.