Closed Bug 271574 Opened 20 years ago Closed 15 years ago

Firefox crashes after visiting http://games.yahoo.com/games/downloads/bo_msgr.html [@ nsStyleBorder::~nsStyleBorder]

Categories

(Core :: Layout, defect)

1.7 Branch
x86
Windows 2000
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: andrea.aime, Unassigned)

References

()

Details

(Keywords: crash)

Crash Data

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Firefox crashes after visiting http://games.yahoo.com/games/downloads/bo_msgr.html
It usually crashes when I close the page (that is, I close the firefox window),
but it may also crash during applet loading (quite easy to reproduce).
The trackback id is TB2154818Q.

Reproducible: Sometimes
Steps to Reproduce:
WFM:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0, Java 1.4.2_05

Severity: normal → critical
Keywords: crash
Oh, I forgot to add that I'm using java 5 (jdk 1.5) 
WFM
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0, Java 1.5

Reporter: How many times do you usually have to do it before it crashes. Do you
have to play the game? Please find a more sure-fire way to reproduce it.

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2154818Q
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/shared/public/nsStyleStruct.h&rev=AVIARY_1_0_20040515_BRANCH&mark=318#308
I got it to crash by opening a tab then closing it. I scrolled the mousewheel as
it was closing. I don't know if that was the cause.

My talkback:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=2155052

Here is another one:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=2153698

It makes me think Java is the culprit, because it crashes in different places in
each report.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It crashes most of the time, and what I have to do is to open by clicking on 
the link in the yahoo messenger to open the game, wait the the game to load, 
and close the firefox window. Nothing more than that... I'm usually surprised 
when I close the window and it does not crashes... 
It doesn't crash all the time for me, it only happens about once every 5-10
times. I think the best method to reproduce this one is brute force -- just open
the link in a new tab, wait 2 seconds, close the tab, and repeat until it
crashes. Opening a bunch of tabs and closing them seems to be less successful
than just opening 1 and closing it.

Here's another talkback:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=2158515
(The URL on the report is wrong)

There would be more, but the talkback server seems to be down and not recieving.
Search for reports with comments containing 271574

I noticed something else.. The browser becomes slow at responding sometimes and
eventually stops responding. The memory usage also doubles when you go to the
page, and never goes down when you close it, showing that the applet seems to
not unload.
Incident ID: 2154818
Stack Signature	nsStyleBorder::~nsStyleBorder 7ddcc6ee
Product ID	Firefox10
Build ID	2004110711
Trigger Time	2004-11-24 07:33:41.0
Platform	Win32
Operating System	Windows NT 5.0 build 2195
Module	FIREFOX.EXE + (00178631)
URL visited	http://games.yahoo.com/games/downloads/bo_msgr.html
User Comments	
Since Last Crash	127 sec
Total Uptime	153906 sec
Trigger Reason	Access violation
Source File, Line No.	../../../../dist/include/content\nsStyleStruct.h, line 318
Stack Trace 	
nsStyleBorder::~nsStyleBorder 
[../../../../dist/include/content/nsStyleStruct.h, line 318]
nsStyleContext::Release  [../../../../dist/include/content/nsStyleContext.h,
line 70]
nsSplittableFrame::Destroy 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsSplittableFrame.cpp,
line 71]
nsFrameList::DestroyFrames 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 129]
nsFrameList::DestroyFrames 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 129]
nsTableFrame::Destroy 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableFrame.cpp,
line 310]
nsTableOuterFrame::Destroy 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableOuterFrame.cpp,
line 82]
CanvasFrame::Destroy 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLFrame.cpp,
line 240]
nsFrameList::DestroyFrames 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 129]
nsBoxFrame::Destroy 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1065]
nsFrameList::DestroyFrames 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/base/src/nsFrameList.cpp,
line 129]
nsBoxFrame::Destroy 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1065]
nsGfxScrollFrame::Destroy 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp,
line 433]
nsPositionedInlineFrame::Destroy 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsInlineFrame.cpp,
line 1103]
PresShell::Destroy 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 1868]
DocumentViewerImpl::Destroy 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp,
line 1242]
DocumentViewerImpl::Show 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp,
line 1502]
PresShell::UnsuppressAndInvalidate 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 4815]
PresShell::UnsuppressPainting 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 4860]
nsDocShell::EndPageLoad 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp,
line 4441]
nsWebShell::EndPageLoad 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/docshell/base/nsWebShell.cpp,
line 755]
nsDocShell::OnStateChange 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp,
line 4375]
nsDocLoaderImpl::FireOnStateChange 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp,
line 1247]
nsDocLoaderImpl::doStopDocumentLoad 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp,
line 868]
nsDocLoaderImpl::OnStopRequest 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp,
line 696]
nsLoadGroup::RemoveRequest 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsLoadGroup.cpp,
line 695]
HandleImagePLEvent 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/content/base/src/nsImageLoadingContent.cpp,
line 604]
PL_HandleEvent 
[d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/xpcom/threads/plevent.c,
line 674]
0x778b0c24

can anyone crash using mozilla trunk?
Summary: Firefox crashes after visiting http://games.yahoo.com/games/downloads/bo_msgr.html → Firefox crashes after visiting http://games.yahoo.com/games/downloads/bo_msgr.html [@ nsStyleBorder::~nsStyleBorder]
Assignee: firefox → nobody
Component: General → Layout
Product: Firefox → Core
QA Contact: firefox.general → core.layout
Version: unspecified → 1.7 Branch
FYI: on linux with Sun's JRE 1.5.0, the java plugin bails consistently:
java_vm: pcm.c:5896: snd_pcm_mmap_commit: Assertion `frames <=
snd_pcm_mmap_avail(pcm)' failed.
INTERNAL ERROR on Browser End: Plugin instance index out of bounds -2
Then is this a case of the Java process taking down the Firefox process, and
would it be fixed by bug 156493 (Browser should tolerate plug-in (plugin)
malfunctions, like with a separate (own) process)?
So.. does this crash on trunk?  Does this crash with java disabled?
Nope, I cannot make it crash with Java disabled. Yet this is no prove that it's
the VM taking down firefox. I'm pretty sure there is some javascript in this
page that interacts with the applet in order to record the high scores (and it
works only with internet explorer). 
Makes sense.  Again, does this crash on trunk?
(In reply to comment #13)
> Makes sense.  Again, does this crash on trunk?
I can't reproduce this with both firefox 2.0 rc1 and seamonkey trunk 2006101708. I use JRE 5.0 update 9 and Windows XP. Even after opening and closing the game around 30 times mozilla did't crash.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsStyleBorder::~nsStyleBorder]
You need to log in before you can comment on or make changes to this bug.