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)

x86
All
defect
Not set
normal

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.
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.
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 ?? ()
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.
Hmm, building with --enable-crashreporter didn't trigger the crash for me.
OS: Mac OS X → All
Summary: Mac Nightly builds crash on loading remote content → Mac+Windows Nightly builds crash on loading remote content
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.
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?
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?
The simple fix would be to wrap that call in GfxInfo::AddCrashReportAnnotations in:
if (CrashReporter::GetEnabled()) { }
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.
Yeah, that's probably the smarter thing to do.
tracking-fennec: --- → 2.0b2+
Attachment #482930 - Flags: review?(ted.mielczarek)
Attachment #482930 - Flags: review?(ted.mielczarek) → review+
Assignee: nobody → doug.turner
Assignee: doug.turner → josh
Attachment #482930 - Attachment is obsolete: true
I found another instance where we'll want to avoid if not enabled. This is the patch I'm pushing.
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.
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.