Closed
Bug 571254
Opened 14 years ago
Closed 14 years ago
Crash in [@ getMallocMapped]
Categories
(Core :: General, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
fennec | 1.1+ | --- |
People
(Reporter: mfinkle, Assigned: cjones)
Details
Attachments
(1 file)
480 bytes,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
When trying to load about:memory into Fennec, I get the following crash: #0 0xb778c832 in ?? () from /lib/ld-linux.so.2 #1 0xb5758a76 in nanosleep () from /lib/tls/i686/cmov/libc.so.6 #2 0xb5758891 in sleep () from /lib/tls/i686/cmov/libc.so.6 #3 0xb5b3ddc9 in ah_crap_handler (signum=11) at /home/mfinkle/Source/mozilla-trunk/mozilla/toolkit/xre/nsSigHandlers.cpp:132 #4 0xb5b3fe7e in nsProfileLock::FatalSignalHandler (signo=11, info=0xbff928ec, context=0xbff9296c) at nsProfileLock.cpp:221 #5 <signal handler called> #6 0xb7799347 in ?? () from /lib/ld-linux.so.2 #7 0xb779efc0 in ?? () from /lib/ld-linux.so.2 #8 0xb6e277d5 in getMallocMapped () at /home/mfinkle/Source/mozilla-trunk/mozilla/xpcom/base/nsMemoryReporterManager.cpp:78 #9 0xb6e289c8 in MemoryReporter_MallocMapped::GetMemoryUsed (this=0x9536278, memoryUsed=0xbff92e48) at /home/mfinkle/Source/mozilla-trunk/mozilla/xpcom/base/nsMemoryReporterManager.cpp:136 #10 0xb6e297c9 in NS_InvokeByIndex_P () at /home/mfinkle/Source/mozilla-trunk/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:69 #11 0xb684d0a9 in CallMethodHelper::Invoke (this=0xbff92e24) at /home/mfinkle/Source/mozilla-trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2983 #12 0xb684b392 in CallMethodHelper::Call (this=0xbff92e24) at /home/mfinkle/Source/mozilla-trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2308 #13 0xb68472b6 in XPCWrappedNative::CallMethod (ccx=..., mode=XPCWrappedNative::CALL_GETTER) at /home/mfinkle/Source/mozilla-trunk/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2272 #14 0xb6858fa3 in XPCWrappedNative::GetAttribute (ccx=...) at /home/mfinkle/Source/mozilla-trunk/mozilla/js/src/xpconnect/src/xpcprivate.h:2565 #15 0xb68576a7 in XPC_WN_GetterSetter (cx=0x9994540, obj=0xabb673a0, argc=0, argv=0xb2b43178, vp=0xb2b43198) at /home/mfinkle/Source/mozilla-trunk/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1833 #16 0xb545d89a in js_Invoke (cx=0x9994540, args=..., flags=2) at /home/mfinkle/Source/mozilla-trunk/mozilla/js/src/jsinterp.cpp:654 #17 0xb545daad in js_InternalInvoke (cx=0x9994540, obj=0xabb673a0, fval=-1414104576, flags=0, argc=0, argv=0x0, rval=0xbff936d0) at /home/mfinkle/Source/mozilla-trunk/mozilla/js/src/jsinterp.cpp:694
Reporter | ||
Comment 1•14 years ago
|
||
This happens in a Linux 32bit desktop build
looks like jemalloc_stats is crashing, or maybe the weak symbol is null?
Assignee | ||
Comment 3•14 years ago
|
||
What's your mozconfig? Did you build against e10s or m-c?
Reporter | ||
Comment 4•14 years ago
|
||
(In reply to comment #3) > What's your mozconfig? Did you build against e10s or m-c? # Options for client.mk. mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../mobile-debug mk_add_options MOZ_MAKE_FLAGS=-j3 # Global options ac_add_options --enable-debug ac_add_options --enable-tests ac_add_options --disable-optimize ac_add_options --enable-application=mobile # e10s ac_add_options --disable-ipc I am building against mozilla-central
Assignee | ||
Comment 5•14 years ago
|
||
The problem was that mobile/app wasn't statically linking with jemalloc even though MOZ_MEMORY was set. So the memory reporting code thought it had jemalloc when it actually didn't.
Assignee: nobody → jones.chris.g
Assignee | ||
Updated•14 years ago
|
Attachment #450578 -
Flags: review?(mark.finkle)
Reporter | ||
Comment 6•14 years ago
|
||
Comment on attachment 450578 [details] [diff] [review] Use jemalloc for linux/fennec I see Firefox does the same thing.
Attachment #450578 -
Flags: review?(mark.finkle) → review+
Assignee | ||
Comment 7•14 years ago
|
||
http://hg.mozilla.org/mobile-browser/rev/92c4a66b8e25
Status: NEW → RESOLVED
tracking-fennec: --- → ?
Closed: 14 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 8•14 years ago
|
||
Stuart, We need to make sure that we are shipping Fennec 1.1 with jemalloc enabled. It looks like we stopped using jemalloc when we switched to a non-xulrunner build.
Updated•14 years ago
|
tracking-fennec: ? → 1.1+
Comment 9•14 years ago
|
||
Will a load of about:memory on the n900 with no crash be sufficient to verify this? I couldn't find another way, on the nets, to test this.
Assignee | ||
Comment 10•14 years ago
|
||
Yep. (Note that since desktop builds had the same bug, you could check one of those too.)
Comment 11•14 years ago
|
||
alright, verified FIXED on builds: Mozilla/5.0 (X11; U; Linux armv71; Nokia N900; en-US; rv:1.9.3a6pre) Gecko/2010615 Namoroka/3.7a6pre Fennec/2.0a1pre Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2.5) Gecko/20100614 Namoroka/3.6.5pre Fennec/1.1 Mozilla/5.0 (X11; U; Linux i686; Nokia N900; en-US; rv:1.9.2.5) Gecko/20100614 Namoroka/3.6.5pre Fennec/1.1
Status: RESOLVED → VERIFIED
Comment 12•14 years ago
|
||
Could this have caused the Tdhtml increase on "Nokia n810 mobile"? Or is that just noise?
Reporter | ||
Comment 13•14 years ago
|
||
(In reply to comment #12) > Could this have caused the Tdhtml increase on "Nokia n810 mobile"? Or is that > just noise? Very likely. I also see Ts regressions (~1sec) on mobile-1.1 and mobile-browser. Of course, mobile-browser is in flux because of introducing the messagemanager, preparing for e10s. I don't think we want to drop jemalloc though. Stuart can make the final call.
You need to log in
before you can comment on or make changes to this bug.
Description
•