Bug 211 - GC.Collect() -> App crashes
Summary: GC.Collect() -> App crashes
Status: RESOLVED DUPLICATE of bug 245
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 1.0
Hardware: PC Windows
: --- critical
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2011-08-06 03:19 UTC by andi
Modified: 2011-08-19 20:12 UTC (History)
5 users (show)

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


Attachments
Test Case (20.53 KB, application/octetstream)
2011-08-09 17:53 UTC, John Moore
Details
Application Output (727 bytes, text/plain)
2011-08-09 17:55 UTC, John Moore
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 DUPLICATE of bug 245

Description andi 2011-08-06 03:19:07 UTC
After the Garbage Collector is executed (called by app or by runtime) an application crashes. 


1. Run an application (Memory information from "Process Monitor" app)
   - Memory Usage
     * Virtual 484 MB
     * Shared 22 MB
     * Date 47 MB
   - Actual Memory Used 66 MB
2. Call GC.Collect()
3. The application will crash
Comment 1 Jonathan Pobst 2011-08-06 11:57:27 UTC
Putting GC.Collect in the default template doesn't make it crash, so I think the issue is a bit deeper than simply calling GC.Collect.

Can you attach a test case which exhibits this bug?

Thanks!
Comment 2 John Moore 2011-08-09 13:39:08 UTC
(In reply to comment #1)
> Putting GC.Collect in the default template doesn't make it crash, so I think
> the issue is a bit deeper than simply calling GC.Collect.
> 
> Can you attach a test case which exhibits this bug?
> 
> Thanks!

Jonathan,
I'd like to report that I am also seeing this issue; however, you are correct in that it is deeper than simply calling GC.Collect() from the default template.  Doing that appears to work just fine.  I am crashing my app when making that call off of the primary (UI) thread, i.e. in a Timer's call back.  I have an example on my personal machine that i can provide this evening.  I was observing this issue on the emulator and physical hardware after installing version 1.0.2 yesterday evening.

Additionally I am building an app with a long running background service.  I have observed the memory foot grow constantly for about 15 to 25 minutes until it hit 36 mb, probably the limit on my device.  at that time the service dies and is restarted.  This makes me suspect that background .net threads are not being properly collected, although i'm still new to MonoDroid so i could be at fault on this.
Comment 3 John Moore 2011-08-09 17:53:51 UTC
Created attachment 103 [details]
Test Case

I run this code in the emulator and after about a minute it fails, the state of the service seems to have no effect.  I am using Mono Develop 2.6b3 on windows 7 64 bit.
Comment 4 John Moore 2011-08-09 17:55:02 UTC
Created attachment 104 [details]
Application Output
Comment 5 Jonathan Pryor 2011-08-09 19:53:16 UTC
I wonder if Bug #245 is a simplified version of this, or if it's entirely unrelated.
Comment 6 John Moore 2011-08-09 21:27:27 UTC
They seem similar, but not completely, when this app dies there is an entry saying it exited cleanly (1), they both revolve around the GC running and the process dieing, it is likley they are related



D/GPSService( 2862): Service not running GC
D/dalvikvm( 2862): GC_EXPLICIT freed 19 objects / 648 bytes in 151ms
D/GPSService( 2862): Done GC
D/GPSService( 2862): Service not running GC
D/dalvikvm( 2862): GC_EXPLICIT freed 19 objects / 648 bytes in 158ms
D/GPSService( 2862): Done GC
D/GPSService( 2862): Service not running GC
D/Zygote  (   33): Process 2862 exited cleanly (1)
I/ActivityManager(   43): Process gpsservice.gpsservice (pid 2862) has died.
I/WindowManager(   43): WIN DEATH: Window{440528b0 gpsservice.gpsservice/gpsserv
ice.Activity1 paused=false}
I/UsageStats(   43): Unexpected resume of com.android.settings while already res
umed in gpsservice.gpsservice
W/InputManagerService(   43): Got RemoteException sending setActive(false) notif
ication to pid 2862 uid 10042
D/SntpClient(   43): request time failed: java.net.SocketException: Address fami
ly not supported by protocol
Comment 7 andi 2011-08-10 02:16:23 UTC
Unfortunately, I was not able to create a test case so far. My application is quite complex. Yesterday I installed the new release but the crash still appears.  But now the crash happens 'earlier' and the following message is put on debzg window:

* Assertion at ../../../../mono/metadata/sgen-internal.c:441, condition `mh->size == size + sizeof (LargeInternalMemHeader)' not met

And it still happens when call GC.Callect();

Hope that helps!
Comment 8 Rodrigo Kumpera 2011-08-19 20:12:24 UTC
This has the same underpinning of #245. Please test your app with the next release of Mono4Androind and reopen this bug in case it doesn't fix.

*** This bug has been marked as a duplicate of bug 245 ***