On Mar 13, 3:36 pm, Mike Hommey <mhom...@mozilla.com> wrote:
> On Tue, Mar 13, 2012 at 10:27:35AM -0400, Benjamin Smedberg wrote:
> > On 3/13/2012 10:09 AM, Adam Dickmeiss wrote:
> > >We have an application that has been working well since 1.9 through 9,
> > >but in Xulrunner 10 we get a crash , on Linux, 64-bit.
>
> > >#0  0x0000000000000000 in ?? ()
> > >#1  0x00007ffff310ca8b in mozilla::storage::(anonymous
> > >namespace)::sqliteMemRoundup (n=<optimized out>)
> > >     at /home/adam/proj/mozilla/ftp.mozilla.org/pub/mozilla.org/
> > >xulrunner/releases/10.0.2/source/mozilla-release/storage/src/
> > >mozStorageService.cpp:370
> > >#2  0x00007fffec7e42fb in ?? ()
> > >    from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> > >#3  0x00007fffec7e43c9 in ?? ()
> > >    from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> > >#4  0x00007fffec7e441d in ?? ()
> > >    from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> > >#5  0x00007fffec7e446f in ?? ()
> > >    from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> > >#6  0x00007fffec7ed45e in sqlite3_initialize ()
> > >    from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> > >#7  0x00007ffff310e45a in mozilla::storage::Service::initialize
> > >(this=0xe64f00)
> > >     at /home/adam/proj/mozilla/ftp.mozilla.org/pub/mozilla.org/
> > >xulrunner/releases/10.0.2/source/mozilla-release/storage/src/
> > >mozStorageService.cpp:418
> > >#8  0x00007ffff310e741 in mozilla::storage::Service::getSingleton ()
> > >     at /home/adam/proj/mozilla/ftp.mozilla.org/pub/mozilla.org/
> > >xulrunner/releases/10.0.2/source/mozilla-release/storage/src/
> > >mozStorageService.cpp:244
>
> > >Seems that the call to je_malloc_usable_size_in_advance fails.
>
> > >mozStorageService.cpp also reads:
>
> > >// jemalloc is directly linked into firefox-bin; libxul doesn't link
> > >// with it.  So if we tried to use je_malloc_usable_size_in_advance
> > >directly
> > >// here, it wouldn't be defined.  Instead, we don't include the
> > >jemalloc header
> > >// and weakly link against je_malloc_usable_size_in_advance.
> > >extern "C" {
> > >extern size_t je_malloc_usable_size_in_advance(size_t size)
> > >   NS_VISIBILITY_DEFAULT __attribute__((weak));
> > >}
>
> > >So tried to see where THAT was defined.. Seems to be in libmozutils.a
> > >which Is NOT installed by 'make -f client.mk install'.
>
> > >Fortunately linking with that library seems to solve our immediate
> > >problem, but not an ideal situation.
>
> > Since we have very little automated testing of Mozilla outside of
> > the normal XUL launch environment, this is I think just a bug. On
> > Linux, we do not expect that all embedders are going to link against
> > jemalloc/mozutils, and so Mozilla code should expect that jemalloc-
> > or mozutils-specific symbols may not be present. Feel free to fix
> > this.
>
> > Your workaround of linking mozutils to pick up jemalloc seems like a
> > good solution for now.
>
> There is an open bug for that particular 
> one:https://bugzilla.mozilla.org/show_bug.cgi?id=720682
>
> Considering how things are evolving, I think libmozglue.a (what used to be
> libmozutils.a) should be shipped in the sdk in two flavours: one with and
> one without jemalloc, and be linked as we require the xpcom glue to be
> linked.
>
> Mike

Thanks for the answers and pointers everyone.

/ Adam
_______________________________________________
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding

Reply via email to