Not sure if this really a layout bug or who to assign it to, but I found a reproducible incident in recent Talkback data for Mozilla 1.7 beta. There are quit a few of these crashes with the same stack signature and trace, but can't be sure if they're all the same. Here is the one incident that I was able to reproduce on Windows XP with Mozilla 1.7beta: Incident ID: 14428 Stack Signature nsLineLayout::ReflowFrame f503c2d0 Email Address chris.clemson@softwareag.co.uk Product ID Mozilla1.7 Build ID 2004031615 Trigger Time 2004-04-08 01:15:33.0 Platform Win32 Operating System Windows NT 4.0 build 1381 Module gklayout.dll + (00022c6f) URL visited www.amss.de (2nd page in) User Comments i think mozilla was trying to load some java applet Since Last Crash null sec Total Uptime null sec Trigger Reason Access violation Source File Name c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsLineLayout.cpp Trigger Line No. 1189 Stack Trace nsLineLayout::ReflowFrame [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsLineLayout.cpp, line 1189] nsBlockFrame::ReflowInlineFrame [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3584] nsBlockFrame::DoReflowInlineFrames [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3412] nsBlockFrame::DoReflowInlineFramesAuto [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3313] nsBlockFrame::ReflowInlineFrames [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3258] nsBlockFrame::ReflowLine [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2422] nsBlockFrame::ReflowDirtyLines [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2078] nsBlockFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 797] nsBlockReflowContext::ReflowBlock [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line 547] nsBlockFrame::ReflowBlockFrame [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3037] nsBlockFrame::ReflowLine [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2297] nsBlockFrame::ReflowDirtyLines [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2078] nsBlockFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 797] nsContainerFrame::ReflowChild [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 950] nsTableCellFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableCellFrame.cpp, line 887] nsContainerFrame::ReflowChild [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 950] nsTableRowFrame::ReflowChildren [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableRowFrame.cpp, line 964] nsTableRowFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableRowFrame.cpp, line 1403] nsContainerFrame::ReflowChild [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 950] nsTableRowGroupFrame::ReflowChildren [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp, line 432] nsTableRowGroupFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableRowGroupFrame.cpp, line 1289] nsContainerFrame::ReflowChild [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 950] nsTableFrame::ReflowChildren [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableFrame.cpp, line 3240] nsTableFrame::ReflowTable [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableFrame.cpp, line 2156] nsTableFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableFrame.cpp, line 2000] nsContainerFrame::ReflowChild [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 950] nsTableOuterFrame::OuterReflowChild [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 1326] nsTableOuterFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/table/src/nsTableOuterFrame.cpp, line 1991] nsBlockReflowContext::ReflowBlock [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line 547] nsBlockFrame::ReflowBlockFrame [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3037] nsBlockFrame::ReflowLine [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2297] nsBlockFrame::ReflowDirtyLines [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2078] nsBlockFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 797] nsBlockReflowContext::ReflowBlock [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockReflowContext.cpp, line 547] nsBlockFrame::ReflowBlockFrame [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 3037] nsBlockFrame::ReflowLine [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2297] nsBlockFrame::ReflowDirtyLines [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 2078] nsBlockFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp, line 797] nsContainerFrame::ReflowChild [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 950] CanvasFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLFrame.cpp, line 554] nsBoxToBlockAdaptor::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp, line 884] nsBoxToBlockAdaptor::DoLayout [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp, line 628] nsBox::Layout [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp, line 994] nsScrollBoxFrame::DoLayout [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsScrollBoxFrame.cpp, line 337] nsBox::Layout [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp, line 994] nsContainerBox::LayoutChildAt [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsContainerBox.cpp, line 654] nsGfxScrollFrameInner::LayoutBox [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 1251] nsGfxScrollFrameInner::Layout [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 1410] nsGfxScrollFrame::DoLayout [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 1259] nsBox::Layout [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBox.cpp, line 994] nsBoxFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 868] nsGfxScrollFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp, line 861] nsContainerFrame::ReflowChild [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp, line 950] ViewportFrame::Reflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsViewportFrame.cpp, line 249] PresShell::ResizeReflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp, line 2945] PresShell::ResizeReflow [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp, line 6105] nsViewManager::SetWindowDimensions [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp, line 669] nsViewManager::DispatchEvent [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp, line 1844] HandleEvent [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp, line 79] nsWindow::DispatchEvent [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 1068] nsWindow::DispatchWindowEvent [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 1085] nsWindow::OnResize [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 5079] nsWindow::ProcessMessage [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 4265] nsWindow::WindowProc [c:/builds/tinderbox/Mozilla1.7b/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp, line 1347] I just tried crashing again, but the java applet seems to be loading fine now. I remember the first time I loaded the page, there was a null pointer exception in the java console and the applet didn't finish loading...and when I shutdown the browser I got the crash. Any attempts to load that page now work fine. Weird. If others are able to reproduce this on their first try, we should look into this crash.

Jay, what are the values of aFrame and aMetrics in the stack frame where we crash? How reliable is the line number? Does it have the usual "off by a few" problem?

Boris: I couldn't find the values for aFrame and aMetrics in the detailed Talkback report. The line numbers are pretty reliable. We've found that they are sometimes a line or 2 off (usually on Linux), but accurate most of the time. Here is the only data I found in the detailed report that might be useful: x86 Registers: Not Available Code Around the PC: 60282c6f ff90a4000000 call dword ptr [eax+0xa4] 60282c75 8b4d10 mov ecx,[ebp+0x10] 60282c78 85c9 test ecx,ecx 60282c7a 740c jz 60282c88 60282c7c 8d8578ffffff lea eax,[ebp+0xffffff78] 60282c82 50 push eax 60282c83 e819010000 call 60282da1 60282c88 8b450c mov eax,[ebp+0xc] 60282c8b 8b00 mov eax,[eax] 60282c8d 8bc8 mov ecx,eax

Well, the only things that could be crashing within 2-3 lines of line 1189 are aFrame and aMetrics. Someone familiar with x86 assembly would have to look at the "code around the pc" bit.

Adding topcrash keyword and a few more urls I found in Talkback data that might help us reproduce this crash: 1. http://www.videoland.be/videoland/index.htm Applet fails to load and I get his in the Java console: java.lang.NullPointerException at AnFade.init(AnFade.java) at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source) But I can't get it to crash. 2. http://www.crh.noaa.gov/ifps/MapClick.php?FcstType=graphical&map.x=193&map.y=176&site=ddc&Radius=0&CiTemplate=0 Applet fails to load and I get his in the console: java.lang.NullPointerException at web_meteo.initForm(web_meteo.java:138) at web_meteo.init(web_meteo.java:106) at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source) But this site doesn't crash me either. Both of those sites crashed for a few users...but I have not been able to reproduce. Maybe others might have better luck.

Updating summary with M17rc1 since this continues to be a topcrash with the latest Mozilla 1.7 RC1 release. Here are a couple of new comments: (29471) URL: www.phoenixorion.com (29471) Comments: The browser kept hanging trying to load a Java applet on the site in question. I closed the tab for the site and it crashed. (29964) Comments: attempting to play Yahoo! games (30565) Comments: suddenly browser died I still haven't been able to reproduce this, although the Java applets on these pages all fail to load the first time I go there. Subsequent attempts load the applets fine.

Mozilla trunk build 2004051108 on WinNT4, JRE 1.4.1 I can give you another example URL, try https://www.commerzbank.de/. Mozilla uses 100% CPU on this page, links don't open with left-click, only middle-click (open in new tab) works very slowly. If I close the window/tab Mozilla crashes. Talkback ID: TB45176Q Stack Signature: nsLineLayout::ReflowFrame 021f08ca Interestingly works Firefox 0.8. Low CPU (<5%), all links clickable. No crash.

I tried going to https://www.commerzbank.de/ and didn't see any problems. Everything loaded fine and system resources for mozilla were at normal levels. No crash after browsing for a while and opening up about 10 tabs. It seems like a hit or miss bug. I wonder if Java version and/or available system resources have anything to do with this.

(In reply to comment #7) > I tried going to https://www.commerzbank.de/ and didn't see any problems. Yeah, tested again with trunk build 2004051709 and a new profile - it works. Something in the old profile was wrong.

M17rc1 -> M17rc2: Already 20 incidents in early Talkback data for Mozilla 1.7 rc2 on Windows.

Ok the problem here might(!) be a old Java version. With 1.4.2_03 and a 1.7 debug build i couldn't reproduce the problem, but with 1.3.1_02 i often could make the browser hanging when closing a tab with a java applet in it (sometimes also the browser hung when just opening a site mentioned in this bug). You could still switch between tabs, but if you clicked a link nothing happened, if you have entered a url in url-bar also nothing happened. Also the throbber diappeared, but i think this are effects of the debug build, i'll see if a opt build with symbols will crash here and then compare the stacktraces from this bug to my own stacktrace.

Ok the problem here is i can't get Mozilla to crash, so this might be another bug (i'm using Windows 2000 btw, didn't add that to the comment before). Anyway, i'm posting the stacktraces, because the ReflowFrame thing is also in it and the line numbers seem to fit, too. Jay, is the Java Version somewhere noted in the Talkback data? Anyway if i attach MS VC manually to Mozilla, i get this stacktraces (opt with symbols): NTDLL! 77882870() KERNEL32! 77e73b50() JVM! 6d477038() JVM! 6d44bf02() 031a9d88() 031a785a() 031a785a() 031a785a() JVM! 6d4db814() JVM! 6d440699() JVM! 6d4699a6() JVM! 6d4405ad() JVM! 6d443f9e() JPINS32! 6d2e8140() JPINS32! 6d2e4f6e() JPINS32! 6d2e58fa() nsObjectFrame::InstantiatePlugin(nsObjectFrame * const 0x01010101, nsIPresContext * 0x02c381d8, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, nsIPluginHost * 0x0134e5f4, const char * 0x017f9878 `string', nsIURI * 0x033125b8) line 1301 + 18 bytes nsObjectFrame::Reflow(nsObjectFrame * const 0x0012af68, nsIPresContext * 0x02c381d8, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x03087f88) line 1101 + 27 bytes nsLineLayout::ReflowFrame(nsLineLayout * const 0x01010101, nsIFrame * 0x03087f88, unsigned int & 0x03087f88, nsHTMLReflowMetrics * 0x00000000, int & 0x00000000) line 997 nsBlockFrame::ReflowInlineFrame(nsBlockFrame * const 0x01010101, nsBlockReflowState & {...}, nsLineLayout & {...}, nsLineList_iterator {...}, nsIFrame * 0x03087f88, unsigned char * 0x0012b153) line 3733 + 29 bytes nsBlockFrame::DoReflowInlineFrames(nsBlockFrame * const 0x01010101, nsBlockReflowState & {...}, nsLineLayout & {...}, nsLineList_iterator {...}, int * 0x0012b6c4, unsigned char * 0x0012b5f3, int 0x00000000, int 0x00000000) line 3431 nsBlockFrame::DoReflowInlineFramesAuto(nsBlockFrame * const 0x01010101, nsBlockReflowState & {...}, nsLineList_iterator {...}, int * 0x0012b6c4, unsigned char * 0x0012b5f3, int 0x00000000, int 0x00000000) line 3332 nsBlockFrame::ReflowInlineFrames(nsBlockFrame * const 0x01010101, nsBlockReflowState & {...}, nsLineList_iterator {...}, int * 0x0212b6c4, int 0x00000000, int 0x00000000) line 3277 nsBlockFrame::ReflowLine(nsBlockFrame * const 0x01010101, nsBlockReflowState & {...}, nsLineList_iterator {...}, int * 0x0012b6c4, int 0x00000000) line 2441 nsBlockFrame::ReflowDirtyLines(nsBlockFrame * const 0x01010101, nsBlockReflowState & {...}) line 2097 nsBlockFrame::Reflow(nsBlockFrame * const 0x00000000, nsIPresContext * 0x02c381d8, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000) line 816 [...] And with a debug build i get this: NTDLL! 77882870() KERNEL32! 77e73b50() JVM! 6d477038() JVM! 6d44bf02() 0569e630() 0569c102() 0569c102() 0569c102() JVM! 6d4db814() JVM! 6d440699() JVM! 6d4699a6() JVM! 6d4405ad() JVM! 6d443f9e() JPINS32! 6d2e8140() JPINS32! 6d2e4f6e() JPINS32! 6d2e58fa() nsPluginNativeWindowWin::CallSetWindow(nsCOMPtr<nsIPluginInstance> & {...}) line 390 nsPluginHostImpl::InstantiateEmbededPlugin(nsPluginHostImpl * const 0x01385d7c, const char * 0x01fa85f4, nsIURI * 0x04887978, nsIPluginInstanceOwner * 0x04946e70) line 3414 nsObjectFrame::InstantiatePlugin(nsIPresContext * 0x044ffc98, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, nsIPluginHost * 0x01385d7c, const char * 0x01fa85f4, nsIURI * 0x04887978) line 1301 + 30 bytes nsObjectFrame::Reflow(nsObjectFrame * const 0x049d8650, nsIPresContext * 0x044ffc98, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0x00000000) line 1101 + 49 bytes nsBlockReflowContext::ReflowBlock(const nsRect & {...}, int 0x00000001, nsCollapsingMargin & {...}, int 0x00000001, nsMargin & {...}, nsHTMLReflowState & {...}, unsigned int & 0x00000000) line 546 + 42 bytes nsBlockFrame::ReflowFloat(nsBlockReflowState & {...}, nsPlaceholderFrame * 0x049d86ac, nsFloatCache * 0x047c9d48, unsigned int & 0x00000000) line 5018 + 52 bytes nsBlockReflowState::FlowAndPlaceFloat(nsFloatCache * 0x047c9d48, int * 0x00127e74, unsigned int & 0x00000000) line 865 nsBlockReflowState::AddFloat(nsLineLayout & {...}, nsPlaceholderFrame * 0x049d86ac, int 0x00000000, unsigned int & 0x00000000) line 672 nsLineLayout::AddFloat(nsPlaceholderFrame * 0x049d86ac, unsigned int & 0x00000000) line 236 nsLineLayout::ReflowFrame(nsIFrame * 0x049d86ac, unsigned int & 0x00000000, nsHTMLReflowMetrics * 0x00000000, int & 0x00000000) line 1055 nsBlockFrame::ReflowInlineFrame(nsBlockReflowState & {...}, nsLineLayout & {...}, nsLineList_iterator {...}, nsIFrame * 0x049d86ac, unsigned char * 0x00128127) line 3563 + 22 bytes nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState & {...}, nsLineLayout & {...}, nsLineList_iterator {...}, int * 0x00128824, unsigned char * 0x001285ff, int 0x00000000, int 0x00000000) line 3430 + 32 bytes nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState & {...}, nsLineList_iterator {...}, int * 0x00128824, unsigned char * 0x001285ff, int 0x00000000, int 0x00000000) line 3331 + 46 bytes nsBlockFrame::ReflowInlineFrames(nsBlockReflowState & {...}, nsLineList_iterator {...}, int * 0x00128824, int 0x00000000, int 0x00000000) line 3275 + 36 bytes nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineList_iterator {...}, int * 0x00128824, int 0x00000000) line 2440 + 33 bytes nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2096 + 31 bytes

There are similar 1.7rc2 call stack with real player (nppl3260.dll). It might be a real player bug though.

It looks like same stacks can be found with Adobe PDF plugin (nppdf.so): bug 244460

None of the comments mention what version of Java. I'm digging through more detailed Talkback reports to see if there is any more info about the Java version installed on these users computers.

(In reply to comment #14) > None of the comments mention what version of Java. I'm digging through more > detailed Talkback reports to see if there is any more info about the Java > version installed on these users computers. But wait i think my Java version guess /might/ be wrong here, because if i read this stacktrace right it crashes before it initiates the plugin even so Java /shouldn't/ be related here. Or might TB be missing some function calls here (but why would it get such function calls then with other plugins like in Bug 244460)?

(In reply to comment #14) > None of the comments mention what version of Java. I'm digging through more > detailed Talkback reports to see if there is any more info about the Java > version installed on these users computers. Got one comment from http://talkback-public.mozilla.org/reports/M17rc1/smart-analysis.all: (54159) Comments: additional info (see previous report): applet made by www.coffeecup.com might be the cause. JRE stacktrace: Java(TM) Plug-in: Version 1.4.1_01 Using JRE version 1.4.1_01 Java HotSpot(TM) Client VM User home directory = C:\Documents and Settings\colin So also seems to occour with 1.4.x, so maybe i'm wrong with my Java thingy here *sigh* this is hard to reproduce

I took a closer look at a few incidents and found various versions of Java installed (from checking the module paths): j2re1.4.2_04 j2re1.4.1_01 j2re1.4.2_03 j2re1.4.2_04

Since we've got same call stacks for real player plugin (from public 1.7rc2 talkback stats), java plugin (this bug), and Adobe PDF plugin (bug 244460), it might well be a bug in Mozilla code. I found it weird that these 3 plugins exhibit a bug at the same time, I think it is simplier to assume that there's a bug in Mozilla code. Also it might be OS->All and not only Windows XP.

jst, can you help try and sort this one out?

Maybe bug 136927 has some clues to what's happening here?

Running Java 1.4.1_01 on windows xp: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax), Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8, and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040524, all crashed loading applets at games.yahoo.com and http://nytimes.com/pages/crosswords/index.html. (and also at https://www.commerzbank.de/, though all were able to load the testcases from bug 136927 without incident.) I went to java and downloaded 1.4.2_03, and both mozilla and 7.1 immediately worked perfectly. After crashing with firefox, I checked and found that it was still using 1.4.1_01--and i couldn't get it to update the plugin files even after copying them into the new directory. but after reinstalling, both pages load fine and the applets seem to be working. can someone confirm? should this be added to the release notes?

(In reply to comment #21) Can you post some talkback ID just to make sure that it's not some other crash bug fixed by 1.4.2 that you are seeing ?

I can reproduce this crash on games.yahoo.com with AdBlock extension: 1.7rc2, java 1.4.2, AdBlock extension on windows 2003: =================================== 1) htpp://games.yahoo.com 2) play "Spades" 3) applet load OK, join a room, watch, ... OK 4) install AdBlock extension 5) close and run Mozilla again 6) repeat 1) + 2) 7) applet does not load 8) browser is stuck, I can't open new windows 9) close Mozilla 10) crash : TB65995K 100 %reproductible I installed latest java 1.5beta2 1.7rc2, AdBlock extension, java 1.5beta2: ====================================== repeat steps 1 2 3 above applet loads OK I had one crash not reproductible (TB66012W) Sometimes after opening several play rooms, closing them, ... the browser freeze On closing Mozilla the process stays in memory and has to be killed manually

I see the same results as Bernard: 1. WinXP, Mozilla 1.7rc2, AdBlock, Java 1.4.2 = crash everytime when closing Mozilla (after the Spades game applet fails to load). 2. WinXP, Mozilla 1.7rc2, AdBlock, Java 1.5beta = no crash, I can play Spades. :-) This should definitely go into the release notes. Users that want to use the AdBlock extension should make sure to have the latest JRE installed (1.5.x). Is there anything we can do on our end to prevent the crash though?

Will the new version of Java be included in the final 1.7 (and all 1.8) builds, and/or will Mozilla post a direct URL for users to get the update from the OEM of Java?

Adding M17rc3 to summary for tracking...just so we know this problem is still around with Mozilla 1.7 rc3.

(In reply to comment #26) > Adding M17rc3 to summary for tracking...just so we know this problem is still > around with Mozilla 1.7 rc3. I think my bug submission 241537 is related to this bug. Can someone please confirm.

This is also a topcrash for Firefox 0.9.x.

This is still a topcrasher with the latest releases of Mozilla and Firefox...so we need to figure out what to do about this. Asa: Who does the release notes? We should probably mention the Java upgrade (as well as other plugin upgrades that help avoid crashes, like Flash as reported in bug 200511). Also, who knows the answer to the question from comment #25? Are we planning on packaging the latest Java plugin in future releases?

-> dbaron

*** Bug 245185 has been marked as a duplicate of this bug. ***

*** Bug 241537 has been marked as a duplicate of this bug. ***

Added relnote

It wouldn't surprise me if the underlying problem here is the one described in bug 136927 comment 0 and bug 136927 comment 1.

This continues to be a topcrasher with Firefox 1.0 PR1 and Mozilla 1.7.3. Although we were able to reproduce with the AdBlock extension and Java, we still need a simplified testcase (if there is one) to help figure out what's going on here. Adding helpwanted to see if we can get more eyes on this crash.

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1 Java Plug-in 1.4.2_05 I am able to consistently repro this by trying to load any java game @ http://games.yahoo.com and then closing the tab/window. FWIW, none of the games ever load, and trying to do other things in the browser after trying to load a game (other than closing the tab/window) have mixed results: Clicking on a menu item will result in a menu w/o the > (right) arrow for items that should have one & hovering over those items (View>Sidebar, for example) will not bring up the context menu, you'll have to click on Sidebar to bring up it's context menu. After clicking on Sidebar>History, the area where the History sidebar should be in there, but it's just gray, as is the Status Bar and parts of the Address Bar. Trying to load a new URL in the Address Bar is futile. IOW, the browser becomes useless. :( See TB IDs TB991402Z, TB1108967Z, TB1109139M & TB1109153Q Others will come, as this is a fairly easy this to reproduce...

This now WFM using JRE 1.5.0-b64

Regarding comment 33, the need for JRE 1.5.x is not in PR ("Greenlane") Release Notes. see http://www.mozilla.org/products/firefox/releases/

If anyone can reproduce this in a debug build, could you see if you hit the assertion in this patch?

ben is adding update to point users at 1.5 rafael is getting sun to produce an .xpi and then we will put it into u.m.o

Ok, i made a debug build for Windows with the patch for the people here who can reproduce this bug, but don't have a debug build handy. Download it from http://mcsmurf.milten.lima-city.de/mozilla-i686-pc-cygwin.zi0, rename it to /mozilla-i686-pc-cygwin.zip and extract it somewhere. You still need to remove the write protected flag from the file components/xpti.dat, but then you can start it. If any assertions appear, just ignore those until you hit a site causing the crash here. There you can still ignore the assertion, but now copy&paste the last warnings and assertions from the console window in this bug (you really only need to copy the last ones, not the full output!), before clicking the OK button (that mozilla.exe crashed).

if we figure out a way to intercept the crash, renominate, but until then we will offer java 1.5 as the solution.

*** Bug 250926 has been marked as a duplicate of this bug. ***

Updating summary with FF10RC2 since this continues to be a topcrash heading towards Firefox 1.0. It looks like upgrading to Java 1.5 is working for some users, as total number of crashes have been going down since Firefox 0.9.x releases. Is update.mozilla.org already setup to upgrade our users to the latest Java release? If not, we should make sure to include a release note for 1.0. Adding relnote keyword.

*** Bug 254975 has been marked as a duplicate of this bug. ***

Still around for Firefox 1.0. Also, I updated bug 244538 with recent Talkback data and think that bug might be related or even a dup of this one.

*** Bug 248709 has been marked as a duplicate of this bug. ***

*** Bug 244538 has been marked as a duplicate of this bug. ***

My firefox crashed several times today again while trying to open yahoo games. I am pasting the details of the error here. Hope it helps! FIREFOX caused an invalid page fault in module JPINSCP.DLL at 016f:6d422bc0. Registers: EAX=6d422bc0 CS=016f EIP=6d422bc0 EFLGS=00010206 EBX=6d420000 SS=0177 ESP=00c9f238 EBP=00c9f268 ECX=00000080 DS=0177 ESI=6d42f004 FS=44f7 EDX=00de3f6c ES=0177 EDI=00000000 GS=0000 Bytes at CS:EIP: 01 00 00 00 a0 2c 42 6d 1f 00 01 00 00 00 00 00 Stack dump: 78001fa2 00000001 6d42ab0d 6d42f000 6d42f00c 6d42ab9a 6d420000 00000001 00000000 00000000 6d420000 817a14dc 00c9f430 bff7ddd6 6d420000 00000001

*** Bug 271961 has been marked as a duplicate of this bug. ***

fwiw, also happens on linux as mentioned on #271961, a «sufficiently empowered user» could update this.

*** Bug 270662 has been marked as a duplicate of this bug. ***

Sounds like updating java helped to solve this and maybe it should be closed now. dbaron, is this work still needed? > It wouldn't surprise me if the underlying problem here is the one described in > bug 136927 comment 0 and bug 136927 comment 1.

Jay, I don't see nsLineLayout::ReflowFrame on crash-stats.

This is marked for 1.7 branch, so by now it's really obsolete.