Closed
Bug 603547
Opened 14 years ago
Closed 14 years ago
Mac+Windows Nightly builds crash on loading remote content
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(fennec2.0b2+)
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
fennec | 2.0b2+ | --- |
People
(Reporter: dougt, Assigned: jdm)
Details
(Keywords: crash)
Attachments
(1 file, 1 obsolete file)
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 PL_DHashTableOperate (table=0x0, key=0x7fff5fbfa770, op=PL_DHASH_ADD) at pldhash.c:615 615 keyHash = table->ops->hashKey(table, key); (gdb) bt #0 PL_DHashTableOperate (table=0x0, key=0x7fff5fbfa770, op=PL_DHASH_ADD) at pldhash.c:615 #1 0x000000010002e0fc in nsBaseHashtable<nsCStringHashKey, nsCString, nsCString>::Put () at /builds/mozilla/mozilla-central/objdir/dist/include/nsBaseHashtable.h:983 #2 0x000000010002e0fc in CrashReporter::AnnotateCrashReport (key=@0x7fff5fbfa770, data=@0x7fff5fbfa840) at nsBaseHashtable.h:983 #3 0x0000000100000012 in ?? () The mozconfig being used right now is: http://hg.mozilla.org/build/buildbot-configs/file/cecf06b9166e/mozilla2/mobile/macosx-i686/mobile-browser/nightly/mozconfig Maybe we should be disabling the crash reporter? I usually do: ac_add_options --disable-crashreporter And that seems to resolve this problem, but not sure if that is what we want.
Comment 1•14 years ago
|
||
Hm. If we had a little more stack that would be helpful. Can you repro on a local build? Clearly something is busted there, since the pld hash is NULL.
Assignee | ||
Comment 2•14 years ago
|
||
Here's the stack with symbols attached: #0 PL_DHashTableOperate (table=0x0, key=0xbfffca34, op=PL_DHASH_ADD) at pldhash.c:615 #1 0x000297c1 in nsBaseHashtable<nsCStringHashKey, nsCString, nsCString>::Put () at :983 #2 0x000297c1 in CrashReporter::AnnotateCrashReport (key=@0xbfffca34, data=@0xbfffc9e0) at nsBaseHashtable.h:983 #3 0x00000017 in ?? ()
Comment 3•14 years ago
|
||
Hrm. That's still not very useful. I wonder why the stack doesn't unwind all the way? I asked Josh on IRC to try single-stepping through XRE_main, that might prove more useful. Doug: was your build --disable-optimize? If not, you might try that to see if it helps get a better stack.
Assignee | ||
Comment 4•14 years ago
|
||
Hmm, building with --enable-crashreporter didn't trigger the crash for me.
Reporter | ||
Updated•14 years ago
|
OS: Mac OS X → All
Summary: Mac Nightly builds crash on loading remote content → Mac+Windows Nightly builds crash on loading remote content
Assignee | ||
Comment 5•14 years ago
|
||
So I've built with the 10.5 SDK, and with the crash reporter enabled and MOZILLA_OFFICIAL=1, and I still can't reproduce the crash in my own builds. Curiouser and curiouser.
Reporter | ||
Comment 6•14 years ago
|
||
okay... in the child process, AnnotateCrashReport is called: #0 CrashReporter::AnnotateCrashReport (key=@0x7fff5fbfb5e0, data=@0x7fff5fbfb6b0) at /builds/mozilla/mozilla-central/toolkit/crashreporter/nsExceptionHandler.cpp:983 #1 0x0000000100fecf52 in mozilla::widget::GfxInfo::AddCrashReportAnnotations (this=0x105740920) at /builds/mozilla/mozilla-central/widget/src/cocoa/GfxInfo.mm:169 #2 0x0000000100fed2a4 in mozilla::widget::GfxInfo::Init (this=0x105740920) at /builds/mozilla/mozilla-central/widget/src/cocoa/GfxInfo.mm:93 crashReporterAPIData_Hash is null. (gdb) p crashReporterAPIData_Hash $4 = (AnnotationTable *) 0x0 The only place this hash is initialized is in SetExceptionHandler() which is never called in the child. I am not exactly clear on how the crash report works in the child process. Is the expectation that AnnotateCrashReport() should work in the child?
Comment 7•14 years ago
|
||
No, AnnotateCrashReport doesn't work in the child process currently. We should make that work at some point, probably before shipping Fennec with OOP content. We worked around this same thing in bug 578952, I guess this is a different call site we're hitting?
Comment 8•14 years ago
|
||
The simple fix would be to wrap that call in GfxInfo::AddCrashReportAnnotations in: if (CrashReporter::GetEnabled()) { }
Comment 9•14 years ago
|
||
Could we add a central check in CrashReporter::AnnotateCrashReport? There are plenty of places which annotate, and I'd like to avoid patching each one separately.
Comment 10•14 years ago
|
||
Yeah, that's probably the smarter thing to do.
Reporter | ||
Updated•14 years ago
|
tracking-fennec: --- → 2.0b2+
Assignee | ||
Comment 11•14 years ago
|
||
Assignee | ||
Updated•14 years ago
|
Attachment #482930 -
Flags: review?(ted.mielczarek)
Updated•14 years ago
|
Attachment #482930 -
Flags: review?(ted.mielczarek) → review+
Updated•14 years ago
|
Assignee: nobody → doug.turner
Assignee | ||
Updated•14 years ago
|
Assignee: doug.turner → josh
Assignee | ||
Updated•14 years ago
|
Attachment #482930 -
Attachment is obsolete: true
Assignee | ||
Comment 12•14 years ago
|
||
I found another instance where we'll want to avoid if not enabled. This is the patch I'm pushing.
Comment 13•14 years ago
|
||
Comment on attachment 482930 [details] [diff] [review] Short-circuit annotation attempts if crash reporter is not enabled. Just change that check to if (!GetEnabled()), since GetEnabled checks gExceptionHandler anyway.
Assignee | ||
Comment 14•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/dc076e50f4f8
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
verified : Mozilla/5.0 (Maemo;Linux armv71; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre Fennec/4.0b2pre Mozilla/5.0 (Android; Linux armv71; rv2.0b8pre) Gecko/20101015 Firefox/4.0b8pre Fennec/4.0b2pre Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre Fennec/4.0b2pre Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101015 Firefox/4.0b8pre Fennec/4.0b2pre Mozilla/5.0 (X11; Linux i686; rv:2.0bpre) Gecko/20101015 Firefox/4.0b8pre Fennec/4.0b2pre No content crashes with simple going to URL. I saw a content crash for another reason, but I can't figure it out as of yet on the Mac side.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•