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
#3  0x00007ffff3c8a69e in
_GLOBAL__sub_I_Unified_cpp_media_libstagefright1.cpp () from
#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".

>> 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
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
dev-platform mailing list

Reply via email to