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

RESOLVED DUPLICATE of bug 218031

Status

()

--
critical
RESOLVED DUPLICATE of bug 218031
15 years ago
15 years ago

People

(Reporter: checker, Assigned: rbs)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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
> 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....
Assignee: blizzard → rbs
Component: GFX: Gtk → MathML
(Assignee)

Comment 2

15 years ago
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 3

15 years ago
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...
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

15 years ago
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

15 years ago
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...
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

15 years ago
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).

You need to log in before you can comment on or make changes to this bug.