Bug 1534 - Application freeze during heavy network use/low memory
Summary: Application freeze during heavy network use/low memory
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 1.0
Hardware: PC Windows
: High major
Target Milestone: ---
Assignee: Rodrigo Kumpera
Depends on:
Reported: 2011-10-17 13:20 UTC by Brett
Modified: 2011-11-22 22:16 UTC (History)
4 users (show)

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

VS project that recreates System.GC.Collection crash (851.96 KB, application/octet-stream)
2011-11-08 21:18 UTC, Brett
Another test case that causes System.GC.Collect crash (320.21 KB, application/zip)
2011-11-09 19:05 UTC, Brett
Logcat snapshot of GC crash (24.88 KB, application/octet-stream)
2011-11-09 19:41 UTC, Brett

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:

Description Brett 2011-10-17 13:20:49 UTC
Application freezes during heavy network use accompanied by a stacktrace. The application does not crash, but becomes unresponsive. This issue is not limited to network use however, it has arisen during bson parsing as well.

The issue seems to be related to low memory conditions (see stacktrace below).

This issue may be related to bug 1031 (http://bugzilla.xamarin.com/show_bug.cgi?id=1031) as the symptoms I'm experiencing are almost the same.

A stacktraces emitted as the issue arose:

http://pastebin.com/aS7YMiNi - (An exception in StringBuilder.InternalEnsureCapacity)

Comment 1 Chris Tossing 2011-11-06 20:45:12 UTC
I believe that am seeing this, as well.

I am downloading a good number of discrete chunks of data one after another.  If the size of each chunk that I download is 64kB the UI hangs after a few downloads (running on a hunch, it seems to be related to garbage collection).  If I increase the chunk size to 256kB, however, it takes longer to download each chunk (allowing the garbage collector to do its job?) and completes successfully.
Comment 2 Brett 2011-11-07 13:34:56 UTC
Another stacktrace that is emitted just before the app becomes unresponsive: http://pastebin.com/qG8viPHx
Comment 3 Brett 2011-11-07 14:38:27 UTC
And another: http://pastebin.com/rwBgH2v1
Comment 4 Brett 2011-11-07 16:05:36 UTC
Rebooting the device seems to "fix" this issue. For how long, I'm not sure, I'll need to run the application for a few days under heavy load to see if the issue crops up again.
Comment 5 Brett 2011-11-07 16:09:58 UTC
Oh, I should have mentioned that the issue seems to be directly linked to System.GC.Collect deadlocking.

After profiling memory for a while, I can see allocations increase to a point where a collection is needed and most likely occurs, then kaboom. I'm going to see if I can write a simple test case that reproduces this issue consistently in the hopes that it will help the Xamarin team fix the issue.
Comment 6 Brett 2011-11-07 17:48:18 UTC
Sorry to be spamming this bug, but I'm just adding information as I come across it since I'm dealing directly with this issue at the moment.

Anyway, I have verified that the magic "reboot fix" does eventually wear off after a couple hours of application usage.
Comment 7 andrew 2011-11-07 17:56:28 UTC
Brett - I have a similar bug logged as http://bugzilla.xamarin.com/show_bug.cgi?id=1031.

Re-booting doesn't really seem to have any effect in my case, intensive use of the app after a re-boot pretty quickly causes the same problem.

As with you, I'm sure it's GC-related. Hopefully we'll get a fix for this soon, it's a painful problem!
Comment 8 Brett 2011-11-08 21:18:09 UTC
Created attachment 851 [details]
VS project that recreates System.GC.Collection crash

A small app that allows you to create threads that do a lot of work and never terminate. You can force System.GC.Collect() and Java.Lang.Runtime.Gc(). Once 10 threads have been started, running System.GC.Collect() will cause the application to freeze (and throw a stacktrace) (Runtime.Gc() completes normally).

It seems like memory usage does not have any influence on the issue, you can consistently cause an ANR once at least 10 threads have been created.
Comment 11 Rodrigo Kumpera 2011-11-09 17:34:31 UTC
Hey Guys, your test case is mixing up two thing. Heavy thread usage and heavy memory usage.

Heavy thread usage doesn't impact mono, I changed your test to just busy loop and things work fine with many dozens threads. The limitation will be on Android itself, which is not very found of high loads.

Now, the next part is heavy memory usage.

Your sample allocates a 132k elements array plus 100k small objects. Then it keeps all those objects alive.

This is a very high number of objects to keep in memory and reachable, so the GC suffers a severe performance degradation.

To fix this case, please reduce the working set of you app.

If you're running with the latest version on Mono4Android use this command before firing your app:

adb shell setprop debug.mono.env 'MONO_LOG_LEVEL=debug|MONO_LOG_MASK=gc'

This will enable a limited for of GC logging that will give us some hints on what might be going on.

If your pause times are too long, the way to fix it is to optimize your app to not hold onto millions of objects in memory.
Comment 12 Brett 2011-11-09 19:05:48 UTC
Created attachment 858 [details]
Another test case that causes System.GC.Collect crash

This test case removes the heavy memory usage in the created threads. Creating 10 threads then causing a System.GC.Collect still causes a stack trace and eventual ANR message.
Comment 13 Brett 2011-11-09 19:41:52 UTC
Created attachment 859 [details]
Logcat snapshot of GC crash

This snapshot was created with 

adb shell setprop debug.mono.env 'MONO_LOG_LEVEL=debug|MONO_LOG_MASK=gc'
Comment 14 Rodrigo Kumpera 2011-11-10 14:31:50 UTC
Hi Bret,

I can confirm that there is a very weird hang happening on your last example.
I'm working on it.
Comment 15 Rodrigo Kumpera 2011-11-22 22:16:12 UTC
Hi Bret,

I have fixed your bug in Mono for Android. It will be part of our next public release to come very soon.