284661 - JavaScript-based extension opens chrome window -- window looks strange then Mozilla crashes [@ nsFontMetricsXft::FindFont]

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[David Costanzo]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

I maintain a JavaScript-based extension called "Dict".  It calls window.open()
to display the definitions of a selected word.  I am trying to change it from
using HTML to using chrome.  The chrome now works on Firefox, but it behaves
strangely on Mozilla and it can even crash.  I have reproduced the crash on
Mozilla 1.7.3 and Mozilla 1.8b1.

By "the window looks strange", I mean that the background is transparent and it
doesn't have a border around it (although it does have a title bar).  When I
move my mouse over the title bar, the title bar starts blinking and the CPU
meter shows the CPU is at 100%. (This might be an issue of focus, since I'm
using SloppyFocus on FVWM2).  Then, when I try to maximize the window, Mozilla
crashes.

I am bringing this to your attention even though it is a problem with an
extension because it's my understanding that a pure JavaScript extension should
not be able to cause Mozilla to crash.  This may be a bug in my window manager,
but I saw the same strange looking window under Gnome/Metacity.  I haven't tried
reproducing the crash there.


Reproducible: Always

Steps to Reproduce:
1. Load my experimental Dict extension (I can upload it if you like)
2. Define a word that has no definitions, but has close matches, 
   such as "lcome".
   This will popup a window of close matches.
3. Mouse over the title bar.
   This causes the title bar to flash and peg the CPU.
4. Click the maximize button the title bar.

Actual Results:  
Mozilla crashes

Expected Results:  
The window is maximized.

Talkback ID: TB4090149Y

I am giving this a "critical" severity because Mozilla crashed, even though this
may not be a bug in Mozilla.

The "window strangeness" may be related to bug #256496.

Comment 1

[Frank Wein [:mcsmurf]]

Stacktrace:
nsFontMetricsXft::FindFont() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/gfx/src/gtk/nsFontMetricsXft.cpp,
line 926]
nsFontMetricsXft::EnumerateXftGlyphs(unsigned const*, unsigned, unsigned
(nsFontMetricsXft::*)() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/gfx/src/gtk/nsFontMetricsXft.cpp,
line 1394]
nsFontMetricsXft::EnumerateGlyphs(char const*, unsigned, unsigned
(nsFontMetricsXft::*)() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/gfx/src/gtk/nsFontMetricsXft.cpp,
line 117]
nsFontMetricsXft::DrawString() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/gfx/src/gtk/nsFontMetricsXft.cpp,
line 265]
nsRenderingContextGTK::DrawString() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/gfx/src/gtk/nsRenderingContextGTK.cpp,
line 1315]
nsTextFrame::PaintAsciiText(nsPresContext*, nsIRenderingContext&,
nsStyleContext*, nsTextFrame::TextPaintStyle&,() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/layout/generic/nsTextFrame.cpp,
line 3322]
nsTextFrame::Paint() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/layout/generic/nsTextFrame.cpp,
line 1493]
nsContainerFrame::PaintChild() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/layout/generic/nsContainerFrame.cpp,
line 130]
nsBlockFrame::PaintChild()
nsBlockFrame::PaintChildren() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 698]
nsHTMLContainerFrame::PaintDecorationsAndChildren() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/layout/generic/nsHTMLContainerFrame.cpp,
line 139]
nsBlockFrame::Paint() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/layout/generic/nsBlockFrame.cpp,
line 5835]
nsContainerFrame::PaintChild() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/layout/generic/nsContainerFrame.cpp,
line 130]
nsContainerFrame::PaintChildren() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/layout/generic/nsContainerFrame.cpp,
line 698]
nsTableCellFrame::Paint() 
[/builds/tinderbox/SeaMonkey-Release/Linux_2.4.20-28.8_Depend/mozilla/layout/tables/nsTableCellFrame.cpp,
line 443]

Comment 2

[David Costanzo]

I reproduced the crash on a more standard windowing system (Gnome/Metacity).

I was not able to reproduce the CPU wasting with Gnome, so that might be an
FVWM2-specific problem.

I've found that the crash is not 100% reproducible.  Sometimes Mozilla locks up
(no longer accepts focus), but does not crash.  I'd say it's like 60% crash, 40%
lockup.

When I run Mozilla from the command-line, it sometimes prints out the following:
  free(): invalid pointer 0x886f6c0!

Comment 3

[David Costanzo]

Attachment: The extension that was used to crash Mozilla

Comment 4

[David Costanzo]

Attachment: XUL file that corrupts heap

This is a XUL file that resembles the XUL file that is used in
dict-crash-mozilla.xpi, except it has no JavaScript.  I haven't been able to
reproduce the crash with this file, but I can reproduce the stack corruption
printouts (which could be a different bug).

Steps to Reproduce:
1) export MALLOC_CHECK_=1
   This enables heap consistency checks in glibc

2) run "mozilla -chrome file:///downloads/crash-mozilla.xul
   This shows the XUL file.
   On my machine, the XUL is mostly transparent.

3) While the XUL window is positioned over another window,
   resize it.
   Eventually, you will see a printout like this.

malloc: top chunk is corrupt

4) Close the XUL.
   You will see a printout like this:

free(): invalid pointer 0x83e88d8!

Comment 5

[David Costanzo]

Attachment: Screenshot of attachment #176224 corrupting the heap

Comment 6

[David Costanzo]

More Info:

I was not able to reproduce the crash on my Windows 95 machine.

The crash seems related to the tranparent background in the XUL.  I added
"background: rgb(200,200,200)" to the root "window" element in the XUL file and
was no longer able to reproduce the crash.

Comment 7

[R.K.Aa.]

dup of bug 38589?

Comment 8

[David Costanzo]

I don't think it's a duplicate of bug #38589.  There are a few key differences:

1) That bug was reproduced on Windows 98.  I wasn't able to reproduce my crash
(or the strange looking window) on Windows 95.
2) That bug was reproduced on Firefox.  I wasn't able to reproduce my crash (or
the strange looking window) on Firefox.
3) That bug crashes in nsView::GetDimensions(), this one crashes in
nsFontMetricsXft::FindFont().  The rest of the stack is also completely different.
4) That bug deals with deliberatly setting semi-transparent.  In this bug, the
window is 100% transparent when it shouldn't be transparent at all.

Comment 9

[Andrew Schultz]

I loaded the attached xul file under valgrind and got:

==20678== Invalid read of size 1
==20678==    at 0x35DA8449: UpdateMaskBits(char*, int, int, nsRect const&,
unsigned char*) (nsWindow.cpp:4280)
==20678==    by 0x35DA8628: nsWindow::UpdateTranslucentWindowAlpha(nsRect
const&, unsigned char*) (nsWindow.cpp:4326)
==20678==    by 0x35DA853E: nsWindow::UpdateTranslucentWindowAlpha(nsRect
const&, unsigned char*) (nsWindow.cpp:4307)
==20678==    by 0x3598B4AB: nsViewManager::RenderViews(nsView*,
nsIRenderingContext&, nsRegion const&, nsIDrawingSurface*, nsVoidArray const&)
(nsViewManager.cpp:1443)
==20678==  Address 0x37721D22 is 0 bytes after a block of size 25650 alloc'd
==20678==    at 0x3414A65D: operator new[](unsigned) (vg_replace_malloc.c:139)
==20678==    by 0x35DA8191: CreateDefaultTransparencyBitmap(int, int)
(nsWindow.cpp:4207)
==20678==    by 0x35DA84A2: nsWindow::ApplyTransparencyBitmap() (nsWindow.cpp:4287)
==20678==    by 0x35DA5653: nsWindow::SetInternalVisibility(int) (nsWindow.cpp:2516)

(followed by many more errors and eventual death)

so it is hitting the opacity problem from the other bug.  generally when there
is memory corruption like you verified with MALLOC_CHECK, all bets are off for
how it will die (the stack might be different every time you crash).

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

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think this is not a duplicate. Reopening.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The fact that the window is transparent is not a bug. That's what you get if you
don't specify a background.

The fact that we crash with heap corruption is definitely a bug...

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

This fixes the problem. We just need to be sure to resize the transparency
bitmap if GTK changes our size externally.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

fix checked in.