Closed Bug 27650 Opened 25 years ago Closed 18 years ago

crasher -- kibo's webpage

Categories

(Core :: Layout, defect, P3)

x86
All
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: sarnold, Unassigned)

References

()

Details

(Keywords: crash, regression)

Attachments

(3 files)

My linux CVS build of mozilla dies when it views kibo's WebTV version of his web
page. (I am not entirely certain that *any* web browser can actually *view* his
page, very non-conformant..)

It would be nice if mozilla didn't crash on it though. (Good luck trying for a
simplified test case! :)

Here is the text mozilla threw into my xterm as it died:
Gdk-ERROR **: BadAlloc (insufficient resources for operation)
  serial 1322562 error_code 11 request_code 53 minor_code 0
Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter)
  serial 1322564 error_code 9 request_code 55 minor_code 06

Hehehe.
i was able to get a crash on that page, not sure if it's the same thing since 
i'm on windows and it's crashing in platform specific code.

i loaded the page.  after a minute or two, it crashed.

here's the last output from the console window, and a stack trace. 
WARNING: cell content 0491277C has large width 16175655
WARNING: cell content 0491277C has large height 100724
nsBlockReflowContext: TableOuter(table)(3)@049125D8 metrics=16176015,101114!
Block(body)(3)@049123A8: line=05423C20 xmost=16176015
nsBlockReflowContext: TableOuter(table)(3)@049125D8 metrics=16176015,101114!
Block(body)(3)@049123A8: line=05423C20 xmost=16176015
killing stream for http://www.kibo.com/webtv/seaquest.mid
killing stream for http://www.kibo.com/webtv/space_1999.mid
killing stream for http://www.kibo.com/webtv/lookit_me_2.wav
killing stream for http://www.kibo.com/webtv/lookit_me_1.wav


NTDLL! 77f76274()
nsWindow::Create(nsWindow * const 0x05489bc4, nsIWidget * 0x0546c6d4, const 
nsRect & {...}, nsEventStatus (nsGUIEvent *)* 0x020c4e40 HandleEvent(nsGUIEvent 
*), nsIDeviceContext * 0x05446300, nsIAppShell * 0x00000000, nsIToolkit * 
0x00000000, nsWidgetInitData * 0x0012f548) line 893
nsView::CreateWidget(nsView * const 0x054880a0, const nsID & {...}, 
nsWidgetInitData * 0x0012f548, void * 0x00000000, int 1) line 1269
nsScrollPortView::CreateScrollControls(nsScrollPortView * const 0x05488108, 
void * 0x00000000) line 155
nsScrollPortFrame::CreateScrollingView(nsIPresContext * 0x0543d390) line 284
nsScrollPortFrame::Init(nsScrollPortFrame * const 0x0490b5cc, nsIPresContext * 
0x0543d390, nsIContent * 0x00000000, nsIFrame * 0x0490b580, nsIStyleContext * 
0x05489ce0, nsIFrame * 0x00000000) line 98
nsCSSFrameConstructor::InitAndRestoreFrame(nsIPresContext * 0x0543d390, 
nsFrameConstructorState & {...}, nsIContent * 0x00000000, nsIFrame * 
0x0490b580, nsIStyleContext * 0x05489ce0, nsIFrame * 0x00000000, nsIFrame * 
0x0490b5cc) line 5344 + 32 bytes
nsCSSFrameConstructor::BeginBuildingScrollFrame(nsIPresShell * 0x0546c330, 
nsIPresContext * 0x0543d390, nsFrameConstructorState & {...}, nsIContent * 
0x00000000, nsIStyleContext * 0x05482aa0, nsIFrame * 0x0490b508, nsIAtom * 
0x017fcd60, nsIDocument * 0x05434260, nsIFrame * & 0x0490b580, 
nsCOMPtr<nsIStyleContext> & {...}, nsIFrame * & 0x00000000) line 4665
nsCSSFrameConstructor::ConstructRootFrame(nsCSSFrameConstructor * const 
0x0546c540, nsIPresShell * 0x0546c330, nsIPresContext * 0x0543d390, nsIContent 
* 0x05431afc, nsIFrame * & 0x00000000) line 2617
StyleSetImpl::ConstructRootFrame(StyleSetImpl * const 0x0546c5e0, 
nsIPresContext * 0x0543d390, nsIContent * 0x05431afc, nsIFrame * & 0x00000000) 
line 942 + 39 bytes
PresShell::InitialReflow(PresShell * const 0x0546c330, int 4995, int 6660) line 
1202
HTMLContentSink::StartLayout() line 3053
HTMLContentSink::OpenBody(HTMLContentSink * const 0x05433520, const 
nsIParserNode & {...}) line 2665
CNavDTD::OpenBody(const nsIParserNode * 0x05473c20) line 2618 + 31 bytes
CNavDTD::OpenContainer(const nsIParserNode * 0x05473c20, nsHTMLTag 
eHTMLTag_body, int 1, nsEntryStack * 0x00000000) line 2870 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x02217960, nsHTMLTag eHTMLTag_body, 
nsIParserNode * 0x05473c20) line 1075 + 20 bytes
CNavDTD::HandleStartToken(CToken * 0x02217960) line 1395 + 22 bytes
CNavDTD::HandleToken(CNavDTD * const 0x0546d100, CToken * 0x02217960, nsIParser 
* 0x05433080) line 765 + 12 bytes
CNavDTD::HandleToken(CNavDTD * const 0x0546d100, CToken * 0x02da28b0, nsIParser 
* 0x05433080) line 723 + 20 bytes
CNavDTD::BuildModel(CNavDTD * const 0x0546d100, nsIParser * 0x05433080, 
nsITokenizer * 0x0546ec00, nsITokenObserver * 0x00000000, nsIContentSink * 
0x05433520) line 504 + 20 bytes
nsParser::BuildModel() line 1083 + 34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 998 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x05433084, nsIChannel * 0x054472d0, 
nsISupports * 0x00000000, nsIInputStream * 0x05423930, unsigned int 0, unsigned 
int 4096) line 1377 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x0542b710, 
nsIChannel * 0x054472d0, nsISupports * 0x00000000, nsIInputStream * 0x05423930, 
unsigned int 0, unsigned int 4096) line 256 + 46 bytes
CacheManagerStreamListener::OnDataAvailable(CacheManagerStreamListener * const 
0x05426960, nsIChannel * 0x05426e30, nsISupports * 0x00000000, nsIInputStream * 
0x05423930, unsigned int 0, unsigned int 4096) line 151
AsyncReadStreamAdaptor::OnDataAvailable(AsyncReadStreamAdaptor * const 
0x05423934, nsIChannel * 0x05426e30, nsISupports * 0x00000000, nsIInputStream * 
0x05423930, unsigned int 0, unsigned int 4096) line 109 + 49 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x054262d0) 
line 370
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x05425e40) line 93 + 12 bytes
PL_HandleEvent(PLEvent * 0x05425e40) line 526 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00d16890) line 487 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x05ad008e, unsigned int 49335, unsigned int 0, 
long 13723792) line 975 + 9 bytes
USER32! 77e71268()
00d16890()
Assignee: leger → kmcclusk
Component: Browser-General → Layout
Keywords: crash
I tried loading kibo's page with WIN95 and WINNT with todays build and I could 
not get it to crash. I also tried it on Linux with todays build and it crashed 
when I was leaving it with a BadAlloc (My window was maximized). I tried running 
it 3 or 4 more times with various window sizes including maximized and it did 
not crash. 

Waqar could you take a look? 
Assignee: kmcclusk → waqar
i just tried it again with a debug build from this morning, and crashed.
same stack trace. here's how it happened:

1. load http://www.kibo.com/webtv/webtv.html
2. some dialog will appear asking about a plugin.  dismiss the dialog.
3. after a minute or two -> crash

i haven't tried to pick this apart.
This page loaded ok, did not crash my build of today, it loaded very slowly and
the mouse response got really slow. It has very large images.
Status: NEW → ASSIGNED
Severity: normal → critical
Investigating
Target Milestone: M15
I dont get a crash, but it has a very large animated gif. which makes the
response to very very slow, take about 2 to 3 minutes to respond to a menu
click.
Moving
Target Milestone: M15 → M17
Moving to m16 due to crash.
Target Milestone: M17 → M16
I am not really able to crash on linux. I let it run overnight. This page was 
specifically designed for webtv. It crashes IE5 for Mac. I think this is works 
for me. I anybody able to crash with this page?
Waqar, were you able to get mozilla to do anything else? :)

I loaded this page on my april 17th mozilla build under linux, and .. although
it no longer crashed mozilla, it might as well have. Any user running mozilla is
just going to crtl-alt-del the thing under windows (if it acts the same way :)
or killall mozilla-bin under unix.

Perhaps as a way of combating such blatantly ugly html, mozilla's parse engine
could assign a score -- +1 for every malformed construct, or something similar,
and refuse to render anything beyond a user-configurable setting. If it goes
above that setting, just show the text as mozilla recieved it. :)

So, to answer your question directly: when I tried to reproduce this, it did not
crash my mozilla. However, mozilla would be useless for most users (myself
included. :) [as a result, I am going to remove 'crash' from the keywords...]

Thanks :)
Keywords: crash
sarnold@willamette.edu I was able to click on menu and scroll bar and have 
mozilla respond, it was very slow, it would take atleast a minute before a menu 
would drop and select. When I move the scroller it would take couple of minutes 
before the page would move up or down.

If we want to add the points in parser, then either rickg@netscape.com or 
harishd@netscape.com would be the people to talk to. I will talk to them about 
it.
Hehehe. Man, Kibo sure put a lot of effort into making a webpage that would
destroy any web browser. :)

Thanks Waqar :)
I think we should invalidate this bug, as if load the
www.kibo.com/webtv/index.html it states that this page is to be viewed by webtv
only.
It does not crash any more.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Adding crash keyword
Keywords: crash
Sorry to dredge up such an old bug, but I can confirm that this bug still
exists. The site crashes me every time on Windows 2000, 20030917 build. It does
not seem to occur in the 1.5 RC1 build, so this might be some kind of regression
in the trunk. My talkback ID for the incident is TB23699136E.

I'm reopening it since people still seem to be stumbling across, and having
trouble with, this page (I went there to investigate bug 206958, which is
probably invalid itself, and found this crasher). I realize this is designed for
WebTV, but Mozilla still shouldn't be shipping with a known crash bug.
Status: RESOLVED → REOPENED
Keywords: regression
OS: Linux → All
Resolution: INVALID → ---
Whiteboard: TB23698722Y, TB23699136E
Crashes for me as well, Talkback incident TB26819922G.
reassigning to defaults
Assignee: waqar → nobody
Status: REOPENED → NEW
QA Contact: cbegle → core.layout
Really awesome page :)

Still crashes for me on Mozilla 1.7a under WinXP. It loads fine but crashes as
soon as I scroll down.

The stacktrace I get is again totally different:
000000f2()
QBCurve::SubDivide(nsIRenderingContext * 0x00000000, nsPoint * 0x01654068
polypath, int * 0x0012cbf4) line 4052 + 20 bytes
QBCurve::SubDivide(nsIRenderingContext * 0x00000000, nsPoint * 0x01654068
polypath, int * 0x0012cbf4) line 4062
QBCurve::SubDivide(nsIRenderingContext * 0x00000000, nsPoint * 0x01654068
polypath, int * 0x0012cbf4) line 4062
QBCurve::SubDivide(nsIRenderingContext * 0x00000000, nsPoint * 0x01654068
polypath, int * 0x0012cbf4) line 4062
QBCurve::SubDivide(nsIRenderingContext * 0x00000000, nsPoint * 0x01654068
polypath, int * 0x0012cbf4) line 4062
QBCurve::SubDivide(nsIRenderingContext * 0x00000000, nsPoint * 0x01654068
polypath, int * 0x0012cbf4) line 4062
QBCurve::SubDivide(nsIRenderingContext * 0x00000000, nsPoint * 0x01654068
polypath, int * 0x0012cbf4) line 4062
QBCurve::SubDivide(nsIRenderingContext * 0x00000000, nsPoint * 0x01654068
polypath, int * 0x0012cbf4) line 4062
QBCurve::SubDivide(nsIRenderingContext * 0x00000000, nsPoint * 0x01654068
polypath, int * 0x0012cbf4) line 4062
QBCurve::SubDivide(nsIRenderingContext * 0x00000000, nsPoint * 0x01654068
polypath, int * 0x0012cbf4) line 4062
...
...
...
Target Milestone: M16 → Future
Wow, tough one. While trying to make a reduced testcase I already got it to hang
WinXP twice. Neat.
on linux, it crashes in bitmap font anti-aliasing code making X11 calls (X11
crashes, not Mozilla) on the enormous fonts.
holy macorole, thats one, um interesting site, It tossed my Browser aside like a
piece fly hitting my winshield
See TB8088X

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316
Keywords: talkbackid
Whiteboard: TB23698722Y, TB23699136E → TB8088X
Kevin's talkback report seems to match that from comment 19:

QBCurve::SubDivide [/mozilla/layout/html/style/src/nsCSSRendering.cpp, line 3975]
QBCurve::SubDivide [/mozilla/layout/html/style/src/nsCSSRendering.cpp, line 3986]
QBCurve::SubDivide [/mozilla/layout/html/style/src/nsCSSRendering.cpp, line 3986]
QBCurve::SubDivide [/mozilla/layout/html/style/src/nsCSSRendering.cpp, line 3986]
....
Keywords: talkbackid
Whiteboard: TB8088X
Very strange page. First it loaded without any problem and I could scroll up and
down without any crashes. But after reloading the page my whole system freezed
and I had to make a hard reset.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040423

Bruno
Attempts to load this page repeatably crash my browser under windows 2000.

Mozilla 1.6
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

I tested the page again with Mozilla 1.7RC2 (Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7) Gecko/20040514) and it didn't crash! Not even after clicking
on the "R - E - S - E - T"-Button, which crashed Mozilla 1.7RC1

So a WFM from me.

Can anyone verify this?
Also WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040520 Firefox/0.8.0+ and Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8a2) Gecko/20040522 Firefox/0.8.0+

Wanted to test with the latest Mozilla nightly too, but that didn't work at all.
Either it didn't start or it did start but nothing happended, wherever I clicked.
I think it's the combination of the very big font and the <nobr> tag what seems
to cause the trouble here. Without the <nobr> tag it is still slow, but not
nearly as cpu intensive as with the <nobr>.
This testcase severely slows down my system, and I suspect it would be even
worse with more text inside the <nobr> tag.

Using:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040711
Firefox/0.9.0+
Depends on: 265736
FWIW, this doesn't crash firefox 1.0.2 on FC3. Can mozilla/other browser users test?
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050329
both testcase and URL, loaded and reloaded, and scrolled a lot.

crash Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050402 Firefox/1.0+

testcase working in first tab, then crash on URL in second tab after some
scrolling around: TB5011533W

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB5011533W
QBCurve::MidPointDivide 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSRendering.cpp,
line 3995]
QBCurve::SubDivide 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSRendering.cpp,
line 3945]
QBCurve::SubDivide 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSRendering.cpp,
line 3954]
...
repeated 60 times (total 62)
...
QBCurve::SubDivide 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.0_Depend/mozilla/layout/base/nsCSSRendering.cpp,
line 3954]
(In reply to comment #31)
> wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050329
> both testcase and URL, loaded and reloaded, and scrolled a lot.

retried, Mozilla is also crashing, TB5012502E, seems to be nearly same as above

Stack Trace  	
GKLAYOUT.DLL + 0x2594e (0x6028594e)
GKLAYOUT.DLL + 0x259dd (0x602859dd)   <- repeated 62 times 
WFM under Mac OS 10.3.9, Camino nightly 2005102404 (v1.0a1+).
I just visited the page in the 20051025 Firefox branch nightly (Windows 2000), it locked up my entire PC and required a hard reboot. It worked fine at first, but when I started scrolling up and down rapidly it froze the system. Not even Ctl-Alt-Del was recognized, I had to physically remove power.

There was a message from the plugin service that I need to download QuickTime, so the QuickTime content is probably unrelated to the hang.
Boris: could you make a jprof on Martijns testcase.

Thanks
The testcase loads instantaneously here (current Linux trunk build), so there's not much to profile there...
Attached file sample app
>The testcase loads instantaneously here (current Linux trunk build), so there's
>not much to profile there...
Boris, I like your profiles. They are sooo to the point.

This is a "upstream" issue. Microsofts GDI routine chooke on long text with large fonts as the attached sample app documents. 

usage:

exttextout 100 

will draw the text with 100 pt roman font.

extextout 

will use the default 500 and severly slow down your system.

It triggers around 350 for the fontsize.
IE does not increase the font size on nested <big>s as we do so it does render Martijn's testcase but it honours the font-size and then it fails as we do. I think there is little left to do other than to reboot to a real OS.
Based on Bernd's comments, I'd say this is partially a dup of bug 206235 and partially an upstream (Windows) issue / invalid.  

Or maybe even evang, if kibo's intention wasn't to inflict pain on Windows Firefox users?
Or we could mark this dependent on the cairo changes and see what happens... ;)
Then it would probably end up being considered a dup of bug 331180, even though that's a 2006 regression and this is a bug from 2000 ;)
Well, let's mark dependent for now.
Depends on: 331180
unable to duplicate crash issue under Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0.

Memory usage remains static.
Original submitter emails bounce. 

I do not have the permissions to close bug. It is my belief that this is resolved.

Can someone remove this little noise from the signal?
My God, what a horrible page. Anyway, WFM.
Status: NEW → RESOLVED
Closed: 24 years ago18 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: