I get a crash in nsExpatTokenizer::PushXMLErrorTokens() when loading the above URL (which is *not* public, so it *must* remain internal), the crash is due to the scanner in mState being nsnull when we end up reporting an error. AFAIK from looking at the file the file is well-formed, the error we're trying to report is "no element found" at line 30, column 19.
Nominating for mozilla0.9.2
Eh jst, I need to peep at that secret file of yours :-) Looks like the crash is introduced by my patch for bug 47416. I am curious why the scanner is null in the _tokenizer_...
Looks very similar to bug 82332.
*** This bug has been marked as a duplicate of 82332 ***
rbs, I'm sorry, but I can't move that file to a public place. I can tell you tho, it's not empty :-) The crash is in the same place as the stack in bug 82332 shows, but it looks like a different situation. Let's wait for a fix for bug 82332 and reopen this if the fix for bug 82332 doesn't fix this as well.
jst, I am curious if the one-liner I made on bug 82332 solves your crash?
rbs, I bet it does, but I haven't had a chance to test it out yet...
Ok, the crash is fixed, but the page at the mentioned URL doesn't load now, no error message, nothing. When I try to load the URL the previous page remains displayed but I never see an error message from the XML paser about there being something wrong with the XML file (which I think there is). Unduping, and reopening.
17 years ago
16 years ago
Worksforme, win2k trunk build from 1/17. I bet this got fixed by harishd's XML parsing architecture change.
verified on the trunk build 2002-05-07-08-trunk on Windows 2000. Worksforme. Marking as verified