Bug 1394 - misc. crashes in mono runtime particularly on operations on a particular string
Summary: misc. crashes in mono runtime particularly on operations on a particular string
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 1.0
Hardware: PC Windows
: Highest normal
Target Milestone: ---
Assignee: Rodrigo Kumpera
Depends on:
Reported: 2011-10-10 10:52 UTC by Iain
Modified: 2012-01-13 05:37 UTC (History)
3 users (show)

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

example project that intermittently crashes (895.94 KB, application/x-zip-compressed)
2011-11-14 09:48 UTC, Iain

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:

Comment 1 Jonathan Pryor 2011-11-04 11:50:47 UTC
Sorry for the delay in reviewing...

I noticed that the startup project was OssCoreDroid, which doesn't contain any activities (and thus installing it doesn't provide any app to launch). Is the correct startup project supposed to be LinnTopologyDroid?

 - Jon
Comment 3 Iain 2011-11-04 17:42:54 UTC
Hi Jon

Yes, sorry, Linn Topology should be the startup project.  Must have forgot the .suo file.

I've done further development since that version, by the way, but am still finding it unstable.  

I should also say well done in getting this far. Despite the instabilities, which are to be expected in an newly released product of this nature, it's still very impressive stuff!
My app is a pretty heavyweight app and therefore would provide an excellent stress test for you.  Feel free to make use of me to help you track the bugs down, I'm more than willing to help you along the way.  I can provide updated versions of the app if it helps, or run debug / trace builds for you.  Just let me know what you need me to do.

ps. if you want a test upnp device for your network, these links should help:


Comment 4 Iain 2011-11-14 09:48:21 UTC
Created attachment 881 [details]
example project that intermittently crashes

Thought I'd add this example project to the bug.  Not sure whether it's directly related or caused by another bug, but I created this toy app to test a hang we were experiencing on starting/stopping our network stack.  It starts 10 threads which bind to a socket, then closes the socket and aborts/joins the threads.  

To cut a long story short, this app hangs or ANRs fairly regularly (perhaps once every 10 or so runs), both during starting and stopping the threads, so it might help you to track down the problem more easily than the full sample project?  On the other hand, there's no stacktrace with this app, so it may be a completely unrelated issue, in which case I can log as a separate bug if you prefer?

Again, this is reproducible on a Motorola Xoom WiFi, deployed in debug mode,  MFA v1.2.0.26415.

Hope it helps you and does not further cloud the issue :)

Comment 5 Rodrigo Kumpera 2011-12-06 12:22:02 UTC
Hi Iain,

We fixed a similar crash on the 4.0 release, does it still occur with it?

Comment 11 Rodrigo Kumpera 2012-01-05 18:09:34 UTC
Hi Iain,

I tried your app for close to an hour and I could not crash or hang it at all.

I did what you suggested, opening/closing it and nothing happened.
Comment 18 Jonathan Pryor 2012-01-11 12:59:00 UTC
The hang described in comment #4 has been moved to bug #2485, as it's not directly related to Android (it also happens on desktop Mono).

Unfortunately, based on what I've seen in #2485, it looks like Thread.Abort() is partially at fault. If I take the bug #2485 sample app, remove the iThread.Abort() call, and instead terminate the loop "cooperatively":

	public void Stop()
		Console.WriteLine("Joining thread: {0}", portIndex);
		running = false;

	private void RunThread()
		while (running)
			byte[] buffer = new byte[1024];
		Console.WriteLine("RunThread terminated successfully: " + portIndex);
	volatile bool running = true;

then I don't see the hang. So the hang appears to be the interaction between Thread.Abort(), Thread.Join(), and GC use. Removing the Thread.Abort() call may be workable...except that your original code was using Socket.Receive(), which doesn't take a timeout parameter. Perhaps using Socket.BeginReceive() along with a cooperative stopping mechanism would work (instead of Thread.Abort())?

That leaves the crashes, which as you note are hard to reproduce (comment #12). Hopefully the 4.0.3 release will fix them; if it doesn't, please re-open this bug or file a new one (if you can create a simpler test case); a major problem is that we don't have the test environment you do, so just because it works for us doesn't mean it'll work for you :-(
Comment 19 Iain 2012-01-11 13:43:31 UTC
Thanks Jon

No worries, I will wait for 4.0.3 and re-open if the problem's still there.  I appreciate that the lack of test environment is a huge problem.  I have done my utmost to write you a standalone repro app but just had no luck in producing one :(

Re the threads issue, are you sure the bug number is 2485?  That bug is to do with System.IO.Directory.EnumerateFiles() not working on an external directory.

Comment 20 Jonathan Pryor 2012-01-11 14:04:27 UTC
Sorry, snafu; i meant bug #2845. (Right digits, wrong order.)

I want to finally note that Thread.Abort() should be avoided anyway: http://msdn.microsoft.com/en-us/library/1c9txz50.aspx

> "Don't use Thread.Abort to terminate other threads.
> Calling Abort on another thread is akin to throwing 
> an exception on that thread, without knowing what
> point that thread has reached in its processing."


> Either way, the call to the Dispose method in the finally 
> block is circumvented, resulting in an abandoned open 
> file handle, preventing any subsequent attempts to
> create myfile.txt until the process ends.


> What does all of this mean?  Quite simply, the .NET 
> Framework cannot be trusted when any of the 
> aforementioned exceptions are thrown."

In short, Don't Do That™. The _only_ times it's safe to call Thread.Abort() is when invoking on the currently executing thread (`Thread.CurrentThread.Abort()`) and when you control EVERY code path that MAY be executing when Thread.Abort() is invoked. This means NO FRAMEWORK CODE (No List<T>, no sockets, no nothing).
Comment 21 Iain 2012-01-13 05:37:18 UTC
Indeed - I'm aware of that.  It's been on my todo list for a while to remove them all, I just haven't had time yet :)