342698 - Stack overflow while (re)loading page

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Caio Tiago Oliveira (asrail)]

While loading this page https://www.orkut.com/GLogin.aspx?done=http%3A%2F%2Fwww.orkut.com%2F (sometimes you have to force refresh it) seamonkey receives a SIGSERV.

This is the debug information just before the crash:
"
CSS Error (https://www.google.com/accounts/ServiceLoginBox?service=orkut&nui=2&uilel=1&skipvpage=true&continue=https%3A%2F%2Fwww.orkut.com%2FRedirLogin.aspx%3Fmsg%3D0%26page%3Dhttp%253A%252F%252Fwww.orkut.com%252F&followup=https%3A%2F%2Fwww.orkut.com%2FGLogin.aspx&hl=en-US :42.2): Selector expected.  Ruleset ignored due to bad selector.
CSS Error (https://www.google.com/accounts/ServiceLoginBox?service=orkut&nui=2&uilel=1&skipvpage=true&continue=https%3A%2F%2Fwww.orkut.com%2FRedirLogin.aspx%3Fmsg%3D0%26page%3Dhttp%253A%252F%252Fwww.orkut.com%252F&followup=https%3A%2F%2Fwww.orkut.com%2FGLogin.aspx&hl=en-US :42.6): Unexpected end of file while searching for closing } of invalid rule set.
WARNING: NS_ENSURE_TRUE(mSaveLayoutState || !aState) failed: file nsSHEntry.cpp, line 297
WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 846
WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 846

Program received signal SIGSEGV, Segmentation fault.
"


The backtrace shows:
"

#0  0xb615baf1 in nsDocument::QueryInterface (this=0x8b6ee68, aIID=@0xb3fc01b8, aInstancePtr=0xbf791078) at nsDocument.cpp:838
#1  0xb626f53c in nsHTMLDocument::QueryInterface (this=0x8b6ee68, aIID=@0xb3fc01b8, aInstancePtr=0xbf7910d0) at nsHTMLDocument.cpp:354
#2  0xb7e0e86f in nsQueryInterface::operator() (this=<value optimized out>, aIID=@0xb3fc01b8, answer=0xb6536c80) at nsCOMPtr.cpp:47
#3  0xb3f5ad02 in nsCOMPtr<nsIContent>::assign_from_qi (this=0xbf791128, qi={mRawPtr = 0x8b6eef4}, aIID=@0xb3fc01b8) at nsCOMPtr.h:1232
#4  0xb3f5ad5a in nsCOMPtr (this=0xbf791128, qi={mRawPtr = 0x8b6eef4}) at nsCOMPtr.h:645
#5  0xb3f73308 in nsAccessible::GetState (this=0x82fc388, aState=0xbf7911e4) at nsAccessible.cpp:769
#6  0xb3f606ff in nsDocAccessible::GetState (this=0x82fc388, aState=0xbf7911e4) at nsDocAccessible.cpp:194
#7  0xb3f716b9 in nsAccessible::GetFinalState (this=0x82fc388, aState=0xbf7911e4) at nsAccessible.cpp:1796
"

Then loops in:
"
#8  0xb3f753a2 in nsAccessible::State (aAcc=0x82fc3a4) at nsAccessible.h:151
#9  0xb3f6f5d4 in nsAccessible::GetExtState (this=0x82fc388, aExtState=0xbf79127c) at nsAccessible.cpp:2206
#10 0xb3f95da0 in nsHyperTextAccessible::GetExtState (this=0x82fc388, aExtState=0xbf79127c) at nsHyperTextAccessible.cpp:183
#11 0xb3f60845 in nsDocAccessible::GetState (this=0x82fc388, aState=0xbf791304) at nsDocAccessible.cpp:220
"
until run out of stack space.


Sometimes it loops in:
"
#12 0xb3fb26b9 in nsAccessible::GetFinalState (this=0x8b711d8, aState=0xbf38b274) at nsAccessible.cpp:1796
#13 0xb3fb63a2 in nsAccessible::State (aAcc=0x8b711f4) at nsAccessible.h:151
#14 0xb3fb05d4 in nsAccessible::GetExtState (this=0x8b711d8, aExtState=0xbf38b30c) at nsAccessible.cpp:2206
#15 0xb3fd6da0 in nsHyperTextAccessible::GetExtState (this=0x8b711d8, aExtState=0xbf38b30c) at nsHyperTextAccessible.cpp:183
#16 0xb3fa1845 in nsDocAccessible::GetState (this=0x8b711d8, aState=0xbf38b394) at nsDocAccessible.cpp:220
"



This is happening with a trunk build compiled by me 25th July 2006, gtk2 non-cairo.

The trunk bz2 file of the same day show just the following:
"
GTK Accessibility Module initialized
./run-mozilla.sh: line 131:  8866 Segmentation fault      "$prog" ${1+"$@"}
".

Don't activate talkback since it isn't activated by stack overflow.

It happens even with a clean profile.

The Linux distro is Ubuntu.

Comment 1

[Aaron Leventhal]

Attachment: Patch

Comment 2

[Caio Tiago Oliveira (asrail)]

The patch worked fine for me.

=)

Comment 3

[Mark Pilgrim (inactive)]

Comment on attachment 227020 [details] [diff] [review]
Patch

My understanding (from aaronlev's explanation) is that GetExtState and GetState were calling each other, and this patch removes the cyclical dependency. r=me