On Wed, Oct 12, 2016 at 04:42:14PM +0300, Henri Sivonen wrote: > On Tue, Oct 11, 2016 at 1:03 AM, Mike Hommey <m...@glandium.org> wrote: > > On Mon, Oct 10, 2016 at 06:24:33PM +0300, Henri Sivonen wrote: > >> For benchmarking purposes, I'd like to call uconv from a Rust > >> program. Since building uconv separately from Gecko hasn't really > >> been maintained, I figured that I'd export a small number of > >> C-linkage functions from libxul, dynamically link with libxul as > >> built as part of Linux x86_64 Firefox and call > >> NS_InitMinimalXPCOM() once before calling my exported test > >> functions. > >> > >> I can get Cargo to link my Rust program with libxul, but upon > >> running the program, it crashes immediately with "signal: 11, > >> SIGSEGV: invalid memory reference" even if I don't even try to call > >> into libxul at all. > > > > What is the stack trace for that crash? > > Sorry, I mistaked Cargo not dumping one as one not being dumpable. > Here's the stack when bypassing Cargo: > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () > #1 0x00007ffff3ca658b in > stagefright::List<stagefright::AString>::prep() [clone .isra.34] () > from ./firefox/libxul.so #2 0x00007ffff3ca723e in > stagefright::AAtomizer::AAtomizer() () from ./firefox/libxul.so #3 > 0x00007ffff3c8a69e in > _GLOBAL__sub_I_Unified_cpp_media_libstagefright1.cpp () from > ./firefox/libxul.so #4 0x00007ffff7de74ea in call_init (l=<optimized > out>, argc=argc@entry=2, argv=argv@entry=0x7fffffffdd58, > env=env@entry=0x7fffffffdd70) at dl-init.c:72 #5 0x00007ffff7de75fb > in call_init (env=0x7fffffffdd70, argv=0x7fffffffdd58, argc=2, > l=<optimized out>) at dl-init.c:30 #6 _dl_init > (main_map=0x7ffff7ffe168, argc=2, argv=0x7fffffffdd58, > env=0x7fffffffdd70) at dl-init.c:120 #7 0x00007ffff7dd7cfa in > _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #8 > 0x0000000000000002 in ?? () #9 0x00007fffffffe11a in ?? () #10 > 0x00007fffffffe16b in ?? () #11 0x0000000000000000 in ?? () > > https://dxr.mozilla.org/mozilla-central/source/media/libstagefright/system/core/include/utils/List.h#293 > shows C++ "new".
So it's a case of code you don't care about having static initializers that require stuff from libmozglue. It means you need to link libmozglue to your program if you want to use libxul. > >> Is there some easily-addressable obvious reason for the process > >> dying due to just dynamically linking with libxul without even > >> calling into it? Related to jemalloc and/or static initializers > >> maybe? (I'm expecting that if this was about duplicate symbols due > >> to two copies of the Rust standard library or jemalloc, the linker > >> would barf, but I'm not sure if that's a correct expectation.) > > > > Build libxul with jemalloc disabled for starters. > > OK. Thanks, but the backtrace is the same with jemalloc disabled. > > > That being said, ISTR there are or used to be uconv standalone tests > > that didn't require linking libxul, so you could also try to link > > uconv + xpcom. > > It seems that these got commented out > https://dxr.mozilla.org/mozilla-central/source/intl/uconv/tests/moz.build#9 > as incompatible with libxul. If I commented out those bits, what would > I do to request a non-libxul build of just that stuff? You'd need to create a static library with the required bits from uconv and xpcom. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
