Thanks for the tip. That address was in system/lib/libc.so 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
