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
