Pause GC Error post android 4.4.2 upgrade

Question

Recently my Galaxy Note 2 was upgraded to version 4.4.2. I am using this phone for development (using ADT) and life was fine but post this upgrade "Pause GC" error started coming and I am unable to resolve. It comes every times UI screen change status in my ADT tool LogCat. Below is dump of the error.

Thanks in advance for the help.

05-13 22:39:22.538: W/dalvikvm(8350): No implementation found for native Ldalvik/system/VMRuntime;.pauseGc:(Ljava/lang/String;)I
05-13 22:39:22.543: E/MyThread(8350): Pause GC
05-13 22:39:22.543: E/MyThread(8350): java.lang.reflect.InvocationTargetException
05-13 22:39:22.543: E/MyThread(8350):   at java.lang.reflect.Method.invokeNative(Native Method)
05-13 22:39:22.543: E/MyThread(8350):   at java.lang.reflect.Method.invoke(Method.java:515)
05-13 22:39:22.543: E/MyThread(8350):   at android.app.MyThread.pauseGC(MyThread.java:5525)
05-13 22:39:22.543: E/MyThread(8350):   at android.app.MyThread.performLaunchActivity(MyThread.java:2324)
05-13 22:39:22.543: E/MyThread(8350):   at android.app.MyThread.handleLaunchActivity(MyThread.java:2471)
05-13 22:39:22.543: E/MyThread(8350):   at android.app.MyThread.access$900(MyThread.java:175)
05-13 22:39:22.543: E/MyThread(8350):   at android.app.MyThread$H.handleMessage(MyThread.java:1308)
05-13 22:39:22.543: E/MyThread(8350):   at android.os.Handler.dispatchMessage(Handler.java:102)
05-13 22:39:22.543: E/MyThread(8350):   at android.os.Looper.loop(Looper.java:146)
05-13 22:39:22.543: E/MyThread(8350):   at android.app.MyThread.main(MyThread.java:5602)
05-13 22:39:22.543: E/MyThread(8350):   at java.lang.reflect.Method.invokeNative(Native Method)
05-13 22:39:22.543: E/MyThread(8350):   at java.lang.reflect.Method.invoke(Method.java:515)
05-13 22:39:22.543: E/MyThread(8350):   at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1283)
05-13 22:39:22.543: E/MyThread(8350):   at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1099)
05-13 22:39:22.543: E/MyThread(8350):   at dalvik.system.NativeStart.main(Native Method)
05-13 22:39:22.543: E/MyThread(8350): Caused by: java.lang.UnsatisfiedLinkError: Native method not found: dalvik.system.VMRuntime.pauseGc:(Ljava/lang/String;)I
05-13 22:39:22.543: E/MyThread(8350):   at dalvik.system.VMRuntime.pauseGc(Native Method)
05-13 22:39:22.543: E/MyThread(8350):   ... 15 more

UPDATE: I have initiated the issue at code.android.com (http://code.google.com/p/android/issues/detail?id=71073). As per them its Samsung bug so I have raised the issue to Samsung forum now.

Answer 1

After seeing this issue for some time on my Note 2 (GT-N7100), Android 4.4.2 I wanted to make my above comment a proper answer.

Sorted by allocation size:

I used webrtc to track allocation when the Android camera is used, and it can be clearly seen that every time the camera is invoked and the video is rendered onto GLSurfaceView in a new Activity, more than 2 MB of trash is left over, which is never ever gathered by GC.

To compare, here is the same allocation tracked on an ASUS Memo Pad 2, Android 4.2.2:

Sorted by allocation size:

In other words, on a Note 2 you can start a video live view about 20-30 times, before memory is full and the device crashes.

In other words: Samsung introduced this issue with an update last year and did not yet fix it, nor do they react in any way. Does Samsung want to make us buy a new device? Looks like that.

--

And here is my original comment as of 2014-12-11:

It does cause trouble. It causes the device to take much more memory than needed and crash. We are developing an app with many images and videos, and due to the missing GC it is possible to make Android reach the 64MB limit (Note 2) and crash, whereas on other devices memory consumption is much lower and memory is always released after use. For example, an ASUS Memo Pad with the same resolution consumes about 12MB, for what the Samsung Note 2 takes 24MB. The Samsung device is much faster, though, probably because of the GC being omitted.

Answer 2

I had the same problem as you. I was using ACRA and it was swallowing the crash and only showing this in the logcat.

The error actually made it back to the server and I was able to debug properly. Possibly disable ACRA while debugging and you will see the proper error.