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
