On Thu, Oct 13, 2016 at 12:54 AM, Mike Hommey <m...@glandium.org> wrote:
> 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 ?? ()
>> 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.
Thank you. Indeed, the program runs after linking with stdc++
(dynamically), mozglue (statically) and xul (dynamically).
This has fun side effects like the libxul Rust panic machinery taking
dev-platform mailing list