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
