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
