Re: xulrunner 10, je_malloc_usable_size_in_advance

2012-03-13 Thread Mike Hommey
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=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  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

2012-03-13 Thread Adam Dickmeiss
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  0x in ?? ()
  #1  0x7310ca8b 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  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