Bug 2738 - Long-running, resource/processor intensive tasks cause application to crash randomly
Summary: Long-running, resource/processor intensive tasks cause application to crash r...
Status: RESOLVED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 4.0
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-01-04 18:42 UTC by Chris Drake
Modified: 2012-01-05 15:59 UTC (History)
3 users (show)

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


Attachments
application demonstrating the crash (2.71 MB, application/zip)
2012-01-05 10:41 UTC, Chris Drake
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 Chris Drake 2012-01-04 18:42:12 UTC
Overview: When performing a long-running, resource/processor intensive task my application will randomly crash with a stacktrace that is either empty or different for each execution. The application crashes randomly after a period of time. If I attempt to step into the application using the debugger I cannot isolate a single point of failure, it varies. It does seem to be strongly correlated to how much is being done, shorter operations are successful. Based on the log output, the single constant symptom is that the crash always occurs immediately after the monodroid garbage collector runs and is followed by a stacktrace in the log that is random or empty. Below (See Actual Results section) I have included the relevant segment of the log, look at the entries for process ID 6349. I have found that simpler test apps do not reproduce the problem, for me it seems to be related to how much data my background thread is processing and how many iterations are performed.

I have attached a sample app that demonstrates this problem. The sample application generates triangle sets for rendering solid lines as four point polygons using a Delany triangulation algorithm implemented in a library called Net Topology Suite. For simplicity I have not included the rendering code. The demo still produces the same type of exception immediately after the mono GC runs on the thread. Also note the assertion occurring in a release build.

01-03 16:35:24.570 F/        ( 4673): * Assertion: should not be reached at ../../../../mono/metadata/sgen-marksweep.c:279
01-03 16:35:24.570 I/mono    ( 4673): Stacktrace:
01-03 16:35:24.570 I/mono    ( 4673):
01-03 16:35:24.570 I/mono    ( 4673):   at System.Array.Resize<T> (T[]&,int) <0x00077>
01-03 16:35:24.586 I/ActivityManager( 1378): Process CrashTestDummy.CrashTestDummy (pid 4673) has died.

As you can see from the log excerpt the exception in the demo is not always stacktrace-less, as many have observed in the forum, but does not always occur in the same place either. It is also important to note that the stacktrace and assertion messages only appear in the log when running in RELEASE. I do believe it is indicative of the same underlying problem. To further simplify the situation I am using only the UI thread, no worker threads.

Steps to Reproduce: 

Run the test application that I have attached to this bug. You should see the crash in either release or debug configurations, but note that for some reason the stacktrace (empty or otherwise) only appears in the log when running in release. I have also noted that the window does not always get destroyed after the crash, although the application is no longer running, you will still see the stacktrace message in the log.

When working with the demo application you will find a hard coded range on the loop governing the number of lines produced by the application on line 60 of Activity1.cs. If you drop the upper bound to something small like 50 the application will begin functioning normally and you should see on-screen output of how many lines were processed. A large upper bound (like 10,000) on this loop will result in the crash described.

Actual Results: What the application did after performing the above steps.

    The application crashed. Relevant log section listed below

12-08 17:22:13.644 D/dalvikvm( 6349): GC_EXPLICIT freed 4995 objects / 300176 bytes in 30ms
12-08 17:22:13.644 I/monodroid-gc( 6349): GC cleanup summary: 21 objects tested - resurrecting 15.
12-08 17:22:27.644 D/BatteryService( 1375): update start
12-08 17:22:27.652 D/BatteryService( 1375): updateBattery level:72 scale:100 status:4 health:2 present:true voltage: 3866 temperature: 343 technology: Li-ion AC powered:false USB powered:true icon:17302563
12-08 17:22:27.668 D/Tethering( 1375): active iface (usb0) reported as added, ignoring
12-08 17:22:27.668 D/WifiService( 1375): ACTION_BATTERY_CHANGED pluggedType: 2
12-08 17:22:27.668 D/BatteryService( 1375): update start
12-08 17:22:27.676 D/BatteryService( 1375): update start
12-08 17:22:29.199 I/mono    ( 6349): Stacktrace:
12-08 17:22:29.199 I/mono    ( 6349):
12-08 17:22:29.215 I/WindowManager( 1375): WIN DEATH: Window{48f7d828 SurfaceView paused=false}
12-08 17:22:29.223 I/ActivityManager( 1375): Process TerragoMobileAndroid.TerragoMobileAndroid (pid 6349) has died.
12-08 17:22:29.230 I/WindowManager( 1375): WIN DEATH: Window{49007770 TerragoMobileAndroid.TerragoMobileAndroid/terragomobileandroid.TGOMobileApplication paused=false}
12-08 17:22:29.238 I/Launcher( 1467): onResume(). mIsNewIntent : false
12-08 17:22:29.238 I/UsageStats( 1375): Unexpected resume of com.sec.android.app.twlauncher while already resumed in TerragoMobileAndroid.TerragoMobileAndroid

Expected Results:

    The application should not crash.

Build Date & Platform:

    I have seen this happening since 1.9.2 and is still present in 4.0.1

Additional Information: 

Several forum postings describe an issue identical or almost identical to mine here are links to two:

http://lists.ximian.com/pipermail/monodroid/2011-December/007756.html
http://lists.ximian.com/pipermail/monodroid/2011-December/007862.html
Comment 1 Chris Drake 2012-01-05 10:41:35 UTC
Created attachment 1129 [details]
application demonstrating the crash
Comment 3 Jonathan Pobst 2012-01-05 15:59:23 UTC
Just tested this with the upcoming 4.0.2 on my Nexus One, and it seems to be fixed now.  No crashes, eventually it just says "Lines Generated: 10000".