See below :) >> I've attached a log file with the messages that are logged when I attempt a >> connection to my testbed environment. I'm pretty sure the "Caught >> segmentation >> fault" messages are unrelated, because a bunch of the same messages are >> logged >> before I attempt to establish a connection. I left them intact in case they >> have some meaning that I'm missing.
Yes, as long as there's no actual crash, the "Caught segmentation fault" messages can be ignored and are part of loading Gecko. >> My interpretation of the output is that ElfLoader class can't locate the >> libgssapi.so file. Looking at the source >> (http://mxr.mozilla.org/mozilla-central/source/mozglue/linker/ElfLoader.cpp#29 >> 6), I'd guess /data/data/org.mozilla.fennec_caleb/lib isn't a valid search >> path. I haven't found a way to manually modify the search path, though, so I >> can't test my hypothesis. Any ideas? >> > I initially ran into a failure to load similar to what is described above > but got past that by specifying the full path to the so file at load time. Like Nick said, it's tricky to load libraries within Gecko on Android. You basically have a choice between two linkers - the system linker and Gecko's custom linker. You use either one depending on the path given to PR_LoadLibrary / dlopen. The custom linker is capable of loading a library from the apk file directly without extracting the library first. However, in most cases it needs an absolute path and a special syntax [1]. When that's not satisfied, the fallback is the system linker which supports relative paths better. However, it doesn't support loading from apk's and I don't think the /lib directory is in the default search paths either. So when using a relative path to load a library in the apk's /assets directory, the load fails because the relative path doesn't follow the custom linker's requirements. On the other hand, when using a relative path to load a library in /lib, the load fails too because the /lib directory is not searched by the system linker. To work around the former, you can find the location of the apk and pass in an absolute path according to the syntax in [1]. See [2] for an example of doing this. To work around the latter, you can either add the /lib path to the LD_LIBRARY_PATH environment variable, or you can specify an absolute path to the /lib directory, either of which requires you knowing the Fennec package name. [1] To load a library in an apk, you would use the absolute path "/path/to/file.apk!/path/within/apk.so". For example, PR_LoadLibrary("/data/app/org.mozilla.fennec-1.apk!/assets/libwebkit.so") [2] This code finds the path that "libxul.so" was loaded from, which follows the custom linker's syntax. From there we can derive the target path, assuming the target library is in the same directory as "libxul.so". http://mxr.mozilla.org/mozilla-central/source/content/media/plugins/MediaPluginHost.cpp#198 > At this point, the so is loaded and invoked (at least enough so that I see a > PIN prompt for the card). After the PIN prompt, I hit a crash. In the log > I also see lots of "Caught segmentation fault" messages that do not appear > to cause a problem, until this final one: > > D GeckoLinker: Caught segmentation fault @0xdeadbaad > > I've been trying to figure out how to log a call stack at that point. There might be a stack of the crash in the 'adb logcat' output, but you should setup a GDB environment [3] if you want to debug it. [3] https://wiki.mozilla.org/Android/GDB Cheers, Jim _______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
