build# 1999070608 the following message came up when attempting to view the source-code for the mozilla.org "development" subdirectory "APPRUNNER caused an invalid page fault in module MSVCRT.DLL at 015f:7800d0b9. Registers: EAX=006a6f20 CS=015f EIP=7800d0b9 EFLGS=00010202 EBX=00000000 SS=0167 ESP=0063ec64 EBP=0063ec80 ECX=01a879b0 DS=0167 ESI=01a877cc FS=32f7 EDX=00000000 ES=0167 EDI=00000008 GS=0000 Bytes at CS:EIP: 89 5a 04 8b 55 0c 89 4d fc 8b 5a 04 8b 52 08 89 Stack dump: 00000000 01a877d0 608b7b24 006a8084 01a87920 00000041 00000090 0063ecc4 7800cc1c 0075005c 01a8785c 00000000 0063ed08 608b7b24 00000024 00000000 " on attempting to duplicate the error, at www.aj.com (attempting to view page- source there) "opening view or source" was the last (or perhaps second-to-last) message displayed in apprunner window, before this happened: APPRUNNER caused an invalid page fault in module MSVCRT.DLL at 015f:7800d0b9. Registers: EAX=006f1a5c CS=015f EIP=7800d0b9 EFLGS=00010206 EBX=00000000 SS=0167 ESP=00e9f860 EBP=00e9f87c ECX=01a7d060 DS=0167 ESI=01a7d00c FS=3297 EDX=00000000 ES=0167 EDI=00000007 GS=0000 Bytes at CS:EIP: 89 5a 04 8b 55 0c 89 4d fc 8b 5a 04 8b 52 08 89 Stack dump: 00000000 01a7d010 00000000 006f29bc 01a7d050 ffffffff 00000010 00e9f8c0 7800cc1c 0075005c 01a7d01c 00000000 01a7eea0 00000000 00000000 bff7b9b6 this was the first time i'd seen that little (approx 1/4 the size of the default mozilla startup window-size) window pop up, which i assume is supposed to be for viewing the source-code on attempting to view source for included test0.html page "opening view of source for resource: "(...directory structure...)"test0.html" "calling handle url" was all i saw before APPRUNNER caused an invalid page fault in module MSVCRT.DLL at 015f:7800d0b9. Registers: EAX=006d6e70 CS=015f EIP=7800d0b9 EFLGS=00010202 EBX=00000000 SS=0167 ESP=0063ec64 EBP=0063ec80 ECX=01664e10 DS=0167 ESI=01664cec FS=254f EDX=00000000 ES=0167 EDI=00000004 GS=0000 Bytes at CS:EIP: 89 5a 04 8b 55 0c 89 4d fc 8b 5a 04 8b 52 08 89 Stack dump: 00000000 01664cf0 608b7b24 006d77c4 01664dc0 00000041 00000050 0063ecc4 7800cc1c 0075005c 01664d3c 00000000 0063ed08 608b7b24 00000020 00000000 now i see why you warn about the nightly builds ;) hope this helps

Yep, it dies for me too. Radha, can you take a look at this since Bill is on vacation?

I couldn't reproduce this in my solaris build. In windows, I could not reproduce when running from the debugger. When running outside the debugger, it worked sometimes and the app just quit with out any error condition. ie., my debug build, did not invoke the debugger as it would when it encounters a crash condition. Shall watch for few days.

This crashes in, layout:html/base/src/nsTextFrame.cpp::nsTextFrame::ComputeWordFragmentWidth() in the following segment, PRUint32 copylen = 2*( ((wordLen + aWordBufLen) > aWordBufSize) ? (aWordBufSize - aWordBufLen) : wordLen ); if(copylen > 0) { nsCRT::memcpy((void*)&(aWordBuf[aWordBufLen]), buf, copylen); ... } copylen gets evaluated to a negative number, but since it is a PRUInt, bad things happen and copylen turns out to be a huge number,which is passed to memcpy. memcpy fails silently with out even a core file because of this. Frm cvsblame, it looks like, Frank Tang touched this code last on July 27. I modified the PRUint to be PRInt32. This seemed to have fixed the problem in linux, but not in windows. Even in linux, after I made the change, it takes a long time to bring up the view source window. Maybe some cyclic computations happen. CC'ing ftang, hoping he can throw some light.

This crashes in, layout:html/base/src/nsTextFrame.cpp::nsTextFrame::ComputeWordFragmentWidth() in the following segment, PRUint32 copylen = 2*( ((wordLen + aWordBufLen) > aWordBufSize) ? (aWordBufSize - aWordBufLen) : wordLen ); if(copylen > 0) { nsCRT::memcpy((void*)&(aWordBuf[aWordBufLen]), buf, copylen); ... } copylen gets evaluated to a negative number, but since it is a PRUInt, bad things happen and copylen turns out to be a huge number,which is passed to memcpy. memcpy fails silently with out even a core file because of this. Frm cvsblame, it looks like, Frank Tang touched this code last on July 27. I modified the PRUint to be PRInt32. This seemed to have fixed the problem in linux, but not in windows. Even in linux, after I made the change, it takes a long time to bring up the view source window. Maybe some cyclic computations happen. CC'ing ftang, hoping he can throw some light.

*** Bug 10916 has been marked as a duplicate of this bug. ***

*** Bug 11624 has been marked as a duplicate of this bug. ***

I'm taking over this bug. It's looking like a Necko or layout bug of some sort, though.

*** Bug 12053 has been marked as a duplicate of this bug. ***

*** Bug 12338 has been marked as a duplicate of this bug. ***

*** Bug 12015 has been marked as a duplicate of this bug. ***

*** Bug 13019 has been marked as a duplicate of this bug. ***

Most of the duplicates of the bug is marked 'critical' as well as 'P1', so I'm making the same modifications here.

*** Bug 13063 has been marked as a duplicate of this bug. ***

I can't claim credit, but this problem has been fixed. Something changed in netlib or html parsing to cure it.

Yep..looks good. Marking Verified.

reopening this bug --it occurs with today's (1999-12-07-xxm12) builds on Mac and NT only. (linux doesn't crash.) might be related to the fix made for 20700.

Clearing FIXED resolution due to reopen.

*** Bug 20960 has been marked as a duplicate of this bug. ***

Updating QA Contact.

Moving to M12 (for obvious reasons).

The most recent comment added to bug #20700 indicates that "view source" is now working (again). I don't think there's a problem, marking WORKSFORME.

actually, i did manage to repro this using today's non-commercial mozilla build 99120808 on NT. here's the recipe: 1. make sure Side Bar is open. 2. go to View Source result: the Source win appears...starts loading...then mozilla crashes. expected: Source win should display the source w/o crashing, regardless of Side Bar existence. anyone else experiencing this on other platforms?

clarified summary

This crash is already covered in bug 20691 which is currently owned by waterson. It's a problem with brutal content sharing and is somewhat random. I'd suggest reclosing this bug and interested parties can follow 20691.

resolving this as a dup of bug 20691 as per mscott's advice... besides, that one is dogfood anyhow. ;-) *** This bug has been marked as a duplicate of 20691 ***