225187 - loading this simple xml 1.1 + mathml 2.0 page crashes mozilla in gtklayout.dll

Status: RESOLVED DUPLICATE of bug 218031

(Core :: MathML, defect)

Description

[Chris Hecker]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

If you visit the URL on this bug
(http://www.d6.com/users/checker/mozcrash/hindex.xml, a simple xml 1.1 + mathml
2.0 page), Mozilla will crash in GTK.  If you pop into the debugger you find
Mozilla dereferencing a null pointer.

Here's the stack:

>	gklayout.dll!61554bfd() 	
 	gklayout.dll!61552009() 	
 	gklayout.dll!61551c9c() 	
 	transformiix.dll!619aa89a() 	
 	xpcom.dll!61db9864() 	
 	transformiix.dll!619a073f() 	
 	transformiix.dll!619a0749() 	
 	xpcom.dll!61d9b3d5() 	
 	transformiix.dll!619a5e8a() 	
 	xpcom.dll!61d90318() 	
 	transformiix.dll!619958a1() 	
 	xpcom.dll!61dc1195() 	
 	transformiix.dll!61995e09() 	
 	transformiix.dll!6199dfcf() 	

The registers:

EAX = 00000000 EBX = 6161C648 ECX = 00000000 
EDX = 0012F58C ESI = 00000000 EDI = 01F44158 
EIP = 61554BFD ESP = 0012F578 EBP = 0012F608 
EFL = 00000216 

And the code (A is the crash IP, skipping IP to B and running resumes mozilla
with seemingly no ill effects):

61554BEF FF 15 4C 58 60 61 call        dword ptr ds:[6160584Ch] 
61554BF5 8B 45 F8         mov         eax,dword ptr [ebp-8] 
61554BF8 8D 55 84         lea         edx,[ebp-7Ch] 
61554BFB 52               push        edx  
61554BFC 50               push        eax  
A==>61554BFD 8B 08            mov         ecx,dword ptr [eax] 
61554BFF FF 51 0C         call        dword ptr [ecx+0Ch] 
B==>61554C02 A1 50 58 60 61   mov         eax,dword ptr ds:[61605850h] 
61554C07 8D 4D 84         lea         ecx,[ebp-7Ch] 
61554C0A 89 45 E0         mov         dword ptr [ebp-20h],eax 
61554C0D 8D 45 E0         lea         eax,[ebp-20h] 
61554C10 50               push        eax  
61554C11 53               push        ebx  
61554C12 FF 15 54 58 60 61 call        dword ptr ds:[61605854h] 

Reproducible: Always

Steps to Reproduce:
1.  Visit the URL.
2.  Watch Mozilla Crash.

Actual Results:  
Access violation.

Expected Results:  
Rendered the page.

gtklayout.dll crash

Comment 1

[Boris Zbarsky [:bzbarsky]]

> Mozilla will crash in GTK

Where do you see gtk there?  "gk" stands for "gecko"; "gklayout" (not
"gtklayout") is Mozilla's Gecko layout engine.

In any case, this does not crash for me in a current Linux trunk build.  Could
you possibly test a 1.6a build and see whether that crashes for you?  There was
a MathML crasher whose fix didn't quite make 1.5....

Comment 2

[rbs]

This is crasher bug 218031 which is fixed on the trunk. m1.5 missed out.

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

Comment 3

[Xanthor Sccas]

I confirm the crash with a 1.6-based Gecko (Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.6) Gecko/20040122 Epiphany/1.0.7)

But bug 218031 which is said to be the same is fixed on my browser...

Comment 4

[Boris Zbarsky [:bzbarsky]]

Sounds like a different problem from this bug, since a current trunk gtk1
Mozilla nightly with no xft does NOT crash.  So this could be a gtk2 issue, an
xft issue, or a Epiphany issue....

Comment 5

[Jungshik Shin]

I cannot reproduce the crash on Linux with gtk2 + xft (1.6). However, my 1.6
build has a patch for Pango as well. Although unlikely, pango patch may work
around the cause. I have to try a trunk build (gtk1 + xft, gtk2+xft)

Comment 6

[Xanthor Sccas]

Sorry : in fact it doesn't seems to crash, but loading this page, Epiphany begin
using lot of memory, and so, sometimes crashes, if there isn't many memory free...

Comment 7

[Boris Zbarsky [:bzbarsky]]

Is it Epiphany using memory?  Or X/xfs?

I guess with xft it would be epiphany, huh?

Anyway, I bet the problem is that every single one of your fonts is loaded into
memory in an attempt to find the right chars.

Comment 8

[Jungshik Shin]

Xft-builds don't try every single font on the system for a glyph. Most of time,
it tries at most a couple of dozen fonts. Even if it looks into every single
font on the system, it'd not take so much memory as X11core-build takes because
fontconfig does the job very efficiently (perhaps '100' times more efficiently
than  X11core does).