Xorg crashes when handed bad xrender glyph data

[Tel]

Binary package hint: xserver-xorg-air-core

Description: Ubuntu 9.04
Release: 9.04

xserver-xorg-core 2:1.6.0-0ubuntu14

Backtrace:
0: /usr/X11R6/bin/X(xorg_backtrace+0x3b) [0x813518b]
1: /usr/X11R6/bin/X(xf86SigHandler+0x55) [0x80c7be5]
2: [0xb7fe5400]
3: /usr/X11R6/bin/X [0x817c1c7]
4: /usr/X11R6/bin/X [0x8175125]
5: /usr/X11R6/bin/X(Dispatch+0x33f) [0x808d57f]
6: /usr/X11R6/bin/X(main+0x3bd) [0x80722ed]
7: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7bb2775]
8: /usr/X11R6/bin/X [0x80717a1]
Saw signal 11. Server aborting.
(II) AT Translated Set 2 keyboard: Close
(II) UnloadModule: "evdev"
(II) Video Bus: Close
(II) UnloadModule: "evdev"
(II) Macintosh mouse button emulation: Close
(II) UnloadModule: "evdev"
(II) UnloadModule: "synaptics"
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) intel(0): xf86UnbindGARTMemory: unbind key 0
 ddxSigGiveUp: Closing log

See attached C program...

[Tel (lists)]

Wants to link to wrong package...

[Tel (lists)]

/var/log/Xorg.0.log.old

[Tel (lists)]

Have tested this against two different Nvidia graphics cards on ununtu (running the non-free Nvidia drivers) and Nvidia drivers seem to be completely immune to the crash.

The crash did occur on a different machine also running "intel" driver and using "Mobile Intel® GM45 Express Chipset" so this is looking like something that depends on the particular graphics driver in use.
Suggestion that someone with the same intel chipset should be the first to debug this problem.

[Tel (lists)]

I have found that certain programs running under "wine" will trigger this crash. Recommended workaround to avoid the crash if you need to use some program that has problems... append to /etc/X11/xorg.conf

Section "Extensions"
Option "RENDER" "disable"
EndSection

[Timo Aaltonen (tjaalton)]

You need to get a proper backtrace, see https://wiki.ubuntu.com/X/Backtracing

[Tel (lists)]

Did you try running the attached progam?

[jajaX (jajaplanet)]

Hi ! (sorry for my bad english)

same problem with jaunty on KDE K.3 with my laptop ACER Aspire 5612WLMi

end of my Xorg.0.log.old :

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x3b) [0x813518b]
1: /usr/bin/X(xf86SigHandler+0x55) [0x80c7be5]
2: [0xb7f1c400]
3: /usr/lib/libpixman-1.so.0(pixman_image_composite+0x761) [0xb7e70f71]
4: /usr/lib/xorg/modules//libfb.so(fbComposite+0x1b2) [0xb768e632]
5: /usr/lib/xorg/modules//libexa.so(ExaCheckComposite+0x313) [0xb77732d3]
6: /usr/lib/xorg/modules//libexa.so(exaComposite+0x21e) [0xb77714ce]
7: /usr/bin/X [0x818030a]
8: /usr/bin/X(CompositePicture+0x19a) [0x817255a]
9: /usr/bin/X [0x8178405]
10: /usr/bin/X [0x8175125]
11: /usr/bin/X(Dispatch+0x33f) [0x808d57f]
12: /usr/bin/X(main+0x3bd) [0x80722ed]
13: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7ae0775]
14: /usr/bin/X [0x80717a1]
Saw signal 11. Server aborting.
(II) AT Translated Set 2 keyboard: Close
(II) UnloadModule: "evdev"
(II) Acer hotkey driver: Close
(II) UnloadModule: "evdev"
(II) Macintosh mouse button emulation: Close
(II) UnloadModule: "evdev"
(II) Video Bus: Close
(II) UnloadModule: "evdev"
(II) Logitech USB-PS/2 Optical Mouse: Close
(II) UnloadModule: "evdev"
(II) UnloadModule: "synaptics"
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) intel(0): xf86UnbindGARTMemory: unbind key 0
 ddxSigGiveUp: Closing log

[jajaX (jajaplanet)]

Hi ! (sorry again for my bad english)

other log :

kdm.log =>

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x3b) [0x813518b]
1: /usr/bin/X(xf86SigHandler+0x55) [0x80c7be5]
2: [0xb7f88400]
3: /usr/lib/libpixman-1.so.0(pixman_image_composite+0x761) [0xb7edcf71]
4: /usr/lib/xorg/modules//libfb.so(fbComposite+0x1b2) [0xb76fa632]
5: /usr/lib/xorg/modules//libexa.so(ExaCheckComposite+0x313) [0xb77df2d3]
6: /usr/lib/xorg/modules//libexa.so(exaComposite+0x21e) [0xb77dd4ce]
7: /usr/bin/X [0x818030a]
8: /usr/bin/X(CompositePicture+0x19a) [0x817255a]
9: /usr/bin/X [0x8178405]
10: /usr/bin/X [0x8175125]
11: /usr/bin/X(Dispatch+0x33f) [0x808d57f]
12: /usr/bin/X(main+0x3bd) [0x80722ed]
13: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b4c775]
14: /usr/bin/X [0x80717a1]
Saw signal 11. Server aborting.
 ddxSigGiveUp: Closing log
 ddxSigGiveUp: re-raising 11

X.Org X Server 1.6.0
Release Date: 2009-2-25
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-23-server i686 Ubuntu
Current Operating System: Linux assistinfo 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC 2009 i686
Build Date: 09 April 2009 02:10:02AM
xorg-server 2:1.6.0-0ubuntu14 (<email address hidden>)
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Aug 18 10:48:37 2009
(==) Using config file: "/etc/X11/xorg.conf"
(EE) Failed to load module "freetype" (module does not exist, 0)
get fences failed: -1
param: 6, val: 0
get fences failed: -1
param: 6, val: 0
expected keysym, got dead_currency: line 501 of fr
expected keysym, got dead_belowcomma: line 509 of fr
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
> Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
expected keysym, got dead_currency: line 501 of fr
expected keysym, got dead_belowcomma: line 509 of fr
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
> Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
expected keysym, got dead_currency: line 501 of fr
expected keysym, got dead_belowcomma: line 509 of fr
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
> Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server

kern.log =>

Aug 18 10:48:37 assistinfo kernel: [ 1485.879296] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
Aug 18 10:48:39 assistinfo kernel: [ 1487.970510] [drm:i915_setparam] *ERROR* unknown parameter 4
Aug 18 10:48:39 assistinfo kernel: [ 1487.970535] [drm:i915_getparam] *ERROR* Unknown parameter 6
Aug 18 10:48:40 assistinfo kernel: [ 1489.147528] [drm:i915_getparam] *ERROR* Unknown parameter 6
Aug 18 10:55:12 assistinfo kernel: [ 18...

[jajaX (jajaplanet)]

syslog :

Aug 18 10:48:37 assistinfo kernel: [ 1485.879296] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
Aug 18 10:48:37 assistinfo kdm[3319]: X server for display :0 terminated unexpectedly
Aug 18 10:48:37 assistinfo acpid: client 3341[0:0] has disconnected
Aug 18 10:48:37 assistinfo acpid: client connected from 6643[0:0]
Aug 18 10:48:39 assistinfo kernel: [ 1487.970510] [drm:i915_setparam] *ERROR* unknown parameter 4
Aug 18 10:48:39 assistinfo kernel: [ 1487.970535] [drm:i915_getparam] *ERROR* Unknown parameter 6
Aug 18 10:48:40 assistinfo kernel: [ 1489.147528] [drm:i915_getparam] *ERROR* Unknown parameter 6
Aug 18 10:48:41 assistinfo kdm_greet[6658]: Cannot load /usr/share/kde4/apps/kdm/faces/.default.face: Aucun fichier ou dossier de ce type
Aug 18 10:55:12 assistinfo kernel: [ 1881.245947] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0

[jajaX (jajaplanet)]

because I have got this bug too on my laptop too

[Bryce Harrington (bryce)]

We still need a full backtrace on this issue - please see http://wiki.ubuntu.com/X/Backtracing for details.

[Tel (lists)]

This patch protects against "xrender_bug.c" program from above (see attached patch).
At least the desktop remains stable. I still can't run my application under "wine", but the patched X gives these errors:

X Error of failed request: BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request: 149 (RENDER)
  Minor opcode of failed request: 20 (RenderAddGlyphs)
  Serial number of failed request: 90044
  Current serial number in output stream: 90053

Probably a step in the right direction, guess there is something wrong with wine font rendering (oh really? how shocking).

[Tel (lists)]

For what it's worth, I found this wine bug:
    http://bugs.winehq.org/show_bug.cgi?id=17338

My wine application is giving very similar results, when I set:
   WINEDEBUG=+xrender,+synchronous

I get this bit of trace:

trace:xrender:LookupEntry found font in cache 0
trace:xrender:X11DRV_XRender_UpdateDrawable freeing pict = 1a008cc dc = 0x1d0
trace:xrender:X11DRV_XRender_SelectFont h=16 w=7 weight=400 it=0 charset=0 name=L"System"
trace:xrender:dec_ref_cache dec'ing entry 0 to 22
trace:xrender:LookupEntry 0
trace:xrender:LookupEntry found font in cache 0
trace:xrender:X11DRV_XRender_SelectFont h=16 w=7 weight=400 it=0 charset=0 name=L"System"
trace:xrender:dec_ref_cache dec'ing entry 0 to 22
trace:xrender:LookupEntry 0
trace:xrender:LookupEntry found font in cache 0
trace:xrender:X11DRV_XRender_SelectFont h=-11 w=65580 weight=100 it=64 charset=12 name=L"MS Sans Serif"
trace:xrender:dec_ref_cache dec'ing entry 0 to 22
trace:xrender:LookupEntry 0
trace:xrender:LookupEntry 4
trace:xrender:LookupEntry 1
trace:xrender:LookupEntry 9
trace:xrender:LookupEntry 3
trace:xrender:LookupEntry 2
trace:xrender:LookupEntry 5
trace:xrender:LookupEntry 8
trace:xrender:LookupEntry 6
trace:xrender:LookupEntry 7
trace:xrender:LookupEntry font not in cache
trace:xrender:AllocEntry freeing unused glyphset at cache 7
trace:xrender:X11DRV_XRender_ExtTextOut bitmap is not a DIB
trace:xrender:X11DRV_XRender_ExtTextOut bitmap is not a DIB
trace:xrender:X11DRV_XRender_ExtTextOut bitmap is not a DIB
trace:xrender:X11DRV_XRender_SelectFont h=-11 w=65580 weight=100 it=64 charset=12 name=L"MS Sans Serif"
trace:xrender:dec_ref_cache dec'ing entry 7 to 0
trace:xrender:LookupEntry 7
trace:xrender:LookupEntry found font in cache 7
trace:xrender:X11DRV_XRender_ExtTextOut bitmap is not a DIB
trace:xrender:X11DRV_XRender_ExtTextOut allocing pict = 1a008ce dc = 0x1d0 drawable = 01e00006
trace:xrender:UploadGlyph buflen = 1023100. Got metrics: 78700x13 adv=13160,0 origin=-1,11
*** buffer overflow detected ***

After that things go south very rapidly. Obviously width 65580 is ridiculous, looks like a 16 bit signed/unsigned mismatch with a negative number slipping through some calculation.

Based on the wine version, supposedly it is fixed in 1.1.21 so will try the dist upgrade to Karmic... what's the worst that could happen?

[Tel (lists)]

A brief update...

Upgrading to Karmic does *NOT* fix the X11 xrender crash. Same program "xrender_bug.c" will demonstrate the crash, same patch from above will block the NULL pointer. Tested against:

xserver-xorg-core 2:1.6.3-1ubuntu4

My problems with wine also remain after the upgrade to Karmic. Wine version 1.0.1 has the font size bug, but the wine1.2 (version 1.1.27) has other problems that kill my application so what I really need is a bit of each. Details of this wine problem no doubt belong in some other bug, once I have a bit more info.

[Kruvalig (kruvalig)]

Created an attachment (id=23514)
log of the command 'wine imap_september_2009.exe'

I install program imap_september_2009.exe. This is a GIS of my town. And this is a programm on russian language. It hase wisard to install. And seems that programm installed normal. But i can't start it.

When i start it with command wine iMap.exe i see error: 'Error initialisation when call file jet VBAjET.dll for 16 bit version.... error 3447. Whould you like to see hel?' i press no. Then i see window that i can see in windowsxp. This window is a window of loading this program. On this window i press NEXT, and then i see dialog of error.

i use wine under Fedora 11.

http://imap58.ru/download/ - this is link on page with this program.
http://imap58.ru/dl/0 - this is link on file with this program.

[Arethusa26 (arethusa26)]

Does using winetricks (http://wiki.winehq.org/winetricks) to install jet40 allow the application to work?

[Vitaliy-bugzilla (vitaliy-bugzilla)]

Please upgrade Wine to latest version - wine-1.1.29 and retest.

[Kruvalig (kruvalig)]

i upgrade under fedora 11 to wine 1.1.29 from test repo. And no, programm is not work.

i install jet40 with help http://wiki.winehq.org/winetricks
and i can say

1. I start program.
2. I see splash window and i press Next on this window. (Now i don't see error VBAjET.dll)
3. Gnome fail. I see black screen. And it restart. I see login page for my Fedora 11. I login. And see error message from wine.

My smolt page: http://www.smolts.org/show?uuid=pub_42e806b0-bed4-439a-b7c0-9924d5a22624

[Kruvalig (kruvalig)]

I try to start iMap under VirtualBox Fedora 11 wine.

and it start (with some graphics bug), but when i scale map it crash

1. start application http://my.jetscreenshot.com/1107/20090909-rngv-282kb.jpg
2. Zoom in map http://my.jetscreenshot.com/1107/20090909-dcgp-234kb.jpg
3. log of start script crash
[qet@localhost iMap]$ wine iMap.exe
X Error of failed request: BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request: 148 (RENDER)
  Minor opcode of failed request: 20 (RenderAddGlyphs)
  Serial number of failed request: 54322
  Current serial number in output stream: 54513

This is a normal screenshot under windowsxp
http://my.jetscreenshot.com/1107/20090909-kpy2-264kb.jpg

[Vitaliy-bugzilla (vitaliy-bugzilla)]

(In reply to comment #3)
> 3. Gnome fail. I see black screen. And it restart. I see login page for my
> Fedora 11. I login. And see error message from wine.
Most likely bad video drivers. Wine is a user app and by definition can not crash X server.

Invalid.

[Vitaliy-bugzilla (vitaliy-bugzilla)]

Closing.

[Tel (lists)]

I would like this to be re-opened.

The is a real bug in wine: it sends invalid xrender glyph data to the X11 server and for some (but not all) video drivers this crashes the X server. This also indicates a bug in the X server (the existence of one bug does not deny the existence of others). I can tell you about the X11 bug, it is a failure to check the NULL pointer in the file render.c and the function ProcRenderAddGlyphs() and a patch is available here --

https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/408016

That said, I have no idea where the wine bug might be lurking other than that it is something to do with client-side font handling and the xrender extension. If you disable xrender in the X11 config or if you recompile wine with client side fonts disabled then the bug goes away (although many programs run into other different problems with this particular feature disabled).

[Tel (lists)]

Out on a limb, but the info might help someone :-(

I've been tinkering with CentOS v5.4 and compiling wine-1.1.29-fe.tar.bz2 to run my EXE program. I've run up against similar problems (same hardware as above). Versions are:

xorg-x11-drv-i810-1.6.5-9.25.el5
xorg-x11-server-Xorg-1.1.1-48.67.el5

Just for reference the RedHat package for i810 contains both of the drivers:

/usr/lib/xorg/modules/drivers/i810_drv.so
/usr/lib/xorg/modules/drivers/intel_drv.so

and I'm using the "intel" driver, although the i810 driver also works on the same hardware.

X does NOT crash for me in this configuration, but neither will wine actually run, I merely get the error message:

X Error of failed request: BadLength (poly request too large or internal Xlib length error)
  Major opcode of failed request: 155 (RENDER)
  Minor opcode of failed request: 20 (RenderAddGlyphs)
  Serial number of failed request: 76507
  Current serial number in output stream: 76512

If you check upstream ...

    http://cgit.freedesktop.org/xorg/xserver/tree/render/render.c

... you can see there is no NULL pointer check on pDstPix around line 1160 so I can't explain why the RedHat version does not crash in the same place, don't have time to go through it with a fine tooth comb. Still waiting for some patch that will prevent wine from delivering the bad glyph data in the first place. Here is an old bug report from 2003 were similar problems were evident (and no fix found back then either).

    http://<email address hidden>/msg06098.html

Some Russian guy is coming up with almost exactly the same error using Kubuntu 9.10 + Wine 1.1.34

   http://linuxforum.ru/index.php?s=ded24b144d5aca3620acdab78ec69455&showtopic=106168&pid=990715&st=0&#entry990715

Another wine bug (this time from only a few month ago, from a Russian using fedora 11 and wine 1.1.29)

   http://bugs.winehq.org/show_bug.cgi?id=19986

I just have to quote the resolution of wine bug 19986: "Most likely bad video drivers. Wine is a user app and by definition can not crash X server. Invalid."

As they say, "you can learn a lot, just by looking" but Oh Boy! It is so difficult to get people to look. Maybe someone can have a good laugh out of all this. I'm off to have a cry now. Does launchpad offer a tissuebox feature? Probably it should...

[Dmitry-codeweavers (dmitry-codeweavers)]

(In reply to comment #7)
> The is a real bug in wine: it sends invalid xrender glyph data to the X11
> server and for some (but not all) video drivers this crashes the X server.

A user application should not be able to crash X server regardless what
data it sends to it.

[Tel (lists)]

Hopefully someone who reads this might be interested in fixing bugs rather than ignoring the problem, the following could be useful:

   export WINEDEBUG=+font,+xrender,+xrandr,+synchronous

In the trace you get:

   trace:xrender:UploadGlyph buflen = 127920. Got metrics: 78715x13 adv=13175,0 origin=-1,11
   err:seh:setup_exception_record stack overflow 940 bytes in thread 0009 eip 7bc39bcf esp 00240f84 stack 0x240000-0x241000-0x340000

Note that the font metric is clearly WRONG (no possible font could be 78000 pixels wide) and the buflen is much larger than expected (typical buflen values in UploadGlyph are less than 100 bytes). This shows errors in the font metric calculation.

Anyone having similar problems should trace with similar WINEDEBUG and search for the UploadGlyph line with the broken metric values. If you have similar problems please post to this bug, maybe get it opened again.

As a bit of additional info, I see lines like this in the trace:

   trace:font:WineEngGetGlyphOutline 4,8,(0,8),5,0

Almost always these are small numbers, but right before the bug hits I see larger numbers like so:

   trace:xrender:get_xrender_format Returning wxr_format=0
   trace:font:GetGlyphOutlineW (0x1d0, 0056, 0081, 0x33e338, 127920, 0x1fea40, 0x73632ab6)
   trace:font:WineEngGetGlyphOutline 0x1a0dc0, 0056, 00000081, 0x33e338, 0001f3b0, 0x1fea40, 0x73632ab6
   trace:font:WineEngGetGlyphOutline font transform 1.000000 0.000000 0.000000 1.000000
   trace:font:WineEngGetGlyphOutline Vec 0,704
   trace:font:WineEngGetGlyphOutline Vec 0,-128
   trace:font:WineEngGetGlyphOutline Vec 384,704
   trace:font:WineEngGetGlyphOutline Vec 384,-128
   trace:font:WineEngGetGlyphOutline transformed box: (-64,704 - 5037696,-128)
   trace:font:WineEngGetGlyphOutline 78715,13,(-1,11),13175,0

This is the only place I see the "Vec" lines and also the only place I see large numbers in the WineEngGetGlyphOutline result so that might be something to look for.

[Tel (lists)]

This also looks like part of the broken calculation:

trace:font:GetTextMetricsW text metrics:
    Weight = 400 FirstChar = 32 AveCharWidth = 65592
    Italic = 0 LastChar = 255 MaxCharWidth = 144302
    UnderLined = 255 DefaultChar = 129 Overhang = 0
    StruckOut = 255 BreakChar = 32 CharSet = 0
    PitchAndFamily = 21
    --------------------
    InternalLeading = 2
    Ascent = 11
    Descent = 2
    Height = 13

Normally AveCharWidth will be a small number, in various places it is a large number but whenever it is large the number is always 65592 and that does not make a plausible font width.

2^16 + 64 - 8 = 65592

Looks a lot like a 16 bit integer calculation gone wrong ?

[Tel (lists)]

I've studied a bit more and think that the application itself is generating this strange wide font value. Wine takes the unreasonable values and makes an attempt to do what it is asked, the buck gets passed into X11DRV_SelectFont() and then ultimately pushes disaster onto the X11 drivers. Layer upon layer without sanity checking.

    warn:font:CreateFontIndirectW orientation angle 208225028.600000 set to escapement angle 134086.000000 for new font 0x1a0d48
    trace:font:CreateFontIndirectW (-11 65592 1340860 2082250286 0 244 df 51 0) L"MS Sans Serif" Italic Underline => 0x1ac0

lfHeight = -11
lfWidth = 65592
lfEscapement = 1340860
lfOrientation = 2082250286
lfPitchAndFamily = 0x0
lfOutPrecision = 244
lfClipPrecision = 0xdf
lfQuality = 51
lfCharSet = 0

These values are completely bogus, somehow Microsoft Win-XP can run this so I'll try inserting a bit of defensive code into CreateFontIndirectW to see if I can protect myself from crashes but in order to do the job properly wine should attempt to handle such problems in a similar manner to however Microsoft does it. I don't have tools to do detailed research unfortunately.

Highly likely this same event was also the cause of:

http://bugs.winehq.org/show_bug.cgi?id=17338

[Tel (lists)]

Made a tiny bit more progress, trying to get upstream wine bug re-opened but they want to fob the blame onto X11 and ignore their own problems, so chance of a quick solution is unlikely.

Summary of the wine problem as far as I can tell: badly behaved win32 exe programs will call CreateFontIndirect() with bogus parameters and somehow under real Microsoft Win-XP these programs actually work. Under wine the bogus parameters gumby up the font metric calculator, which in turn cranks the handle on the X11 drivers -- whole lot of code, not many error checks.

Getting X11 fixed might be a good step towards getting other buggy applications fixed, then they can stop trying to blame everything on the X server!

I'll be patching up my own version of wine but I hesitate to post any public patch because it is rather a delicate matter to deal with badly behaved exe programs in a way that maintains maximum Microsoft compatibility. Doing the job right requires excellent understanding of how the win32 fonts work and a bit of research into how Microsoft deal with the questionable cases.

I've gone about as far as I can go with this so I would appreciate someone pushing my NULL pointer check into the X server code and close off this bug. Thanks.

[Dmitry-codeweavers (dmitry-codeweavers)]

Have you tried with latest Wine version?

[Tel (lists)]

Trying with wine 1.1.35 gives similar bogus values in trace:

warn:font:CreateFontIndirectW orientation angle 208225028.600000 set to escapement angle 136615.600000 for new font 0x1e18a8
trace:font:CreateFontIndirectW (-11 131150 1366156 2082250286 0 36 df 51 12) L"MS Sans Serif" Italic Underline => 0x21d0

lfHeight = -11
lfWidth = 131150
lfEscapement = 1366156
lfOrientation = 2082250286
lfPitchAndFamily = 0x0
lfOutPrecision = 36
lfClipPrecision = 0xdf
lfQuality = 51
lfCharSet = 12

Strangely, not the same values as before and when I retry the program the numbers are similar but not consistent. Unfortunately this is a partly interactive program and it updates "workspace" files making it difficult to get a completely consistent result.

Good news that it does *NOT* crash out in wine 1.1.35 but that may be a fluke. There is some on-screen font corruption but only in window decoration... I can live with that. I am starting to think this application program is using uninitialized memory or something similar.

I tried going back to the version I was using before (1.1.29) and the crash came back, but the width is also back to 65592 under 1.1.29 so I cannot explain why the program gives different numbers under different wine versions (perhaps DLL changes effect the stack memory and the application does not clear the stack when it should). Comparing the wine source code for CreateFontIndirectW shows some changes between the two versions so maybe these are protecting the system somehow (but there is no obvious bounds-checking code so quite likely the protection is accidental).

I still suggest that their is a loophole in wine for badly behaved EXE programs to inject bogus parameters into CreateFontIndirectW() and generate outrageous glyph sizes in X11, and there is evidence that at least some existing Win-XP applications will behave in this manner.

However, my problem is solved for the time being, thanks for your interest.

I would be curious to know what the original poster could find with

  export WINEDEBUG=+xrender,+font,+synchronous

and checking closely lines containing CreateFontIndirect ...

[Dmitry-codeweavers (dmitry-codeweavers)]

That particular problem was probably fixed by
http://www.winehq.org/pipermail/wine-cvs/2009-October/060217.html

Still, an X11 crash is not a Wine bug.

[Bryce Harrington (bryce)]

Looks like this patch is included in the xorg-server we're shipping with natty, fixed by commit 77fcfd0e94c200ee383cf9d03383cde947eef6fd to xorg-server on Mar 29, 2011.