crash due to missing stylesheet



20 years ago
19 years ago


(Reporter: bernd.mielke, Assigned: wtc)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2+])


(2 attachments)

Mozilla/5.0 (Windows; U; Win98; en-US; m16) Gecko/20000520 Debug

If the file with a link to a nonexisting stylesheet is loaded, mozilla chrashes.
I think I have seen this two days ago for the first time. Note when you remove
the rel="stylesheet" everything is fine. Maybe NSPR is not the right category,
could be also xpcom.

Actions to reproduce:

Download the the file.
Open the file from your local directory
Get the stack trace.

KERNEL32! bff768a0()
_PR_MD_GETFILEINFO64(const char * 0x040e2030, PRFileInfo64 * 0x040e1df0) line
776 + 41 bytes
PR_GetFileInfo64(const char * 0x040e2030, PRFileInfo64 * 0x040e1df0) line 470 +
13 bytes
nsLocalFile::ResolveAndStat(int 1) line 523 + 20 bytes
nsLocalFile::GetFileSize(nsLocalFile * const 0x040e1da0, __int64 * 0x0262fcbc)
line 1342 + 10 bytes
nsFileIO::Open(nsFileIO * const 0x040e5190, char * * 0x040e5200, int *
0x040e5230) line 135 + 30 bytes
nsFileTransport::Process() line 510 + 58 bytes
nsFileTransport::Run(nsFileTransport * const 0x040e51e4) line 484
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x0153fea0) line 689 + 12
nsThread::Main(void * 0x0153e1e0) line 84 + 26 bytes
_PR_NativeRunThread(void * 0x0153e070) line 399 + 13 bytes
_threadstartex(void * 0x015425a0) line 212 + 13 bytes
KERNEL32! bff88f20()
KERNEL32! bff869ef()
KERNEL32! bff868ec()
doron has advised me to change bug component
Component: NSPR → Style System
Product: NSPR → Browser
Version: 3.0 → other
Could you print the value of the first
argument 'fn' to _PR_MD_GETFILEINFO64()
in the debugger?  If you can invoke
GetLastError() at the time of the crash
that will be great.  Thanks.
The crash inside _PR_MD_GETFILEINFO64()
is an assertion failure at w95io.c:776.
The patch I just attached (id=8922) changes
the assertion to an error return.  Please
give this patch a try and see if it fixes
the problem.
Reminder to self: map ERROR_BAD_PATHNAME (161L).
Keywords: crash, nsbeta2
It works, I get now an error message:
CSSLoaderImpl::DidLoadStyle: Load of an URL `file://///results.css` failed. 
Error code 16389.

I cannot figure out why, there are 5 / I think there should be an absolute 
expanded path like file:///C:/....
With that patch I could get beyound this problem but there is something more 
there. The initial procedure to get the problem was to validate a html-page at 
w3c. Save the result to hard disk and to look on the results later offline. This 
crashes still. I will probably file on wednesday a new bug on that, as I am on 
travel now.
If you remove the patch and make
the browser crash in _PR_MD_GETFILEINFO64(),
can you print in the debugger the value of
the first argument 'fn', which is a string
(the file name)?  Thanks.
I am afraid, that my last statement was not quite clear. The patch is good. 
Please check it in. The failure I had seen is behind that and definetely not in 
w95io.c (xpcom or style). But as long as your patch is not checked in, it does 
not make sense to file a new bug, that only you and I can reproduce.
The reason I want to know the value of
the 'fn' argument to _PR_MD_GETFILEINFO64()
is to verify that I reproduced the right
Whiteboard: [nsbeta2+]
Component: Style System → NSPR
Product: Browser → NSPR
Target Milestone: --- → 4.0.1
Version: other → 4.0
Larry, could you review my patch?  Thanks.
Checked in the patch on the main trunk.  Note that
ntio.c needs the same patch.
/cvsroot/mozilla/nsprpub/pr/src/md/windows/ntio.c, revision 3.24
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95io.c, revision 3.18
Checked in the fix on the NSPRPUB_RELEASE_4_0_BRANCH.
/cvsroot/mozilla/nsprpub/pr/src/md/windows/ntio.c, revision
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95io.c, revision
Reviewed patch. Looks good to me.
Checked in the fix on the NSPRPUB_CLIENT_BRANCH.
/cvsroot/mozilla/nsprpub/pr/src/md/windows/ntio.c, revision
/cvsroot/mozilla/nsprpub/pr/src/md/windows/w95io.c, revision

Marked the bug fixed.
Closed: 20 years ago
Resolution: --- → FIXED
Adding verifyme keyword.
Keywords: verifyme
marking bug as verified, as is fixes the problem
Keywords: verifyme
Target Milestone: 4.0.1 → 4.0.2
You need to log in before you can comment on or make changes to this bug.