Closed Bug 55734 Opened 24 years ago Closed 24 years ago

page freeze moz during load

Categories

(Core :: DOM: HTML Parser, defect, P3)

defect

Tracking

()

VERIFIED WORKSFORME
Future

People

(Reporter: spam, Assigned: harishd)

References

()

Details

(Keywords: perf)

Attachments

(2 files)

2000100709 While loading http://www.nordata.net mozilla will freeze 99 of 100 times. I've seen it load completely, and be functional, but that's a rare occation and last happened some weeks ago. The culprit is the left JS based menu.
The left frame (http://shop.nordata.net/meny.asp) freezes all Mozilla windows for about ten seconds on Win98. All/all, perf.
Keywords: perf
OS: Linux → All
Hardware: PC → All
Hmm. On linux it freezes for many many minutes. Actually for so long that i always wind up putting the whole app out of it's misery with a "killall mozilla-bin"
Confirming on WinNT, using: commercial build 2000101608 MN6 branch debug build 2000-10-16 CPU usage pinned at 100%. I interrupted the browser and kept getting stack traces like this: FROM THE BINARY: XPCOM! 60cb6ddc() XPCOM! 60ca96ee() GKPARSER! 60363832() GKPARSER! 6036336a() GKPARSER! 6036327d() GKPARSER! 60376328() GKPARSER! 60375a9c() GKPARSER! 60375f4b() URILDR! 609444b8() NECKO! 60670837() NECKO! 6065c7f3() NECKO! 60657e3a() NECKO! 6066fe41() NECKO! 60646d9c() NECKO! 606468ce() FROM THE DEBUG BUILD: nsCRT::strncasecmp(const unsigned short * 0x03b1e8e6, const unsigned short * 0x0012f5c6, unsigned int 8) line 374 + 15 bytes Compare2To2(const char * 0x03b1e8e4, const char * 0x0012f5c4, unsigned int 8, int 1) line 621 + 17 bytes nsStr::RFindSubstr(const nsStr & {...}, const nsStr & {...}, int 1, int 28948, int 28475) line 540 + 43 bytes nsString::RFind(const nsString & {...}, int 1, int 28948, int 28475) line 1253 + 73 bytes CTextToken::ConsumeUntil(unsigned short 0, int 0, nsScanner & {...}, nsString & {...}, int 1, int & 0) line 643 + 31 bytes nsHTMLTokenizer::ConsumeStartTag(unsigned short 108, CToken * & 0x03ba7038, nsScanner & {...}, int & 0) line 709 + 45 bytes nsHTMLTokenizer::ConsumeTag(unsigned short 115, CToken * & 0x03ba7038, nsScanner & {...}, int & 0) line 531 + 34 bytes nsHTMLTokenizer::ConsumeToken(nsScanner & {...}, int & 0) line 459 + 34 bytes nsParser::Tokenize(int 0) line 2453 + 28 bytes nsParser::ResumeParse(int 1, int 0) line 1889 + 12 bytes nsParser::OnDataAvailable(nsParser * const 0x03fc6ec8, nsIChannel * 0x03f21d10, nsISupports * 0x00000000, nsIInputStream * 0x03f23df4, unsigned int 0, unsigned int 31) line 2342 + 19 bytes nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x03f20440, nsIChannel * 0x03f21d10, nsISupports * 0x00000000, nsIInputStream * 0x03f23df4, unsigned int 0, unsigned int 31) line 251 + 46 bytes nsHTTPFinalListener::OnDataAvailable(nsHTTPFinalListener * const 0x03f203e0, nsIChannel * 0x03f21d10, nsISupports * 0x00000000, nsIInputStream * 0x03f23df4, unsigned int 0, unsigned int 31) line 1191 + 46 bytes InterceptStreamListener::OnDataAvailable(InterceptStreamListener * const 0x03f23df0, nsIChannel * 0x03f21d10, nsISupports * 0x00000000, nsIInputStream * 0x038d7cb0, unsigned int 0, unsigned int 31) line 1216 nsHTTPChunkConv::OnDataAvailable(nsHTTPChunkConv * const 0x02be2db8, nsIChannel * 0x03f21d10, nsISupports * 0x00000000, nsIInputStream * 0x03fc5090, unsigned int 0, unsigned int 1233) line 211 + 46 bytes nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x03fc44e0, nsIChannel * 0x03f20e64, nsISupports * 0x03f21d10, nsIInputStream * 0x03fc5090, unsigned int 38994, unsigned int 1233) line 554 + 67 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x034f6980) line 400 + 47 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x034f48e0) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x034f48e0) line 580 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00ac3c00) line 513 + 9 bytes _md_EventReceiverProc(HWND__ * 0x059502f8, unsigned int 49369, unsigned int 0, long 11287552) line 1049 + 9 bytes USER32! 77e71820() 00ac3c00() So it seems to be getting hung up in the HTML Parser. Reassigning to Parser component for further triage -
Assignee: rogerl → harishd
Component: Javascript Engine → Parser
QA Contact: pschwartau → janc
Confirming on Mac Mozilla installer build 2000101808, Mac OS 9.0.4. Two stdlogs to play with. The first one came when I got tired of waiting for Mozilla to build the page. Mozilla would get the top and bottom of URL, make one side grey and the other side the beige color, and then sit and spin. I busted out into MacsBug to get my first stdlog. The second stdlog came when I loaded the URL again, and then attempted to turn a USB printer on an iMac DV on and then off. I could turn the printer on -- waited 30 sec per the USB book for the bus to reset -- and then turned the printer off. Boom. OS came down. Not sure what it all means, though.
Attached file MacsBug stdlog #1 per my post (deleted) —
Attached file MacsBug stdlog #2 per my post (deleted) —
Working on a fix. If the fix happens to be reasonable ( and small ofcourse ), and if a bunch of sites would benefit from this then we can even nominate this bug for rtm. Will update soon. Thanx for catching the bug.
Status: NEW → ASSIGNED
After discussing this problem with another engineer it looks like we might see some improvement, on loading the above URL, and pages with lengthy ( really really big! ) scripts, but not a whole lot ( loading other sites ). Therefore, this is definitely not going to make it thro' rtm. Btw, lots of performance work is happening in this area and with those changes the above URL *did render* pretty fast :-). So, let's bite the bullet for now..... FURTURE.
Target Milestone: --- → Future
furck.. Well well. If you want to swop it for an alert-box blur-bug instead, just cough. The "secure page" alert now takes One Minute to appear first time. (and watch out for those threads.)
R.K.Aa, is there a bug # for the alert-box blur-bug?
Not sure. I mention it in 56366 which i filed as a PSM bug, but checking that one again there seems to be at least two bugs there.
Tested with what probably is linux build ID 2000110616: NO freeze. In two different session page loaded OK. Either mozilla's credit, or the site has changed code recently.
This bug is definitely fixed. Marking WFM.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
updated qa contact.
QA Contact: janc → bsharma
Verified on build: 2001-05-03-04 Platform: winNT
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: