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 bytes 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

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).

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 bug.

[nsbeta2+]

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 3.20.4.9 /cvsroot/mozilla/nsprpub/pr/src/md/windows/w95io.c, revision 3.16.4.5

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 3.21.2.2 /cvsroot/mozilla/nsprpub/pr/src/md/windows/w95io.c, revision 3.17.2.1 Marked the bug fixed.

Adding verifyme keyword.

marking bug as verified, as is fixes the problem