On Nov 10, 9:55 am, ashAndroid <[EMAIL PROTECTED]> wrote: > but sometimes it crashes giving error :Excessive JNI global > references: ( Pl. see logs below )
Ordinarily, objects are discarded when nothing else in the virtual heap holds a reference to them. This is a problem for native code, which can be holding an object reference that isn't visible to the garbage collector. JNI allows native code to convert a reference into a "global" reference, which the garbage collector can see. To help find memory leaks, a limit is placed on the total number of global references available to the VM. (This should only be enabled on the emulator.) It looks like some native code is allocating lots of certain kinds of objects: > W/dalvikvm( 440): JNI global reference table summary (2001 entries): > W/dalvikvm( 440): 53 of Ljava/lang/Class; 164B (42 unique) > W/dalvikvm( 440): 1 of Ljava/lang/String; 28B > W/dalvikvm( 440): 941 of Ljava/lang/ref/WeakReference; 28B (941unique) > W/dalvikvm( 440): 10 of Ljava/lang/ref/WeakReference; 36B (10 unique) > W/dalvikvm( 440): 1 of Ldalvik/system/VMRuntime; 12B > W/dalvikvm( 440): 1 of Landroid/app/ActivityThread$ProviderRecord; 28B > W/dalvikvm( 440): 1 of Landroid/app/ActivityThread$ApplicationThread; 28B > W/dalvikvm( 440): 1 of Landroid/content/ContentProvider$Transport; 28B > W/dalvikvm( 440): 470 of Landroid/database/ContentObserver$Transport; 28B > (470 unique) > W/dalvikvm( 440): 2 of Landroid/database/ContentObserver$Transport; 36B > (2 unique) > W/dalvikvm( 440): 497 of Landroid/database/CursorToBulkCursorAdaptor; 44B > (451 unique) > W/dalvikvm( 440): 23 of Landroid/database/CursorToBulkCursorAdaptor; 52B > (21 unique) > W/dalvikvm( 440): Memory held directly by native code is 67888 bytes > E/dalvikvm( 440): Excessive JNI global references (2001) It may be that some bit of code is failing to close a Cursor. I don't see how the code you posted would cause the creation of ContentObserver objects. > E/dalvikvm( 440): VM aborting > I/DEBUG ( 21): *** *** *** *** *** *** *** *** *** *** *** *** *** *** > *** *** The next part of the log includes the native stack trace, showing where the last gref allocation occurred. This can sometimes help determine which bit of code was overdoing it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
