xulrunner 10, je_malloc_usable_size_in_advance

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

xulrunner 10, je_malloc_usable_size_in_advance

Adam Dickmeiss-2
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.

Any other success stories on embedding Xulrunner 10 on Linux?
_______________________________________________
dev-embedding mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-embedding
Reply | Threaded
Open this post in threaded view
|

Re: xulrunner 10, je_malloc_usable_size_in_advance

Martin Stransky
See https://bugzilla.mozilla.org/show_bug.cgi?id=720682

On 03/13/2012 03:09 PM, 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.
>
> Any other success stories on embedding Xulrunner 10 on Linux?
> _______________________________________________
> dev-embedding mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-embedding

_______________________________________________
dev-embedding mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-embedding
Reply | Threaded
Open this post in threaded view
|

Re: xulrunner 10, je_malloc_usable_size_in_advance

Benjamin Smedberg
In reply to this post by Adam Dickmeiss-2
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.

--BDS

_______________________________________________
dev-embedding mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-embedding
Reply | Threaded
Open this post in threaded view
|

Re: xulrunner 10, je_malloc_usable_size_in_advance

Mike Hommey-6
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
_______________________________________________
dev-embedding mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-embedding
Reply | Threaded
Open this post in threaded view
|

Re: xulrunner 10, je_malloc_usable_size_in_advance

Adam Dickmeiss-2
In reply to this post by Benjamin Smedberg
On Mar 13, 3:36 pm, Mike Hommey <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-embedding