Closed
Bug 2029
Opened 26 years ago
Closed 25 years ago
Document load stalls
Categories
(Core :: CSS Parsing and Computation, defect, P1)
Tracking
()
M12
People
(Reporter: troy, Assigned: warrensomebody)
References
()
Details
(Whiteboard: Waiting for improvements in history performance)
NTDLL! 77f76148()
nsDebug::Assertion(const char * 0x0049428c
??_C@_0CK@IGKJ@change?5your?5code?5to?5use?5the?5Equa@, const char * 0x004942b8
?? :: ?? :: ?? ::PLJA::PLJA ?? `string', const char * 0x004942bc
??_C@_0BD@GA@?4?4?2public?2nsIURL?4h?$AA@, int 43) line 95 + 13 bytes
nsIURL::operator==(const nsIURL & {...}) line 43 + 32 bytes
CSSStyleSheetImpl::ContainsStyleSheet(nsIURL * 0x0146a560) line 1494 + 29 bytes
CSSParserImpl::ProcessImport(int & 0, const nsString & {"style/default.css"},
const nsString & {""}) line 731 + 21 bytes
CSSParserImpl::ParseImportRule(int & 0) line 609
CSSParserImpl::ParseAtRule(int & 0) line 535
CSSParserImpl::Parse(CSSParserImpl * const 0x0146a9a0, nsIUnicharInputStream *
0x0146aa60, nsIURL * 0x00f0d980, nsICSSStyleSheet * & 0x00000000) line 336
HTMLContentSink::LoadStyleSheet(nsIURL * 0x00f0d980, nsIUnicharInputStream *
0x0146aa60, int 1, const nsString & {""}, const nsString & {""}, nsIHTMLContent
* 0x0146ad3c) line 2703
HTMLContentSink::ProcessSTYLETag(const nsIParserNode & {...}) line 2557 + 39
bytes
HTMLContentSink::AddLeaf(HTMLContentSink * const 0x00f15c60, const nsIParserNode
& {...}) line 1810 + 12 bytes
CNavDTD::AddLeaf(const nsIParserNode & {...}) line 2954 + 22 bytes
CNavDTD::HandleStartToken(CToken * 0x00f84460) line 917 + 15 bytes
NavDispatchTokenHandler(CToken * 0x00f84460, nsIDTD * 0x00f86680) line 446 + 12
bytes
CTokenHandler::operator()(CToken * 0x00f84460, nsIDTD * 0x00f86680) line 80 + 14
bytes
CNavDTD::HandleToken(CNavDTD * const 0x00f86680, CToken * 0x00f84460, nsIParser
* 0x00f14b80) line 697 + 18 bytes
nsParser::BuildModel() line 765 + 20 bytes
nsParser::ResumeParse() line 723 + 11 bytes
nsParser::EnableParser(int 1) line 596
HTMLContentSink::ResumeParsing() line 2323
nsDoneLoadingStyle(nsIUnicharStreamLoader * 0x00fa7b40, nsString & {"/*
* Style
sheet for the CSS2 specification
* $Id: default.css,v 2.14 1998/03/24 16:16:22
bbos Exp $
*/
BODY {
color: "}, void * 0x00fa7bd0, unsigned int 0) line
2109
nsUnicharStreamLoader::OnStopBinding(nsUnicharStreamLoader * const 0x00fa7b44,
nsIURL * 0x00fa7db0, unsigned int 0, const unsigned short * 0x00fa7a40) line 148
+ 31 bytes
OnStopBindingProxyEvent::HandleEvent(OnStopBindingProxyEvent * const 0x00fa6120)
line 575
StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x00fa6124) line 453 + 12
bytes
PL_HandleEvent(PLEvent * 0x00fa6124) line 395 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00eb9810) line 357 + 9 bytes
_md_EventReceiverProc(HWND__ * 0xc46f0240, unsigned int 49308, unsigned int 0,
long 15439888) line 675 + 9 bytes
USER32! 77e71250()
00eb9810()
Updated•26 years ago
|
Assignee: peterl → vidur
Summary: Assert in ContainsStyleSheet() → Document load stalls
Comment 1•26 years ago
|
||
The assertion has been fixed.
But now this page (and several others in the CSS1 test spec) seems to stall on
document load.
I don't know if this is a netlib cache issue of a problem in the async loading
code. Vidur, can you please take a look?
Updated•26 years ago
|
Assignee: vidur → peterl
Comment 3•26 years ago
|
||
There are 2 problems with this document:
1) Construction and layout of this document is especially slow. I put a break in
the code that loads the style sheet and the loading completes reasonably
quickly. There seems to be a long delay, however, after we load the style sheet
and before we see anything. I tried breaking several times during that delay and
found that we were in frame construction code, often with style resolution
happening at the top of the stack. I suspect that this code is even slower since
we delete existing frames once the new style sheet comes in.
2) Netlib seems to be ignoring the result code from stream methods.
Specifically, the process of deleting frames once the new style sheet comes in
interrupts image loading. The interrupted image consumer returns an error value
of MK_INTERRUPTED from its OnDataAvailable() method and never reads from
the stream again. Netlib doesn't seem to interpret this as the end of the line
and still keeps the stream alive. Of course, no one is reading from the other
end of the stream, so the loading animation continues indefinitely. Note that
this is highly timing dependent (it won't happen if the image loads before the
style sheet).
The first problem is something that Peter should probably look at. The second is
probably Gagan's problem and may warrant a second bug. I'll leave that up to you
Peter. ;-)
Updated•26 years ago
|
QA Contact: 4110 → 4144
Comment 4•26 years ago
|
||
Updated•26 years ago
|
Target Milestone: M5 → M6
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M6 → M8
Comment 6•26 years ago
|
||
The delay isn't a sheet load issue. There's a problem where due to the large
number of links, a large nuber of style contexts are (unnecessarily) being
created. I have a fix in mind...
Updated•26 years ago
|
Target Milestone: M8 → M9
Comment 7•26 years ago
|
||
Partial fix checked in. We now create a whole lot less style contexts for this
page (and many like it). Unfortunately, the code to determine whether a link has
been visited is dog slow. I'm going to spank that next.
Updated•26 years ago
|
Whiteboard: Waiting for improvements in history performance
Target Milestone: M9 → M10
Updated•25 years ago
|
Assignee: peterl → waterson
Status: ASSIGNED → NEW
Comment 8•25 years ago
|
||
This may be as good as it gets for now. Waterson, please close this unless you
have more performance work on deck for history.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M10 → M12
Comment 9•25 years ago
|
||
Peter, can you point me to the page that you're using to test stuff? I've
replaced the history back-end with what should be its final implementation;
however, I haven't done any tuning at all. I can go ahead and take a pass
through the history back-end to pick up any slack there.
Comment 10•25 years ago
|
||
Oops. Add peterl to cc list. Peter, can you update the URL to refer to the test
case you're using? thanks.
Comment 11•25 years ago
|
||
The current URL is accurate (CSS2 spec title page).
Reporter | ||
Comment 12•25 years ago
|
||
Peter, I noticed in my Quantify runs this week the same thing, that
NS_MakeAbsoluteURL is probably the slowest routine on the face of the earth
I'm interested in solving that problem as well, so I'll give you a call and see
what we can do about it (either get Necko to speed it up, or find a faster
alternative)
Updated•25 years ago
|
Assignee: waterson → warren
Status: ASSIGNED → NEW
Comment 13•25 years ago
|
||
Ok, so the big problem here seems to be NS_MakeAbsoluteURL(). Warren, I'm
giving this love to you: can you profile and improve performance?
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Comment 14•25 years ago
|
||
If there's more to this bug than MakeAbsolute performance, please reopen.
Otherwise this is a dup.
*** This bug has been marked as a duplicate of 10736 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 15•25 years ago
|
||
Based on Warren's comments, marking as verified duplicated of 10736.
You need to log in
before you can comment on or make changes to this bug.
Description
•