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". >> 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? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
