Closed Bug 30026 Opened 26 years ago Closed 26 years ago

browser crashes when loading this page

Categories

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

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: shrir, Assigned: rickg)

References

()

Details

(Whiteboard: [PDT+] fix in hand (reviewed and tested): eta to checkin 3/9)

Pls reassign to correct component if wrong. I used yesterday's commercial bits. Trying to visit the url mentioned above crashes the browser. The stack trace is not much significant. It says: Trigger Type: Program Crash Trigger Reason: Access violation Thread ID: Call Stack: (Signature = nsParser::EnableParser b8bc86f5) nsParser::EnableParser [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 817] CSSLoaderImpl::Cleanup [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 675] CSSLoaderImpl::ParseSheet [d:\builds\seamonkey\mozilla\layout\html\style\src\nsCSSLoader.cpp, line 780]
cc: john
This is crashing in nsParser::EnableParser(), the parser checks if eOnStop == mParserContext->mStreamListenerState but mParserContext is null! Changing component to Parser and reassigning.
Assignee: vidur → rickg
Component: DOM Level 0 → Parser
QA Contact: desale → janc
Actually -- the parser is only responding to direction (correctly). The bug is in the style system. Reassigning to markA.
Assignee: rickg → attinasi
PDT team: it's a trival kill, and I have the fix in hand. The crash makes me want to fix this for beta.
Status: NEW → ASSIGNED
Keywords: beta1
Per Friday's closing PDT meeting discussion, I'm moving this up to PDT+ over the weekend. (i.e., it is an obvious +, especially with a simple advertised fix).
Assignee: attinasi → rickg
Status: ASSIGNED → NEW
Whiteboard: [PDT+] for fix in hand w/b minus on 3/6
Oops -- my remarks were intended for a different bug. Nonetheless, I agree with the importance of this crash (which appears to be in the style code as my earlier comment stated) so I'll work with MarkA to fix it on monday.
Status: NEW → ASSIGNED
Removed fix in hand from status whiteboard. Will look into this today.
Whiteboard: [PDT+] for fix in hand w/b minus on 3/6 → [PDT+] w/b minus on 3/6
With Rick's help I have come up with a fix. When the parser is disabled we need to make sure we do not ResumeParse and pop the context. Added a check for disabled in two Parse routines and there, when disabled, short-circuited the parse call without calling ResumeParse and then popping the context. Will checkin today, after running pre-checkins. Reassigning to myself so I can update to FIXED after checkin.
Assignee: rickg → attinasi
Status: ASSIGNED → NEW
According to the notes, this is fixed. Did you forget to mark this as such, or is there a problem??
There is a problem: the change I made fixes the crash but causes some pages (www.ebay.com) to be missing some content. I have a fix for that too but it is a hack and I am trying to get together with Rick to make sure it is OK for now. Please give me another day to get some of Rick's time on this. I'll update the bug once I discuss it with him.
Status: NEW → ASSIGNED
Please open a new bug for content corrections/adjustments. This bug had the PDT+ based on crashing. If that crash is fixed, then this should be closed, and a new bug opened, and nominated if the content that is lost is critical and common. Thanks, Jim
No need to bother opening a new bug for an incomplete fix - Rick and I have spent some time on this today and he has a complete fix for the crash that does not break other pages (a correct fix, not my hack). Reassigning to Rick, his ETA for checkin: 3/9
Assignee: attinasi → rickg
Status: ASSIGNED → NEW
Whiteboard: [PDT+] w/b minus on 3/6 → [PDT+] fix known: eta to checkin 3/9
*** Bug 27235 has been marked as a duplicate of this bug. ***
Ok the fix has been reviewed and verified by attinasi. He and Harish and I will run with this awhile before landing. I'll land this tonight or tomorrow.
Status: NEW → ASSIGNED
The fix seems to be working on the top 100, but I want to do more testing tomorrow before landing. It will be ready.
Rick, Can you update the landing plan in on the status whiteboard, and in the bug. Thanks
Whiteboard: [PDT+] fix known: eta to checkin 3/9 → [PDT+] fix in hand (reviewed and tested): eta to checkin 3/9
Sorry for the delay. The fix was landed on Friday on the tip. Chofmann asked me to wait a day to land it on the branch.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Verified 2000-03-13-18-M15-nb1b
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.