91597 - Invalid page fault in GKCONTENT.DLL

Status: VERIFIED DUPLICATE of bug 91538

(Core :: DOM: HTML Parser, defect)

Description

[Jon Rubin]

Reproducible on Win98-En using 07-19-05-branch build.  Could not reproduce on
WinMe-Ja using same build.  I submitted several talkbacks.  This is the error
message given by Win98:

NETSCP6 caused an invalid page fault in
module GKCONTENT.DLL at 017f:6021d3f3.
Registers:
EAX=00000000 CS=017f EIP=6021d3f3 EFLGS=00010206
EBX=80000000 SS=0187 ESP=0068f5a4 EBP=0068f7b4
ECX=0068f7a4 DS=0187 ESI=00000000 FS=519f
EDX=0068f678 ES=0187 EDI=00000000 GS=0000
Bytes at CS:EIP:
8b 06 51 56 ff 50 34 85 c3 0f 85 94 00 00 00 8b 
Stack dump:
0307f130 0330cbd8 00000043 0038000c 003803ca 0068f6a0 bff9e5ee 0068f5c8 0068f6b0
6c2b16a0 78026b4c 6c2b16a0 00235ef3 00989680 00000000 00000000 

This is the talkback stack trace:

HTMLContentSink::ProcessMETATag
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp,
line 4525]
HTMLContentSink::AddLeaf
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLContentSink.cpp,
line 3390]
CNavDTD::AddLeaf [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 3796]
CNavDTD::AddHeadLeaf [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp,
line 3855]
CNavDTD::HandleStartToken
[d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp, line 1750]
CNavDTD::HandleToken [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp,
line 924]
CNavDTD::BuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\CNavDTD.cpp,
line 549]
nsParser::BuildModel [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp,
line 2222]
nsParser::ResumeParse [d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp,
line 2086]
nsParser::OnDataAvailable
[d:\builds\seamonkey\mozilla\htmlparser\src\nsParser.cpp, line 2696]
nsDocumentOpenInfo::OnDataAvailable
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 236]
nsStreamListenerTee::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerTee.cpp, line 57]
nsHttpChannel::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpChannel.cpp, line 2227]
nsOnDataAvailableEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsStreamListenerProxy.cpp, line 188]
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591]
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 524]
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1072]
KERNEL32.DLL + 0x24407 (0xbff94407)
0x00688b5e 

Bug 77708 also had involved a crash in GKCONTENT.

Comment 1

[Jon Rubin]

The page in question contains the Trademark (TM) character (alt+0153).  A
possible cause?

Comment 2

[Jon Rubin]

Okay, I've narrowed this down.  My suspicion about the TM character led me to
test what happens with various Character Coding settings (in View>Character
Coding).  First I noticed that Auto-Detect was set to "All".  When I set it to
"Off", the crash did not occur.  It also did not occur if I set it to Russian or
Ukranian.  But setting Auto-Detect to the Double-Byte languages, such as Korean
or Japanese, caused a crash.  I suspect it has something to do with the TM
character in that page.  Also, I can now make the crash occur on WinMe-Ja by
changing the Auto-Detect settings.

Comment 3

[Jon Rubin]

The crash does not occur if I go to Character Coding>More>East Asian and then
choose any of the Japanese codings (checked this on WinMe-Ja).  It does crash if
I choose Japanese in Auto-Detect.

Comment 4

[Jon Rubin]

Just reproduced this problem on MacOS9.1 using 07-19-03 branch build.  I could
not reproduce this problem on Windows or Mac using 07-18-branch builds.  Several
people are saying they didn't see the problems in bug 91531 in yesterday's
branch builds either.

Changing Platform to All.

Comment 5

[Jon Rubin]

Reproduced on Linux RH 7.1 Ja using 07-19-04-branch build.  Could not reproduce
using 07-18-04-branch build.  Next step would be to see if this crash happens on
other pages displaying the Trademark symbol.

Comment 6

[Jon Rubin]

Not sure if the TM symbol is at fault.  Other pages using TM symbol do not crash.

Comment 7

[Katsuhiko Momoi]

Shanjian, Frank, Harish, Vidur, please look at this ASAP.
Here are some things to think about:

1. The page contains the meta tag for ISO-8859-1.
2. It contains the 8-bit trademark character (0x99), 
   which is an illegal character under this encoding.
3. So if you change the encoding to "Windows-1252",this
   crash does not occur.
4. According to jon, this crash occurs when auto-detection
   for CJK or ALL is tunred ON. In other auto-detection (single-byte
   type), it does not happen.

What we need to determeine are:

1.  How widespeard this type of incorrect meta charset would 
    be when the page contains Windows-1252 only 8-bit character,
    and not NCRs. 
    
2. Why non-single byte auto-detection causes the crash.

I am going to mark this as 'nsbranch' to get attention 
of the PDT and the i18n & DOM engineers. Please evaluate the
risks carefully and see whether or not we can pass on
this for the NSbranch.

Comment 8

[selmer (gone)]

Kat, please send email to pdt2 instead.  Putting nsBranch keyword doesn't get
this on our radar (there are over 100 such bugs and it means something different
than what you intend.)

Comment 9

[Katsuhiko Momoi]

Thanks, Steve. Will do.

Comment 10

[harishd]

Kat: This problem could be due to bug 90288 ( also ref. to bug 91543). I think
gagan backed out his changes yesterday around 10:00PM. Please try today's branch
build. In the mean time I'll investigate the problem.

Comment 11

[harishd]

also ref. to bug 91538

Comment 12

[harishd]

No doubt this is a dupe of  bug 91538. Since gagan backed out his changes to bug
90288 we shouldn't see this crash anymore. 

Bindu: Could you please verify this crash on today's branch build?

Comment 13

[Jon Rubin]

I just checked today's branch build (07-20-06-branch) and I didn't experience
the crash.  

Comment 14

[harishd]

*** This bug has been marked as a duplicate of 91538 ***

Comment 15

[bsharma]

Verified on 2001-07-19-05-0.9.2 on WinNT

The above url does not crash.

Comment 16

[Moied]

Verified as a duplicate of 91538  which is fixed.