Closed Bug 571254 Opened 14 years ago Closed 14 years ago

Crash in [@ getMallocMapped]

Categories

(Core :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
fennec 1.1+ ---

People

(Reporter: mfinkle, Assigned: cjones)

Details

Attachments

(1 file)

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
This happens in a Linux 32bit desktop build
looks like jemalloc_stats is crashing, or maybe the weak symbol is null?
What's your mozconfig?  Did you build against e10s or m-c?
(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
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
Attachment #450578 - Flags: review?(mark.finkle)
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+
http://hg.mozilla.org/mobile-browser/rev/92c4a66b8e25
Status: NEW → RESOLVED
tracking-fennec: --- → ?
Closed: 14 years ago
Resolution: --- → FIXED
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.
tracking-fennec: ? → 1.1+
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.
Yep.  (Note that since desktop builds had the same bug, you could check one of those too.)
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
Could this have caused the Tdhtml increase on "Nokia n810 mobile"?  Or is that just noise?
(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.

Attachment

General

Created:
Updated:
Size: