Closed
Bug 225187
Opened 22 years ago
Closed 22 years ago
loading this simple xml 1.1 + mathml 2.0 page crashes mozilla in gtklayout.dll
Categories
(Core :: MathML, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 218031
People
(Reporter: checker, Assigned: rbs)
References
()
Details
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•22 years ago
|
||
> 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
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
Closed: 22 years ago
Resolution: --- → DUPLICATE
|
|
||
Comment 3•21 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...
|
|
||
Comment 4•21 years ago
|
||
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•21 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•21 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...
|
|
||
Comment 7•21 years ago
|
||
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•21 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.
Description
•