58.74 KB, application/x-xpinstall
367 bytes, application/vnd.mozilla.xul+xml
16.69 KB, image/png
1.86 KB, patch
|Details | Diff | Splinter Review|
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]
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!
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.
dup of bug 38589?
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.
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Version: 1.7 Branch → Trunk
I think this is not a duplicate. Reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
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...
Created attachment 179023 [details] [diff] [review] fix This fixes the problem. We just need to be sure to resize the transparency bitmap if GTK changes our size externally.
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago → 14 years ago
Resolution: --- → FIXED
Crash Signature: [@ nsFontMetricsXft::FindFont]
You need to log in before you can comment on or make changes to this bug.