Closed Bug 127569 Opened 23 years ago Closed 23 years ago

Crash on going "back" to bugzilla bug page

Categories

(SeaMonkey :: General, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: john)

References

Details

Attachments

(1 file)

BUILD: Linux 2002-02-22-08 and Linux 2002-02-24-06 STEPS TO REPRODUCE: 1) Load a bug page 2) Try to reassign the bug to "aaaaaa" with no comment 3) When bugzilla demands a comment, hit "back" (alt-left or the back button) 4) Watch the crash Opt build claims to be crashing in #0 0x401a487c in nsString::SetLength () from /home/bzbarsky/mozilla/profile/mozilla/dist/bin/libxpcom.so #1 0x40872955 in nsGenericHTMLElement::GetAttr () from /home/bzbarsky/mozilla/profile/mozilla/dist/bin/components/libgkcontent.so #2 0x4092cacb in SelectorMatches () from /home/bzbarsky/mozilla/profile/mozilla/dist/bin/components/libgkcontent.so #3 0x4092de9f in ContentEnumFunc () from /home/bzbarsky/mozilla/profile/mozilla/dist/bin/components/libgkcontent.so #4 0x40926fac in RuleHash::EnumerateAllRules () from /home/bzbarsky/mozilla/profile/mozilla/dist/bin/components/libgkcontent.so #5 0x4092df54 in CSSRuleProcessor::RulesMatching () from /home/bzbarsky/mozilla/profile/mozilla/dist/bin/components/libgkcontent.so #6 0x40a29923 in EnumRulesMatching () from /home/bzbarsky/mozilla/profile/mozilla/dist/bin/components/libgkcontent.so #7 0x40133fb6 in nsSupportsArray::EnumerateForwards () Debug build claims to be crashing in: #0 0x40301a26 in PL_HashTableRawLookup (ht=0x809dbf0, keyHash=3836752349, key=0x41436f21) at plhash.c:186 #1 0x40302121 in PL_HashTableLookup (ht=0x809dbf0, key=0x41436f21) at plhash.c:388 #2 0x402526a7 in GetBloatEntry (aTypeName=0x41436f21 "nsGenericElement", aInstanceSize=32) at nsTraceRefcnt.cpp:430 #3 0x40253b88 in nsTraceRefcnt::LogAddRef (aPtr=0x8802540, aRefCnt=1086, aClazz=0x41436f21 "nsGenericElement", classSize=32) at nsTraceRefcnt.cpp:1734 #4 0x411f739f in nsGenericElement::AddRef (this=0x8802540) at nsGenericElement.cpp:2578 #5 0x40fc9086 in nsHTMLFormElement::AddRef (this=0x8802540) at nsHTMLFormElement.cpp:363 #6 0x411f7306 in nsGenericElement::QueryInterface (this=0x8802540, aIID=@0x4200d624, aInstancePtr=0xbfe02158) at nsGenericElement.cpp:2571 #7 0x40f9d54e in nsGenericHTMLElement::QueryInterface (this=0x8802540, aIID=@0x4200d624, aInstancePtr=0xbfe02158) at nsGenericHTMLElement.cpp:280 #8 0x40fc912b in nsHTMLFormElement::QueryInterface (this=0x8802540, aIID=@0x4200d624, aInstancePtr=0xbfe02158) at nsHTMLFormElement.cpp:369 #9 0x4028b796 in nsQueryInterface::operator() (this=0xbfe02194, aIID=@0x4200d624, answer=0xbfe02158) at nsCOMPtr.cpp:47 #10 0x41fa20f8 in nsCOMPtr<nsIContent>::assign_from_helper (this=0xbfe021a0, helper=@0xbfe02194, aIID=@0x4200d624) at ../../../../dist/include/xpcom/nsCOMPtr.h:972 #11 0x41fa2312 in nsCOMPtr<nsIContent>::nsCOMPtr (this=0xbfe021a0, helper=@0xbfe02194) at ../../../../dist/include/xpcom/nsCOMPtr.h:565 #12 0x41fa227a in nsCOMPtr<nsIContent>::Assert_NoQueryNeeded (this=0xbfe02250) at ../../../../dist/include/xpcom/nsCOMPtr.h:500 #13 0x41fb80d9 in nsCOMPtr<nsIContent>::nsCOMPtr (this=0xbfe02250, aRawPtr=0x8802540) at ../../../../../../dist/include/xpcom/nsCOMPtr.h:536 #14 0x41e51dbd in nsCSSFrameConstructor::FindFrameWithContent (this=0x87b7fb8, aPresContext=0x87c32f0, aParentFrame=0x87f9ae4, aParentContent=0x8802540, aContent=0x87ffac0, aHint=0xbfe02370) at nsCSSFrameConstructor.cpp:11473 #15 0x41e52545 in nsCSSFrameConstructor::FindPrimaryFrameFor (this=0x87b7fb8, aPresContext=0x87c32f0, aFrameManager=0x8704770, aContent=0x87ffac0, aFrame=0xbfe023e4, aHint=0xbfe02370) at nsCSSFrameConstructor.cpp:11681 #16 0x41239521 in StyleSetImpl::FindPrimaryFrameFor (this=0x8802218, aPresContext=0x87c32f0, aFrameManager=0x8704770, aContent=0x87ffac0, aFrame=0xbfe023e4, aHint=0xbfe02370) at nsStyleSet.cpp:1556 #17 0x41d7cc08 in FrameManager::GetPrimaryFrameFor (this=0x8704770, aContent=0x87ffac0, aResult=0xbfe023e4) at nsFrameManager.cpp:674 #18 0x41dcb2a7 in PresShell::GetPrimaryFrameFor (this=0x87f6000, aContent=0x87ffac0, aResult=0xbfe023e4) at nsPresShell.cpp:5459 #19 0x40fa6575 in nsGenericHTMLElement::GetFormControlFrameFor (aContent=0x87ffac0, aDocument=0x8819fb0, aFlushContent=0) at nsGenericHTMLElement.cpp:2860 #20 0x40fae25f in nsGenericHTMLElement::GetFormControlFrame (this=0x87ffac0, aFlushContent=0) at nsGenericHTMLElement.h:217 #21 0x40fde7a9 in nsHTMLInputElement::SetChecked (this=0x87ffac0, aValue=1) at nsHTMLInputElement.cpp:665 #22 0x41e114dc in nsGfxCheckboxControlFrame::SetCheckboxState (this=0x88b1180, aPresContext=0x87c32f0, aValue=1) at nsGfxCheckboxControlFrame.cpp:284 #23 0x41e11563 in nsGfxCheckboxControlFrame::SetCheckboxControlFrameState ( this=0x88b1180, aPresContext=0x87c32f0, aValue=@0xbfe0272c) at nsGfxCheckboxControlFrame.cpp:303 #24 0x41e11a31 in nsGfxCheckboxControlFrame::RestoreState (this=0x88b1180, aPresContext=0x87c32f0, aState=0x8827cb0) at nsGfxCheckboxControlFrame.cpp:390 talkback does not trigger, so I can't provide any more info than that.... The opt build stack looks odd, but the debug build stack could be related to recent PL_Hashtable changes...
There weren't any recent PLHashTable changes -- you're confusing that hash table implementation, which still lives in nspr (nsprpub/lib/ds/plhash.[ch]) with the double hash table impl PLDHashTable (xpcom/ds/pldhash.[ch], whose primary source is js/src/jsdhash.[ch], kept in synch by hand using js/src/plify_jsdhash.sed). I did update pldhash.[ch] trivially, recently, but those changes are not implicated here, and don't seem capable of bad effects anyway. I'm not able to reproduce this, or even work on it this week (don't ask), so I am bouncing back to bz. This smells of heap corruption, though -- someone should run purify. Cc'ing dbaron for his nsTraceRefcnt.cpp expertise and jst in case he's seeing this too. /be
Assignee: brendan → bzbarsky
Asa too, in case this is a recent regression that must be fixed for 0.9.9, and cuz he probably goes "Back" to bugzilla all the time. /be
OK, I can't reproduce this anymore (Spent all of yesterday and today going "back" and it always works now). Has anyone else seen this?
The symptoms are identical to bug 123914, although the stacktrace is completely different.
Well, I'm seeing this crash on and off with build 2002-03-02-06.... :(
Attached file Minimal testcase (deleted) —
The key was selecting the "and mark this bug NEW" checkbox on unco bugs _then_ hitting back. The testcase is reduced from a real live bugzilla page and crashes for me 100% of the time in a 2002-03-06 opt build. The "CHECKED" on the radio button is absolutely essential to reproduce.
To jkeiser, looks like frame control state restoration.
Assignee: bzbarsky → jkeiser
Blocks: 122050
Keywords: mozilla0.9.9
The patch in bug 108308 fixes this, by the way.
Not gonna happen for 0.9.9
No longer blocks: 122050
In which case we'll set dependent. 108308 will land shortly.
Depends on: 108308
Yes this is in fact fixed. Thanks for the testcase bz!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 130769 has been marked as a duplicate of this bug. ***
*** Bug 132882 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: