Closed
Bug 127569
Opened 23 years ago
Closed 23 years ago
Crash on going "back" to bugzilla bug page
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bzbarsky, Assigned: john)
References
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
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...
Comment 1•23 years ago
|
||
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
Comment 2•23 years ago
|
||
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
Reporter | ||
Comment 3•23 years ago
|
||
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?
Comment 4•23 years ago
|
||
The symptoms are identical to bug 123914, although the stacktrace is completely
different.
Reporter | ||
Comment 5•23 years ago
|
||
Well, I'm seeing this crash on and off with build 2002-03-02-06.... :(
Reporter | ||
Comment 6•23 years ago
|
||
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.
Reporter | ||
Comment 7•23 years ago
|
||
To jkeiser, looks like frame control state restoration.
Assignee: bzbarsky → jkeiser
Updated•23 years ago
|
Blocks: 122050
Keywords: mozilla0.9.9
Reporter | ||
Comment 8•23 years ago
|
||
The patch in bug 108308 fixes this, by the way.
Assignee | ||
Comment 10•23 years ago
|
||
In which case we'll set dependent. 108308 will land shortly.
Depends on: 108308
Assignee | ||
Comment 11•23 years ago
|
||
Yes this is in fact fixed. Thanks for the testcase bz!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 12•23 years ago
|
||
*** Bug 130769 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 13•23 years ago
|
||
*** Bug 132882 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•