Re: xulrunner 10, je_malloc_usable_size_in_advance
On Mar 13, 3:36 pm, Mike Hommey 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 0x in ?? ()
> > >#1 0x7310ca8b in mozilla::storage::(anonymous
> > >namespace)::sqliteMemRoundup (n=)
> > > 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 0x7fffec7e42fb in ?? ()
> > > from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> > >#3 0x7fffec7e43c9 in ?? ()
> > > from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> > >#4 0x7fffec7e441d in ?? ()
> > > from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> > >#5 0x7fffec7e446f in ?? ()
> > > from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> > >#6 0x7fffec7ed45e in sqlite3_initialize ()
> > > from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> > >#7 0x7310e45a 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 0x7310e741 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
Re: xulrunner 10, je_malloc_usable_size_in_advance
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 0x in ?? ()
> >#1 0x7310ca8b in mozilla::storage::(anonymous
> >namespace)::sqliteMemRoundup (n=)
> > 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 0x7fffec7e42fb in ?? ()
> >from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> >#3 0x7fffec7e43c9 in ?? ()
> >from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> >#4 0x7fffec7e441d in ?? ()
> >from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> >#5 0x7fffec7e446f in ?? ()
> >from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> >#6 0x7fffec7ed45e in sqlite3_initialize ()
> >from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
> >#7 0x7310e45a 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 0x7310e741 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
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
Re: xulrunner 10, je_malloc_usable_size_in_advance
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 0x in ?? ()
#1 0x7310ca8b in mozilla::storage::(anonymous
namespace)::sqliteMemRoundup (n=)
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 0x7fffec7e42fb in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#3 0x7fffec7e43c9 in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#4 0x7fffec7e441d in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#5 0x7fffec7e446f in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#6 0x7fffec7ed45e in sqlite3_initialize ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#7 0x7310e45a 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 0x7310e741 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
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
___
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
Re: xulrunner 10, je_malloc_usable_size_in_advance
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 0x in ?? ()
#1 0x7310ca8b in mozilla::storage::(anonymous
namespace)::sqliteMemRoundup (n=)
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 0x7fffec7e42fb in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#3 0x7fffec7e43c9 in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#4 0x7fffec7e441d in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#5 0x7fffec7e446f in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#6 0x7fffec7ed45e in sqlite3_initialize ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#7 0x7310e45a 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 0x7310e741 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
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
xulrunner 10, je_malloc_usable_size_in_advance
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 0x in ?? ()
#1 0x7310ca8b in mozilla::storage::(anonymous
namespace)::sqliteMemRoundup (n=)
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 0x7fffec7e42fb in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#3 0x7fffec7e43c9 in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#4 0x7fffec7e441d in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#5 0x7fffec7e446f in ?? ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#6 0x7fffec7ed45e in sqlite3_initialize ()
from /home/adam/prefix/lib/xulrunner-10.0.2/libmozsqlite3.so
#7 0x7310e45a 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 0x7310e741 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
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
