Segmentation Fault beim Laden bestimmter Klassen in OSGi unter Android (2.2 & 2.3)

Hallo zusammen,

... ich hoffe mal, ich bin hier richtig, und verstosse bei meinem ersten Posting hier nicht gleich gegen irgendwelche Forenregeln, die ich so nicht gesehen habe...

Worum es geht: ich bin (bzw. wir sind) dabei, eine Applikation zu entwickeln, die in einem OSGi-Framework unter Android laufen soll. Grundsätzlich arbeitet das OSGi-Framework bzw. die Frameworks auch prima (wir verwenden zum Testen parallel Apache Felix und ProSyst mBS Mobile); Bundle lassen sich installieren & starten, und registrieren ihre Services auch brav (also erstmal alles so, wie es sein soll). Einzige Ausnahme ist (wie könnte es andern sein) eine unserer Kernkomponenten (wiederum ein OSGi Bundle) - diese stellt einen Service zur Verfügung, bei dem in einigen Methodensignaturen javax.security.auth.Subjects mit übergeben werden (können). Wird die Klasse dieses Services instanziiert scheint es ein wie auch immer geartetes Problem mit dem Laden dieser Klasse geben - sie ist (natürlich) nicht Teil des OSGi-Framework, sondern wird von der Android API / der Dalvik VM geliefert. Das scheint aber *irgendwie* fehlzuschlagen, was dann dazu führt, dass (wie ich vermute) die Dalvik VM abstürzt - auf jeden Fall stürzt das OSGi-Framework ab, und es gibt einen Segmentation Fault.

Hier vielleicht mal ein kleiner Auszug aus dem Log, das ich bekomme:

++++++++++++++++++++++++++++++++++
05-09 13:20:08.740: DEBUG/dalvikvm(13668): DEX prep './felix-cache/bundle10/version10.0/bundle.jar': unzip in 10ms, rewrite 153ms
05-09 13:20:19.819: DEBUG/dalvikvm(13668): DexOpt: --- BEGIN 'bundle.jar' (bootstrap=0) ---
05-09 13:20:19.929: DEBUG/dalvikvm(13750): DexOpt: load 10ms, verify0ms, opt 3ms
05-09 13:20:19.939: DEBUG/dalvikvm(13668): DexOpt: --- END'bundle.jar' (success) ---
05-09 13:20:19.939: DEBUG/dalvikvm(13668): DEX prep './felix-cache/bundle34/version0.0/bundle.jar': unzip in 1ms, rewrite 116ms
05-09 13:20:20.009: DEBUG/dalvikvm(13668): GC_FOR_MALLOC freed 10683 objects / 957840 bytes in 54ms
05-09 13:20:20.079: WARN/dalvikvm(13668): VFY: unable to find class referenced in signature (Ljavax/security/auth/Subject;)
05-09 13:20:20.379: INFO/DEBUG(31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-09 13:20:20.379: INFO/DEBUG(31): Build fingerprint: 'generic/sdk/generic/:2.2/FRF91/43546:eng/test-keys'
05-09 13:20:20.389: INFO/DEBUG(31): pid: 13668, tid: 13679 >>> /system/bin/dalvikvm <<<
05-09 13:20:20.389: INFO/DEBUG(31): signal 11 (SIGSEGV), fault addr 00000024
05-09 13:20:20.399: INFO/DEBUG(31): r0 00000000 r1 4013fc48 r2 00011074 r3 80087fc4
05-09 13:20:20.399: INFO/DEBUG(31): r4 80088d1c r5 400fb210 r6 00000000 r7 41f695f1
05-09 13:20:20.399: INFO/DEBUG(31): r8 80013b00 r9 400fb210 10 401abeb0 fp 0002e0c8
05-09 13:20:20.409: INFO/DEBUG(31): ip 80088098 sp 422e1d38 lr 8005ee23 pc 8005cdce cpsr 20000030
05-09 13:20:20.449: INFO/DEBUG(31): #00 pc 0005cdce /system/lib/libdvm.so
05-09 13:20:20.449: INFO/DEBUG(31): #01 pc 0005ee1e /system/lib/libdvm.so
05-09 13:20:20.449: INFO/DEBUG(31): #02 pc 0005ee8c /system/lib/libdvm.so
05-09 13:20:20.449: INFO/DEBUG(31): #03 pc 0005ef6c /system/lib/libdvm.so
05-09 13:20:20.459: INFO/DEBUG(31): #04 pc 0005f13e /system/lib/libdvm.so
05-09 13:20:20.459: INFO/DEBUG(31): #05 pc 00017c60 /system/lib/libdvm.so
05-09 13:20:20.459: INFO/DEBUG(31): #06 pc 0001e8c4 /system/lib/libdvm.so
05-09 13:20:20.469: INFO/DEBUG(31): #07 pc 0001d790 /system/lib/libdvm.so
05-09 13:20:20.469: INFO/DEBUG(31): #08 pc 00053eec /system/lib/libdvm.so
05-09 13:20:20.469: INFO/DEBUG(31): #09 pc 00054102 /system/lib/libdvm.so
05-09 13:20:20.479: INFO/DEBUG(31): #10 pc 0004825a /system/lib/libdvm.so
05-09 13:20:20.479: INFO/DEBUG(31): #11 pc 0001103c /system/lib/libc.so
05-09 13:20:20.479: INFO/DEBUG(31): #12 pc 00010b20 /system/lib/libc.so
05-09 13:20:20.479: INFO/DEBUG(31): code around pc:
05-09 13:20:20.489: INFO/DEBUG(31): 8005cdac 10831a98 43584803 46c04770 0002b228
05-09 13:20:20.489: INFO/DEBUG(31): 8005cdbc 00000374 aaaaaaab 4b12b510 2900447b
05-09 13:20:20.489: INFO/DEBUG(31): 8005cdcc 6a42d01e 062424b0 4c0f1912 4c0f591b
05-09 13:20:20.489: INFO/DEBUG(31): 8005cddc 681b3394 dc0442a2 d0022b00 181800d0
05-09 13:20:20.499: INFO/DEBUG(31): 8005cdec 3050e000 3b016843 e007009a 58a46804
05-09 13:20:20.499: INFO/DEBUG(31): code around lr:
05-09 13:20:20.499: INFO/DEBUG(31): 8005ee00 f7ff1c07 4c14ffe9 48141c06 5824447c
05-09 13:20:20.499: INFO/DEBUG(31): 8005ee10 6820348c f7b43014 6ce9e982 f7fd1c30
05-09 13:20:20.499: INFO/DEBUG(31): 8005ee20 9001ffd1 30146820 ec66f7b4 20019b01
05-09 13:20:20.499: INFO/DEBUG(31): 8005ee30 d10e2b00 1c386ce9 ffcef7ff d0011e04
05-09 13:20:20.509: INFO/DEBUG(31): 8005ee40 d1032e00 ff20f7e7 63012100 42501b32
05-09 13:20:20.509: INFO/DEBUG(31): stack:
05-09 13:20:20.509: INFO/DEBUG(31): 422e1cf8 401f1180 /dev/ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.509: INFO/DEBUG(31): 422e1cfc 8006caa4 /system/lib/libdvm.so
05-09 13:20:20.509: INFO/DEBUG(31): 422e1d00 00000002
05-09 13:20:20.519: INFO/DEBUG(31): 422e1d04 00000000
05-09 13:20:20.519: INFO/DEBUG(31): 422e1d08 401f1180 /dev/ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.519: INFO/DEBUG(31): 422e1d0c 0009eb00 [heap]
05-09 13:20:20.519: INFO/DEBUG(31): 422e1d10 41f695f1 /data/dalvik-cache/mnt@sdcard@test@felix-osgi@.@felix-cache@bundle10@[email protected]@classes.dex
05-09 13:20:20.519: INFO/DEBUG(31): 422e1d14 401692c8 /dev/ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.519: INFO/DEBUG(31): 422e1d18 00011074 [heap]
05-09 13:20:20.529: INFO/DEBUG(31): 422e1d1c afd10510 /system/lib/libc.so
05-09 13:20:20.529: INFO/DEBUG(31): 422e1d20 80088d1c /system/lib/libdvm.so
05-09 13:20:20.529: INFO/DEBUG(31): 422e1d24 400fb210 /dev/ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.529: INFO/DEBUG(31): 422e1d28 00000000
05-09 13:20:20.529: INFO/DEBUG(31): 422e1d2c 41f695f1 /data/dalvik-cache/mnt@sdcard@test@felix-osgi@.@felix-cache@bundle10@[email protected]@classes.dex
05-09 13:20:20.539: INFO/DEBUG(31): 422e1d30 df002777
05-09 13:20:20.539: INFO/DEBUG(31): 422e1d34 e3a070ad
05-09 13:20:20.539: INFO/DEBUG(31): #00 422e1d38 80088d1c /system/lib/libdvm.so
05-09 13:20:20.539: INFO/DEBUG(31): 422e1d3c 8005ee23 /system/lib/libdvm.so
05-09 13:20:20.549: INFO/DEBUG(31): #01 422e1d40 00028850 [heap]
05-09 13:20:20.549: INFO/DEBUG(31): 422e1d44 0004a340 [heap]
05-09 13:20:20.549: INFO/DEBUG(31): 422e1d48 00000000
05-09 13:20:20.549: INFO/DEBUG(31): 422e1d4c 400fb210 /dev/ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.549: INFO/DEBUG(31): 422e1d50 410ceefc /dev/ashmem/dalvik-LinearAlloc (deleted)
05-09 13:20:20.549: INFO/DEBUG(31): 422e1d54 401dcd08 /dev/ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.549: INFO/DEBUG(31): 422e1d58 400fb210 /dev/ashmem/mspace/dalvik-heap/0 (deleted)
05-09 13:20:20.559: INFO/DEBUG(31): 422e1d5c 8005ee91 /system/lib/libdvm.so
05-09 13:20:21.239: INFO/BootReceiver(59): Copying /data/tombstones/tombstone_09 to DropBox (SYSTEM_TOMBSTONE)
05-09 13:20:21.399: DEBUG/dalvikvm(59): GC_FOR_MALLOC freed 2764 objects / 477792 bytes in 155ms
++++++++++++++++++++++++++++++++++

Das Problem liegt bzw. beginnt m.E. nach in der 7. Zeile (timestamp 13:20:20.079). Ich hab da inzw. wild hin- und herdebug'ed, aber ich komme zu keiner Lösung. Die benötigte Klasse (javax.security.auth.Subject) ist unter Dalvik verfügbar (bestimmte javax.*-Sachen fehlen da AFAIK ja, diese aber nicht) - wenn ich z. B. ein einfaches Testbundle starte, das nichts anderes tut als ein solches Subject zu instanziieren, dann läuft das auch durch, d.h. stürzt nicht etwa ab oder so (da scheint das dann also zu funktioneren...). Betreibe ich unsere Bundles im identischen OSGi-Framework auf einem normalen PC (wirklich mit exakt dem gleichen Framework - es ist das gleiche JAR, dieses enthält sowohl die Dalvik- als auch ide Java-Klassen, und ist somit auf beiden Plattformen ausführbar...), dann funktioniert das alles exakt so, wie es soll...

Ich sitze da inzw. einige Tage an diesem Problem, ich komme aber partout nicht weiter. Falls hier also jemand eine Idee oder einen Lösungsvprschlag hat - gerne her damit!

Danke & viele Grüsse,
Jan

Hallo,

Zitat von Kogoro

Ohne Codeausschnitt ist wahrscheinlich nicht viel zu machen.

Kann ich gerne noch einstellen - bringt aber denke ich nicht viel, da das dann recht viel Code wäre, der an sich an auch völlig korrekt ist (betreibe ich ihn in einem OSGi Framework unter "normalem" Java, z. B. auf einem PC, dann funktioniert dieser Code absolut problemlos). Erst, wenn er nach Dalvik überführt und auf Android bzw. in einem Framework unter Android ausgeführt wird gibt es Probleme. Diese treten exakt in dem Moment auf, wenn der Service (sprich: die Java-Klasse) instanziiert wird, in dessen Methodensignaturen javax.security.auth.Subjects mit übergeben werden können (und zwar wirklich beim Instanziieren dieser Klasse, nicht etwa erst beim Aufruf einer dieser Methoden...

Zitat von Kogoro

Außerdem wäre ein Link zum Framework nett.
Ansonsten sagt der Logcat nur, dass dort ein Fehler ist:
unable to find class referenced in signature (Ljavax/security/auth/Subject

Getestet habe ich das mit a) Felix ( http://felix.apache.org/site/a…k-and-google-android.html ) und b) dem ProSyst mBS Mobile ( http://www.prosyst.com/index.p…9/mBS-Mobile-for-Android/ ). Der Fehler tritt mit beiden Frameworks auf, allerdings in leicht unterschiedlichen Ausprägungen: bei Felix kommt er erst, wenn auch wirklich die Instanz der o.g. Klasse (des Services) erzeugt wird, d.h. starte ich da einfach nur das Bundle, und kommentiere das Instanziieren des Services aus, passiert nichts; das mBS Mobile Framework stürzt direkt beim Installieren / Starten des Bundles ab. Das liegt m. E. nach aber eher daran, dass dieses Framework evtl. direkt beim Starten überprüft, wie es denn so mit den benötigten Klassen aussieht, und dann eben das javax.security.auth.Subject nicht geladen bekommt. Felix scheint das nicht zu prüfen, sondern erst "im Falle des Falles" zu laden (denke ich, andern kann ich mir das Verhalten nicht erklären.

Ich verstehe halt nicht wirklich, warum diese Klasse (das Subject) nicht gefunden wird - in der Dalvik VM ist diese verfügbar (versch. javax.*-Klassen sind dort AFAIK ausgelassen, gerade diese aber nicht). Schaut man sich bspws. das Log des mBS Mobile an, dann sieht man auch, dass das Laden dieser Klasse an die Dalvik VM delegiert wird, diese die Klasse anscheinend auch lädt, aber dann *irgendwie* die Rückgabe schiefzugehen scheint:

03-24 08:31:04.976: INFO/System.out(243): fw>$[COMPONENTMANAGER_ACTIVATOR] Registering ComponentManager-Services...
03-24 08:31:05.056: INFO/mBS(243): Cannot load class: javax/security/auth/Subject from /data/data/com.prosyst.mbs.mobile.android/app_mbs/lib/serverandroid.jar
03-24 08:31:05.056: DEBUG/mBS(243): [DalvikClassLoader] Loaded class from boot class loader: class javax.security.auth.Subject
03-24 08:31:05.066: INFO/mBS(243): Cannot load class: javax/security/auth/Subject from /data/data/com.prosyst.mbs.mobile.android/app_mbs/bin/vms/dalvikvm/storage/bundles/8^1^OSAmI-Binding-API_1.0.0.jar
03-24 08:31:05.226: INFO/DEBUG(31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-24 08:31:05.226: INFO/DEBUG(31): Build fingerprint: 'generic/sdk/generic/:2.2/FRF91/43546:eng/test-keys'
03-24 08:31:05.226: INFO/DEBUG(31): pid: 243, tid: 377 >>> com.prosyst.mbs.mobile.android:mbsservice <<<
03-24 08:31:05.226: INFO/DEBUG(31): signal 11 (SIGSEGV), fault addr 00000024

(die folgenden Zeilen mit der Fehlermeldung spare ich mir mal, da kommen Registernummern oder sowas...)

Inzw. hab ich testweise mal eine Version des Services / der Klasse gebaut, bei denen alle Subjects in den Methodensignaturen stumpf zu Objects refactored wurden - diese Version lässt sich dann ganz normal instanziieren, starten, und auch nutzen; dabei stürzt nichts ab. Ist natürlich leider keine Lösung, da hier dann auch Funktionsumfang verlorengegangen ist - und vor allem ist es ja gerade unser Ziel, auf allen Plattformen identische Bundles (mal abgesehen von z. B. der Umwandlung nach Dalvik) einsetzen zu können. Das ist dann ja nicht mehr gegeben...