Closed
Bug 55734
Opened 24 years ago
Closed 24 years ago
page freeze moz during load
Categories
(Core :: DOM: HTML Parser, defect, P3)
Core
DOM: HTML Parser
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.
Comment 1•24 years ago
|
||
The left frame (http://shop.nordata.net/meny.asp) freezes all Mozilla windows
for about ten seconds on Win98. All/all, perf.
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"
Comment 3•24 years ago
|
||
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
Comment 4•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
Comment 6•24 years ago
|
||
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.)
Assignee | ||
Comment 10•24 years ago
|
||
R.K.Aa, is there a bug # for the alert-box blur-bug?
Reporter | ||
Comment 11•24 years ago
|
||
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.
Reporter | ||
Comment 12•24 years ago
|
||
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.
Assignee | ||
Comment 13•24 years ago
|
||
This bug is definitely fixed. Marking WFM.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Comment 15•24 years ago
|
||
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.
Description
•