Just to update. The reason exceptions are causing an abort, despite being caught inside the library, is because the Gecko custom linker lacks a particular function that the system linker implements.
Exceptions should start working in external libraries once Bug 930627 implements that function. Cheers, Jim On 10/22/13 2:35 PM, Carl Wallace wrote: > The shared library list is interesting. There are four different STLs > loaded: stdc++, gabi, stlport and gnustl. The latter is loaded by my > extension. > > /system/lib/libstdc++.so > /system/lib/libgabi++.so > /system/lib/libstlport.so > /system/lib/libgnustl_shared.so > > I can step into a std::runtime_error exception inside the gnustl library > prior to the libc crash. To simplify the test, I changed the throw > statement to just throw an integer and the behavior is unchanged. The > last step before the crash is this: > > 433 throw 20; > (gdb) n > > Program received signal SIGSEGV, Segmentation fault. > 0x4012e1ba in ?? () from /jimdb-arm/lib/0A3BFB5607008011/system/lib/libc.so > > > > On 10/22/13 2:04 PM, "Carl Wallace" <[email protected]> wrote: > >> The stack immediately before the crash looks like this: >> >> Breakpoint 1, PKCS11Object::getAttributeValue (this=0x5179f728, >> pTemplate=0x53ad7f68, ulCount=2, log=0x51bcd068) at object.cpp:424 >> 424 { >> (gdb) bt >> #0 PKCS11Object::getAttributeValue (this=0x5179f728, >> pTemplate=0x53ad7f68, ulCount=2, log=0x51bcd068) at object.cpp:424 >> #1 0x51926c58 in Slot::getAttributeValue (this=0x5121e1d0, suffix=..., >> hObject=2, pTemplate=0x53ad7f68, ulCount=2) at slot.cpp:3442 >> #2 0x51926ab0 in SlotList::getAttributeValue (this=0x517a0468, >> hSession=16777218, hObject=2, pTemplate=0x53ad7f68, ulCount=2) at >> slot.cpp:3422 >> #3 0x51914270 in C_GetAttributeValue (hSession=16777218, hObject=2, >> pTemplate=0x53ad7f68, ulCount=2) at coolkey.cpp:636 >> #4 0x5649823e in NSSDBGC_GetAttributeValue (hSession=16777218, hObject=2, >> pTemplate=0x53ad7f68, ulCount=2) at debug_module.c:1484 >> #5 0x564cae1e in nssCKObject_GetAttributes (object=2, >> obj_template=0x53ad7f68, count=2, arenaOpt=0x0, session=0x683e4978, >> slot=0x683e8018) at ckhelper.c:85 >> #6 0x564cecaa in nssCryptokiObject_Create (t=0x683e7818, >> session=0x683e4978, h=2) at devutil.c:29 >> #7 0x564cc6b2 in create_objects_from_handles (tok=0x683e7818, >> session=0x683e4978, handles=0x53ad7fd8, numH=3) at devtoken.c:239 >> #8 0x564cc882 in find_objects (tok=0x683e7818, sessionOpt=0x0, >> obj_template=0x53ad8064, otsize=2, maximumOpt=10, statusOpt=0x53ad80ac) at >> devtoken.c:346 >> #9 0x564cd10c in nssToken_FindObjects (token=0x683e7818, sessionOpt=0x0, >> objclass=1, searchType=nssTokenSearchType_TokenForced, maximumOpt=10, >> statusOpt=0x53ad80ac) at devtoken.c:594 >> #10 0x564cf54a in get_token_objects_for_cache (cache=0x6833fe48, >> objectType=0, objclass=1) at devutil.c:571 >> #11 0x564cf900 in nssTokenObjectCache_FindObjectsByTemplate >> (cache=0x6833fe48, objclass=1, otemplate=0x53ad8148, otlen=4, >> maximumOpt=1, statusOpt=0x53ad8110) at devutil.c:736 >> #12 0x564cca4c in find_objects_by_template (token=0x683e7818, >> sessionOpt=0x0, obj_template=0x53ad8148, otsize=4, maximumOpt=1, >> statusOpt=0x0) at devtoken.c:420 >> #13 0x564cd83c in nssToken_FindCertificateByIssuerAndSerialNumber >> (token=0x683e7818, sessionOpt=0x0, issuer=0x68fa98b0, serial=0x68fa98c0, >> searchType=nssTokenSearchType_TokenOnly, statusOpt=0x0) at devtoken.c:844 >> #14 0x564c8e70 in nssTrustDomain_UpdateCachedTokenCerts (td=0x683e4818, >> token=0x683e7818) at tdcache.c:479 >> #15 0x5648e656 in PK11_DoPassword (slot=0x683bd000, session=16777218, >> loadCerts=0, wincx=0x52972090, alreadyLocked=0, contextSpecific=0) at >> pk11auth.c:626 >> #16 0x5648e0fe in PK11_Authenticate (slot=0x683bd000, loadCerts=0, >> wincx=0x52972090) at pk11auth.c:315 >> #17 0x5648e136 in pk11_AuthenticateUnfriendly (slot=0x683bd000, >> loadCerts=0, wincx=0x52972090) at pk11auth.c:330 >> #18 0x564a382a in pk11_TraverseAllSlots (callback=0x0, arg=0x0, >> forceLogin=1, wincx=0x52972090) at pk11obj.c:1865 >> #19 0x56479388 in CERT_GetCertNicknames (handle=0x683e4818, what=2, >> wincx=0x52972090) at certhigh.c:485 >> #20 0x56478ec0 in CERT_FindUserCertsByUsage (handle=0x683e4818, >> usage=certUsageSSLClient, oneCertPerName=0, validOnly=0, >> proto_win=0x52972090) at certhigh.c:90 >> #21 0x5cb3d5fa in ClientAuthDataRunnable::RunOnTargetThread >> (this=0x6789b1f0) at >> //mozilla-central/security/manager/ssl/src/nsNSSIOLayer.cpp:2330 >> #22 0x5cb506c8 in mozilla::psm::SyncRunnableBase::Run (this=0x6789b1f0) at >> //mozilla-central/security/manager/ssl/src/PSMRunnable.cpp:35 >> #23 0x5d610102 in nsThread::ProcessNextEvent (this=0x52902320, >> mayWait=false, result=0x53ad8867) at >> //mozilla-central/xpcom/threads/nsThread.cpp:622 >> #24 0x5d5aa220 in NS_ProcessNextEvent (thread=0x52902320, mayWait=false) >> at //mozilla-central/xpcom/glue/nsThreadUtils.cpp:238 >> #25 0x5cd95440 in mozilla::ipc::MessagePump::Run (this=0x52901d90, >> aDelegate=0x529670c0) at //mozilla-central/ipc/glue/MessagePump.cpp:81 >> #26 0x5d68e374 in MessageLoop::RunInternal (this=0x529670c0) at >> //mozilla-central/ipc/chromium/src/base/message_loop.cc:220 >> #27 0x5d68e316 in MessageLoop::RunHandler (this=0x529670c0) at >> //mozilla-central/ipc/chromium/src/base/message_loop.cc:213 >> #28 0x5d68e2be in MessageLoop::Run (this=0x529670c0) at >> //mozilla-central/ipc/chromium/src/base/message_loop.cc:187 >> #29 0x5cc94c2c in nsBaseAppShell::Run (this=0x52911060) at >> //mozilla-central/widget/xpwidgets/nsBaseAppShell.cpp:161 >> #30 0x5ca81156 in nsAppStartup::Run (this=0x63b62730) at >> //mozilla-central/toolkit/components/startup/nsAppStartup.cpp:269 >> #31 0x5b70e66a in XREMain::XRE_mainRun (this=0x53ad8af0) at >> //mozilla-central/toolkit/xre/nsAppRunner.cpp:3869 >> #32 0x5b70e880 in XREMain::XRE_main (this=0x53ad8af0, argc=9, >> argv=0x52936148, aAppData=0x50e85d90 <sAppData>) at >> //mozilla-central/toolkit/xre/nsAppRunner.cpp:3937 >> #33 0x5b70ea16 in XRE_main (argc=9, argv=0x52936148, aAppData=0x50e85d90 >> <sAppData>, aFlags=0) at >> //mozilla-central/toolkit/xre/nsAppRunner.cpp:4139 >> #34 0x5b7028fa in GeckoStart (data=0x5294a1a0, appData=0x50e85d90 >> <sAppData>) at //mozilla-central/toolkit/xre/nsAndroidStartup.cpp:73 >> #35 0x50e10c3c in Java_org_mozilla_gecko_mozglue_GeckoLoader_nativeRun >> (jenv=0x510efb98, jc=0x22800001, jargs=0x21e00005) at >> //mozilla-central/mozglue/android/APKOpen.cpp:379 >> #36 0x40915ef4 in dvmPlatformInvoke () from >> //jimdb-arm/lib/0A3BFB5607008011/system/lib/libdvm.so >> #37 0x409451ae in dvmCallJNIMethod(unsigned int const*, JValue*, Method >> const*, Thread*) () from >> //jimdb-arm/lib/0A3BFB5607008011/system/lib/libdvm.so >> #38 0x409472c8 in dvmResolveNativeMethod(unsigned int const*, JValue*, >> Method const*, Thread*) () from >> //jimdb-arm/lib/0A3BFB5607008011/system/lib/libdvm.so >> #39 0x4091f324 in dvmJitToInterpNoChain () from >> //jimdb-arm/lib/0A3BFB5607008011/system/lib/libdvm.so >> #40 0x4091f324 in dvmJitToInterpNoChain () from >> //jimdb-arm/lib/0A3BFB5607008011/system/lib/libdvm.so >> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >> >> >> >> Stepping past the throw statement results in the stack below referencing >> an address in libc. The throw sits inside a try/catch including a >> catch(...). >> >> On 10/22/13 1:39 PM, "Jim Chen" <[email protected]> wrote: >> >>> What library is 0x4012e1ba in? If you run 'info sharedlibrary' you can >>> see the library that 0x4012e1ba belongs to. >>> >>> >>> On 10/22/13 1:36 PM, Carl Wallace wrote: >>>> I did not try GAbi++ since I need standard library support. There is >>>> no >>>> useful stack (below) at the point of the crash. >>>> >>>> >>>> (gdb) bt >>>> #0 0x4012e1ba in ?? () >>>> #1 0x40131b18 in ?? () >>>> #2 0x40131b18 in ?? () >>>> Backtrace stopped: previous frame identical to this frame (corrupt >>>> stack?) >>>> >>>> >>>> >>>> On 10/22/13 1:23 PM, "Jim Chen" <[email protected]> wrote: >>>> >>>>> Yes, dynamic header type #f (i.e. 15) is DT_RPATH [1], so not likely >>>>> related. >>>>> >>>>> Do you get other messages or a stack with the crash? Have you tried >>>>> the GAbi++ runtime [2] (assuming you don't need additional >>>>> functionality that stlport/gnustl provides? >>>>> >>>>> Jim >>>>> >>>>> >>>>> [1] http://www.sco.com/developers/gabi/latest/ch5.dynamic.html >>>>> >>>>> [2] >>>>> >>>>> http://androidxref.com/4.3_r2.1/xref/ndk/docs/CPLUSPLUS-SUPPORT.html#75 >>>>> >>>>> >>>>> On 10/22/13 1:12 PM, Carl Wallace wrote: >>>>>> To self-reply and top post, I got rid of the dynamic header type #f >>>>>> not >>>>>> handled warnings by omitting rpath in the library. Still crash on >>>>>> throw >>>>>> though. >>>>>> >>>>>> On 10/22/13 11:46 AM, "Carl Wallace" <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> I am continuing my effort to get exception handling working with an >>>>>>> external library. Here's a summary of current status. Any help is >>>>>>> welcome. >>>>>>> >>>>>>> I have a restartless extension (.xpi file) that installs modutil, >>>>>>> pcscd >>>>>>> and coolkey. The modutil utility is from the Fennec build, the >>>>>>> other >>>>>>> two >>>>>>> are external to the Mozilla build. The extension may need to be a >>>>>>> non-restartless extension ultimately but for now it is restartless. >>>>>>> The >>>>>>> rough actions performed by the extension are as follows: >>>>>>> >>>>>>> 1) Copy binaries and a few library files to fennec/bin. I could not >>>>>>> run >>>>>>> the binaries from the folder within the extension but execution from >>>>>>> a >>>>>>> newly created bin folder works fine. The extension also sets up >>>>>>> folders >>>>>>> and copies configuration files required by pcscd. >>>>>>> 2) During installation the extension starts pcscd and uses modutil >>>>>>> to >>>>>>> register an sdcard with the NSS store used by Fennec during the >>>>>>> installation. Exceptions are thrown and caught successfully during >>>>>>> this >>>>>>> registration. >>>>>>> 3) During browser start-up, the extension starts pcscd and adds the >>>>>>> bin >>>>>>> folder to LD_LIBRARY_PATH. >>>>>>> 4) When browsing to a page that requires TLS client authentication, >>>>>>> the >>>>>>> browser loads the coolkey library which interacts with the pcscd >>>>>>> service. >>>>>>> A PIN prompt is displayed then the application crashes when an >>>>>>> exception >>>>>>> is thrown inside the coolkey library. >>>>>>> >>>>>>> The exception is part of a throw/catch I added to libcoolkey to make >>>>>>> sure >>>>>>> I always hit an exception until this is resolved. The libcoolkey >>>>>>> library >>>>>>> is linked against gnustl_shared. The .so is installed by the >>>>>>> extension. >>>>>>> I know this .so is loaded as the behavior when I move the .so file >>>>>>> is >>>>>>> different (I am not prompted for a PIN and the browsers continues to >>>>>>> an >>>>>>> error page displayed by the server). Initially I was using NDK n8e >>>>>>> but >>>>>>> have also tried with n9. >>>>>>> >>>>>>> I noticed the following warnings in logcat shortly before a crash: >>>>>>> >>>>>>> E GeckoLinker: >>>>>>> /data/data/org.mozilla.fennec_cwallace/bin/libcoolkeypk11.so: >>>>>>> Warning: >>>>>>> dynamic header type #f not handled >>>>>>> E GeckoLinker: >>>>>>> /data/data/org.mozilla.fennec_cwallace/bin/libcoolkeypk11.so: >>>>>>> Warning: >>>>>>> unhandled flags #8 not handled >>>>>>> >>>>>>> >>>>>>> Several NSS libraries also generate the unhandled flags warning, but >>>>>>> the >>>>>>> dynamic header type warning only appears for the library that is >>>>>>> causing >>>>>>> the crash. Are these warnings problematic? It seems strange that >>>>>>> exceptions are thrown/caught when the library is loaded by modutil, >>>>>>> but >>>>>>> not when loaded by the browser. >>>>>>> >>>>>>> I have tried using gnustl and stlport in both static and shared >>>>>>> forms. >>>>>>> When using stlport (static or shared), the coolkey library cannot be >>>>>>> loaded with the following error: >>>>>>> >>>>>>> "Cannot load library: reloc_library[1310]: 5237 cannot locate >>>>>>> '_ZNSsD1Ev'? >>>>>>> >>>>>>> As above, I confirmed the shared version of stlport is being used by >>>>>>> moving the library and observing a different error. Unlike the >>>>>>> gnustl >>>>>>> behavior, I am unable to load libcoolkey into modutil when it is >>>>>>> linked >>>>>>> against stlport. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mobile-firefox-dev mailing list >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>>>>> >>>> >>>> >> >> > > _______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
