http://bugs.winehq.org/show_bug.cgi?id=12307
Summary: firefox 3 beta 4 crash on some web pages Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: NEW Keywords: download Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
This happened three times in a row with http://heise.de, but of course doesn't happen anymore. The only symptom was a hang halfway through loading, plus a backtrace:
Unhandled exception: page fault on read access to 0x066d1140 in 32-bit code (0x7e2901e1). Backtrace: =>1 0x7e2901e1 X11DRV_XRender_ExtTextOut+0x551(physDev=0x1a7e28, x=0x1b, y=0x95, flags=0x2010, lprect=0x34c4d0, wstr=0x34cdf8, count=0xc, lpDx=0x140110) [dlls/winex11.drv/xrender.c:1306] in winex11 (0x0034c238) 2 0x7e27683d X11DRV_ExtTextOut+0x5d(physDev=0x1a7e28, x=0x1b, y=0x95, flags=0x2010, lprect=0x34c4d0, wstr=0x34cdf8, count=0xc, lpDx=0x140110) [dlls/winex11.drv/text.c:55] in winex11 (0x0034c2f8) 3 0x7e9545b2 ExtTextOutW+0xac2(hdc=0xee18, x=0x1b, y=0x95, flags=0x2010, lprect=0x0, str=0x34cdf8, count=0xc, lpDx=0x34c5f8) [dlls/gdi32/font.c:1950] in gdi32 (0x0034c518) 4 0x6067f38b in xul (+0x1cf38b) (0x0034d038)
0x7e2901e1 X11DRV_XRender_ExtTextOut+0x551 [/home/dank/wine-git/dlls/winex11.drv/xrender.c:1306] in winex11: movswl 0x8(%eax),%edi 1306 current.x += (elts[idx].xOff + formatEntry->gis[wstr[idx]].xOff);
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #1 from Marcel Partap mpartap@gmx.net 2008-04-16 05:48:09 --- Created an attachment (id=12236) --> (http://bugs.winehq.org/attachment.cgi?id=12236) tail of console output with WINEDEBUG=font,xrender
http://bugs.winehq.org/show_bug.cgi?id=12307
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ovek@arcticnet.no
--- Comment #2 from Dan Kegel dank@kegel.com 2008-05-22 00:27:27 --- *** Bug 12764 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=12307
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|firefox 3 beta 4 crash on |firefox 3 beta 4 crash on |some web pages |some web pages [dogfood]
--- Comment #3 from Dan Kegel dank@kegel.com 2008-05-22 00:31:10 --- Adding [dogfood] to make it easier to find 'dogfood challenge' bugs.
http://bugs.winehq.org/show_bug.cgi?id=12307
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|firefox 3 beta 4 crash on |firefox 3 crash on some web |some web pages [dogfood] |pages [dogfood]
--- Comment #4 from Dan Kegel dank@kegel.com 2008-05-22 15:15:49 --- Seeing this repeatably when viewing the url http://www.astonshell.com/aston/ with firefox 3 rc1 (previous reports were about beta 4).
http://bugs.winehq.org/show_bug.cgi?id=12307
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Target Milestone|--- |1.0.0
--- Comment #5 from Dan Kegel dank@kegel.com 2008-05-22 18:11:03 --- This happens about once an hour, sometimes more often. It makes firefox 3 almost unusable in wine.
Nominating for 1.0, though we will almost certainly defer it, since it's not a regression.
http://bugs.winehq.org/show_bug.cgi?id=12307
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
--- Comment #6 from James Hawkins truiken@gmail.com 2008-05-22 19:33:08 --- Not major ;)
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #7 from Dan Kegel dank@kegel.com 2008-05-22 19:59:42 --- ... for a wide range of web pages? :-)
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #8 from Dan Kegel dank@kegel.com 2008-05-24 13:37:48 --- Saw this show up associated with a visual problem once: in a gmail signin page, which was autofilled with my username and password, the autofilled text was all on top of each other, as was the label on the login button. I fooled around trying to erase the username and type it in again, and then the crash (with same stack) happened. I suspect something is clobbering a font structure somewhere...
http://bugs.winehq.org/show_bug.cgi?id=12307
Paul Broadbent dbdkmezz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dbdkmezz@gmail.com
--- Comment #9 from Paul Broadbent dbdkmezz@gmail.com 2008-05-31 17:18:22 --- Firefox 3 is consistently crashing for me when playing videos on the bbc iplayer website. Go to http://www.bbc.co.uk/iplayer/ and just try playing a video, boom! Works fine in FF2
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2008-06-02 12:40:01 --- (In reply to comment #8)
I think the font structures are fine, it's just that we get a garbage string that causes reference to non-existent glyphs. We should instead fall back to a default glyph in that case.
http://bugs.winehq.org/show_bug.cgi?id=12307
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.0.0 |1.2.0
--- Comment #11 from Dan Kegel dank@kegel.com 2008-06-09 11:56:15 --- firefox 2 is an ok workaround for now. wine 1.0 is in deep code freeze, and we don't have good analysis on this one yet, so deferring.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #12 from Dmitry Timoshkov dmitry@codeweavers.com 2008-06-10 08:57:27 --- The following patch fixes the crash for me:
http://www.winehq.org/pipermail/wine-patches/2008-June/055710.html
http://bugs.winehq.org/show_bug.cgi?id=12307
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.2.0 |1.0.0
--- Comment #13 from Dan Kegel dank@kegel.com 2008-06-10 09:35:37 --- Thanks, I tried it, and was able to browse for several minutes without a crash. I'll keep testing it, hopefully this is a real fix.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #14 from Dmitry Timoshkov dmitry@codeweavers.com 2008-06-10 09:41:21 --- (In reply to comment #13)
Thanks, I tried it, and was able to browse for several minutes without a crash. I'll keep testing it, hopefully this is a real fix.
Alexandre said it is not: http://www.winehq.org/pipermail/wine-devel/2008-June/066303.html
http://bugs.winehq.org/show_bug.cgi?id=12307
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.0.0 |1.0.1
--- Comment #15 from Dan Kegel dank@kegel.com 2008-06-11 16:29:37 --- 1.0 is breathing down our necks. Deferring to 1.0.1 (and possibly later).
http://bugs.winehq.org/show_bug.cgi?id=12307
Michael Karcher wine@mkarcher.dialup.fu-berlin.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@mkarcher.dialup.fu- | |berlin.de
--- Comment #16 from Michael Karcher wine@mkarcher.dialup.fu-berlin.de 2008-08-18 16:51:48 --- The patches linked here fix the symptom, but not the cause. Wine crashes because there are invalid glyph indices in an ExtTextOutW with ETO_GLYPH_INDEX. The log shows many working ExtTextOuts, where the indices are well below 256, and the crashing one with indices that all have their *low* byte zero.
Probably there are two bugs to fix: Wine should not crash on bad glyph indices (symptom), and also Firefox should not provide bad glyph indices at all (cause). Wether the latter is a Firefox or a Wine bug is yet to be determined.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #17 from Michael Karcher wine@mkarcher.dialup.fu-berlin.de 2008-08-18 17:21:40 --- Part of the real bug seems to be that usp10.ScriptShape does not check the result of GetGlyphIndicesW. When GetGlyphIndices fails (which it does for an up to now unknown reason), it leaves uninitialized data in the output buffer. As this failure does not get propagated, this garbage glyph numbers get finally into GetTextOut.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #18 from Austin English austinenglish@gmail.com 2008-08-18 20:36:18 --- (In reply to comment #16)
While it is a bug on Firefox's end to send the bad glyphs, if windows handles it fine, Wine should as well.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #19 from Dan Kegel dank@kegel.com 2008-08-18 22:06:31 --- Sure. The interesting question is, does Firefox send bad glyphs *because* of a Wine bug? If so, perhaps this bug needs to be split into two: one to avoid crashing on bad glyphs, and one to avoid generating them.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #20 from Michael Karcher wine@mkarcher.dialup.fu-berlin.de 2008-08-19 01:37:11 --- Its an uniscript bug, not a Firefox bug.
ScriptPlace is called with hdc=0. According to MSDN this is OK, and means to use cached metrics/indices information only. Wine puts a DC into the script cache when it is created, and tries to use this DC to obtain font information, regardless of what DC is passed. This is wrong. Wine must use the DC passed to ScriptPlace instead. The crash is caused by the DC in the cache (which should not be there!) being stale. The stale hDC creates a chain reaction that leads to the crash: a) GetGlyphIndicesW fails because of the stale DC in the cache. This failure does not get propagated in ScriptPlace, so ScriptPlace returns garbage in it output buffer without telling anyone that there is garbage. b) ExtTextOutW is called with a valid DC and the uninitialized glyph index list. This causes GetGlyphOutline to fail, as these uninitialized values are invalid. c) This causes UploadGlyph to fail. d) This causes a crash in ExtTextOutW later.
The suggested patches fix d), which is worth fixing, but the real problem is that Wine's SCRIPT_CACHE contains a DC the application might have (and firefox does so) deleted a long time ago.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #21 from Michael Karcher wine@mkarcher.dialup.fu-berlin.de 2008-08-19 01:49:55 --- Created an attachment (id=15480) --> (http://bugs.winehq.org/attachment.cgi?id=15480) Trimmed down relay log
Parts of a relay,font,uniscribe log used a base for my analysis
http://bugs.winehq.org/show_bug.cgi?id=12307
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
--- Comment #22 from Hans Leidekker hans@meelstraat.net 2008-08-19 02:32:49 ---
This suggests that we'd have to call GetGlyphIndicesW earlier and put the result in the cache too. This probably affects more gdi calls.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #23 from Michael Karcher wine@mkarcher.dialup.fu-berlin.de 2008-08-19 02:59:20 --- No, it does not mean you have to call GetGlyphIndicesW earlier. You can do that, and you should put the result into the cache then, but even at that point you might decide that you need to call GetGlyphIndicesW right now, and return STATUS_PENDING. In that case, the application should retry the call with a valid DC instead of a null DC. MSDN reads like Windows puts the character to glyph index map into the cache, but I don't know whether it gets the whole map at the beginning or incrementally builds the map for character codes or unicode blocks.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #24 from Michael Karcher wine@mkarcher.dialup.fu-berlin.de 2008-08-19 03:02:32 --- Most importantly, it means that you should not put hdc into the cache. If you need a DC, you may only use the one provided right to this call. If none was provided, return STATUS_PENDING. And it also means you should check for errors in calls you perform, especially if these calls have out parameters like GetGlyphIndicesW.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #25 from Hans Leidekker hans@meelstraat.net 2008-08-20 06:27:57 ---
The DC is in the cache because gdi calls need it. Returning STATUS_PENDING whenever we call a gdi function it is not going to work because that is not how Windows behaves. I agree that the DC should be banned from the cache though and that's why I'm suggesting we should call gdi functions earlier and cache the results.
http://bugs.winehq.org/show_bug.cgi?id=12307
Detlef Riekenberg wine.dev@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.0.1 |1.2.0
--- Comment #26 from Detlef Riekenberg wine.dev@web.de 2008-09-12 09:59:11 --- The Milestone Wine 1.0.1 is for Bugs, where the fix is nominated to be backported to the stable Wine 1.0 release.
Deferring to Wine 1.2.0
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #27 from Dan Kegel dank@kegel.com 2008-10-01 09:32:48 --- This is still happening, and it kind of makes firefox unreliable enough to be unusable for routine use.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #28 from Hans Leidekker hans@meelstraat.net 2008-10-06 06:05:57 --- Created an attachment (id=16498) --> (http://bugs.winehq.org/attachment.cgi?id=16498) usp10: Store glyph mappings and widths in the script cache.
Can you try this patch Dan?
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #29 from Dan Kegel dank@kegel.com 2008-10-06 08:49:05 --- So far so good. Been using it for five minutes without obvious trouble. (I see that text in <code> brackets is inexplicably rendered as symbols, and that gmail doesn't show bold at all without 'winetricks corefonts', but I doubt those were caused by your patch.)
http://bugs.winehq.org/show_bug.cgi?id=12307
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #30 from Dan Kegel dank@kegel.com 2008-10-08 08:46:56 --- Been using the patch for hours now, works a treat.
http://bugs.winehq.org/show_bug.cgi?id=12307
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #16498|0 |1 is obsolete| |
--- Comment #31 from Hans Leidekker hans@meelstraat.net 2008-10-08 09:50:53 --- Created an attachment (id=16540) --> (http://bugs.winehq.org/attachment.cgi?id=16540) usp10: Store glyph mappings and widths in the script cache.
Thank you for testing Dan. I've been running this improved version for a while now on gmail, heise.de and some Chinese sites. I've switched to sparse allocation scheme so that it uses much less memory on average.
http://bugs.winehq.org/show_bug.cgi?id=12307
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|winex11.drv |usp10
http://bugs.winehq.org/show_bug.cgi?id=12307
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #32 from Hans Leidekker hans@meelstraat.net 2008-10-10 09:58:54 --- Patch was committed as addcf866cbb42309ccafa41e8424c3b80a00a7ba
http://bugs.winehq.org/show_bug.cgi?id=12307
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #33 from Alexandre Julliard julliard@winehq.org 2008-10-24 11:13:14 --- Closing bugs fixed in 1.1.7.
http://bugs.winehq.org/show_bug.cgi?id=12307
--- Comment #34 from Dan Kegel dank@kegel.com 2008-11-27 10:27:58 --- Oddly, a test failed recently with a very similar backtrace: http://test.winehq.org/data/79f24b54c5f8f658dca8e4ceccd24c249ba091f8/wine_xp...
http://bugs.winehq.org/show_bug.cgi?id=12307
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified