[gm45] Xorg consistently crashing when using some applications

[Diego Schulz]

xserver-xorg-video-intel version: 2.8.0-0u
xserver-xorg-core version: 1.6.3-1u

X crashes when using some applications as Google Earth.

The crash is very easy to reproduce, as I noticed recently:
1. Open Kolourpaint (KDE drawing program), and select the pen tool.
2. Start drawing some doodle by pressing the left button of your mouse
   _without releasing it_ for at least 30 secs (keep the cursor moving).
3. X crashes.

here's a backtrace found in /var/log/kdm.log

---------------------------snip---------------------------
Backtrace:
0: /usr/bin/X(xorg_backtrace+0x3b) [0x8133d5b]
1: /usr/bin/X(xf86SigHandler+0x55) [0x80c7c15]
2: [0xa10400]
3: /usr/lib/xorg/modules//libfb.so(fbBresSolid+0x18e) [0x4fd33e]
4: /usr/lib/xorg/modules//libfb.so(fbSegment+0x1e7) [0x4fc637]
5: /usr/lib/xorg/modules//libfb.so(fbZeroLine+0x13c) [0x4f930c]
6: /usr/lib/xorg/modules//libfb.so(fbPolyLine+0x72) [0x4f8ff2]
7: /usr/lib/xorg/modules/drivers//intel_drv.so(uxa_check_poly_lines+0x125) [0x3a3ee5]
8: /usr/lib/xorg/modules/drivers//intel_drv.so [0x39cf0b]
9: /usr/bin/X [0x8180a28]
10: /usr/bin/X(ProcPolyLine+0x10b) [0x808ab9b]
11: /usr/bin/X(Dispatch+0x347) [0x808d027]
12: /usr/bin/X(main+0x395) [0x8072465]
13: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x554b56]
14: /usr/bin/X [0x8071911]
Saw signal 11. Server aborting.
Dropping master
 ddxSigGiveUp: Closing log
 ddxSigGiveUp: re-raising 11
---------------------------snip---------------------------

There's no other symptom or indication found in log files.
No file created in /var/crash/.

[lspci]
          bus info: pci@0000:00:00.0
             description: VGA compatible controller

[Diego Schulz (dschulzg)]

May be related to

[i965gm] X server crash at closing session if kdm is in use. [UXA bug]
https://bugs.launchpad.net/bugs/371500

[Bryce Harrington (bryce)]

Hi dschulz-gmail,

Thanks for including the attached files. Could you also include your /var/log/Xorg.0.log (or Xorg.0.log.old) from after reproducing the issue?

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Diego Schulz (dschulzg)]

Sure, here it is.

[Diego Schulz (dschulzg)]

Here's the normal Xorg.0.log

[Martin (agima)]

This affects me too when starting some simple 2D fullscreen games with wine, but using the radeon driver. Shall I open a separate bug report or attach my Xorg.log here, too? (It says ddxSigGiveUp: Closing Log at last)

[Luka Renko (lure)]

I can reproduce this on my ThinkPad X200s with exact instructions from Diego. I get the same backtrace in /var/log/kdm.log and I have also noticed the following oops in my /var/log/messages file:

Sep 10 00:18:23 lure kernel: [ 4629.464505] Pid: 3093, comm: Xorg Tainted: G C 2.6.31-10-generic #30-Ubuntu 74705HG
Sep 10 00:18:23 lure kernel: [ 4629.464505] RIP: 0010:[<ffffffffa002e5f3>] [<ffffffffa002e5f3>] drm_ht_remove_item+0x13/0x40 [drm]
Sep 10 00:18:23 lure kernel: [ 4629.464505] RSP: 0018:ffff88012fd45ac8 EFLAGS: 00010246
Sep 10 00:18:23 lure kernel: [ 4629.464505] RAX: ffffc90005105bf8 RBX: ffff88011bd8ed80 RCX: ffff88011bd89f10
Sep 10 00:18:23 lure kernel: [ 4629.464505] RDX: 0000000000000000 RSI: ffff88011bd8eda8 RDI: ffff880134d5b3f8
Sep 10 00:18:23 lure kernel: [ 4629.464505] RBP: ffff88012fd45ac8 R08: 0000000000000000 R09: 0000000000000000
Sep 10 00:18:23 lure kernel: [ 4629.464505] R10: 6db6db6db6db6db7 R11: 0000000000000000 R12: ffff88011bd8ef00
Sep 10 00:18:23 lure kernel: [ 4629.464505] R13: ffff88011bd8ef00 R14: 0000000000001000 R15: 0000000000000001
Sep 10 00:18:23 lure kernel: [ 4629.464505] FS: 00007f36028976f0(0000) GS:ffff880028040000(0000) knlGS:0000000000000000
Sep 10 00:18:23 lure kernel: [ 4629.464505] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Sep 10 00:18:23 lure kernel: [ 4629.464505] CR2: ffffc90005105bf8 CR3: 000000011b5a6000 CR4: 00000000000006a0
Sep 10 00:18:23 lure kernel: [ 4629.464505] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Sep 10 00:18:23 lure kernel: [ 4629.464505] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Sep 10 00:18:23 lure kernel: [ 4629.464505] Process Xorg (pid: 3093, threadinfo ffff88012fd44000, task ffff8801360c96b0)
Sep 10 00:18:23 lure kernel: [ 4629.464505] ffff88012fd45af8 ffffffffa0061b46 ffff88012fd45ae8 ffff88013480a800
Sep 10 00:18:23 lure kernel: [ 4629.464505] <0> ffff88011bd8ed80 0000000000000534 ffff88012fd45b18 ffffffffa0027d0b
Sep 10 00:18:23 lure kernel: [ 4629.464505] <0> ffff88011bd8ed80 ffffffffa0027ce0 ffff88012fd45b38 ffffffff81270507
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffffa0061b46>] i915_gem_free_object+0x76/0xe0 [i915]
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffffa0027d0b>] drm_gem_object_free+0x2b/0x60 [drm]
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffffa0027ce0>] ? drm_gem_object_free+0x0/0x60 [drm]
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffff81270507>] kref_put+0x37/0x70
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffffa00280b0>] drm_gem_object_release_handle+0x30/0x40 [drm]
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffff8126dce9>] idr_for_each+0x89/0xe0
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffffa0028080>] ? drm_gem_object_release_handle+0x0/0x40 [drm]
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffff81521f59>] ? mutex_lock+0x19/0x50
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffffa0027d75>] drm_gem_release+0x35/0x50 [drm]
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffffa002743b>] drm_release+0x33b/0x3d0 [drm]
Sep 10 00:18:23 lure kernel: [ 4629.464505] [<ffffffff8111b6e0>] __fput+0xf0/0x210
Sep 10 00:18:23 lure k...

[Luka Renko (lure)]

Created an attachment (id=29995)
Xorg.0.log with backrace

HW: ThinkPad X200s with gm45
SW: Kubuntu Karmic up-to-date + update mesa & intel 2.9.0 driver from x-updates PPA

I would like to report reproducible crash from Ubuntu bug 415357 (there is similar crash in bug 416421, but w/o reproduction instructions):
https://launchpad.net/bugs/415357
https://launchpad.net/bugs/416421

Bug is reproducible by performing the following steps:
1. Open Kolourpaint (KDE drawing program), and select the pen tool.
2. Start drawing some doodle by pressing the left button of your mouse
   _without releasing it_ for at least 30 secs (keep the cursor moving).
3. X crashes.

In Xorg.0.log, I get the following backtrace:

0: /usr/bin/X(xorg_backtrace+0x26) [0x4f0136]
1: /usr/bin/X(xf86SigHandler+0x41) [0x4850f1]
2: /lib/libc.so.6 [0x7ffcbef32530]
3: /usr/lib/xorg/modules//libfb.so(fbBresSolid+0x1d6) [0x7ffcbcced336]
4: /usr/lib/xorg/modules//libfb.so(fbSegment+0x282) [0x7ffcbccec4d2]
5: /usr/lib/xorg/modules//libfb.so(fbZeroLine+0xfd) [0x7ffcbcce90ad]
6: /usr/lib/xorg/modules/drivers//intel_drv.so(uxa_check_poly_lines+0x138) [0x7ffcbd775f38]
7: /usr/bin/X [0x539947]
8: /usr/bin/X(ProcPolyLine+0xe2) [0x44be82]
9: /usr/bin/X(Dispatch+0x384) [0x44e044]
10: /usr/bin/X(main+0x3b5) [0x433fa5]
11: /lib/libc.so.6(__libc_start_main+0xfd) [0x7ffcbef1dabd]
12: /usr/bin/X [0x433429]
Saw signal 11. Server aborting.

[Luka Renko (lure)]

This bug is still easily reproducible with up-to-date Karmic and also latest intel 2.9.0 driver from x-updates PPA. I have therefore opened upstream bug report.

Also, bug 416421 has similar backtrace, therefore it may be related.

[Chris Wilson (ickle)]

Created an attachment (id=30003)
Exercise fbBresSolid()

The attached code exercises the call stack from the reported backtrace, but is insufficient to reproduce the crash here.

Luka, do you mind trying the test case (with gcc large-poly-lines.c -lX11 && ./a.out) and seeing if it reproduces the crash on your machine?

[Chris Wilson (ickle)]

Ok, I can reproduce the crash here by wiggling kolourpaint...

[Chris Wilson (ickle)]

Created an attachment (id=30004)
Assert that the read/write pointer is within bounds

A simple assertion to check that the pointer we are about to read from and write is valid (i.e points to within the destination drawable).

[Chris Wilson (ickle)]

X: fbseg.c:92: fbBresSolid: Assertion `dst >= start && dst < end' failed.

As the assertion above is being hit is not specific to the intel driver, I'm reassigning the bug to the core server.

[Erki Hallingu (erkiha)]

Hi, I have same symptoms with intel gm4500. I get ddxSigSiveUp and X does not start.

It broke after yesterday's (2009/11/29) updates. In Lucid.

ubuntu@ubuntu:~$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

[Erki Hallingu (erkiha)]

My preivious report was false, please disregard. I resolved it by removing all X related dot files in my home folder.

I still get ddxSigGiveUp message when closing X but I do not know what it refers to, everything works.

[Paulo Zanoni (pzanoni)]

I can reproduce this problem on both 1.6.5 and 1.7.4. I didn't have time to test on git master yet.
I also tried Chris Wilson's patch on 1.6.5 and then instead of giving a backtrace X dies with this message:
X: fbseg.c:92: fbBresSolid: Assertion `dst >= start && dst < end' failed.

Link to Mandriva bug report:
https://qa.mandriva.com/show_bug.cgi?id=57105

[Bryce Harrington (bryce)]

[This is an automatic notification.]

Thanks for reporting this bug to help making the Intel graphics driver
better. We hear from upstream that a number of bugs (possibly including
this one) have been fixed in the newer DRM code from the 2.6.33 kernel.
I don't know if your bug is one of the ones fixed in this release,
though, but we've prepared a PPA with this DRM update. Would you mind
installing this, rebooting, and testing if the original issue can be
reproduced with it or not?

The DRM PPA is here:

    https://edge.launchpad.net/~apw/+archive/red

Note there could be new bugs... please file these as new reports using
the command 'ubuntu-bug linux' (for kernel or DRM or KMS bugs) or
'ubuntu-bug xorg' if you suspect them to be X.org issues.

[Luka Renko (lure)]

Still reproducible with kolourpaint on drm from .33. kdm.log trace:

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x4a25d8]
1: /usr/bin/X (0x400000+0x652dd) [0x4652dd]
2: /lib/libpthread.so.0 (0x7fe58b0cb000+0xf920) [0x7fe58b0da920]
3: /usr/lib/xorg/modules/libfb.so (fbBresSolid+0x1d6) [0x7fe587561bd6]
4: /usr/lib/xorg/modules/libfb.so (fbSegment+0x282) [0x7fe587560d72]
5: /usr/lib/xorg/modules/libfb.so (fbZeroLine+0xfd) [0x7fe58755d85d]
6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7fe587f86000+0x672a8) [0x7fe587fed2a8]
7: /usr/bin/X (0x400000+0xd8d77) [0x4d8d77]
8: /usr/bin/X (0x400000+0x2efff) [0x42efff]
9: /usr/bin/X (0x400000+0x30bac) [0x430bac]
10: /usr/bin/X (0x400000+0x2613a) [0x42613a]
11: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fe589dc4c4d]
12: /usr/bin/X (0x400000+0x25ce9) [0x425ce9]
Segmentation fault at address 0x7fe580f19ffc

Caught signal 11 (Segmentation fault). Server aborting

Please consult the The X.Org Foundation support
     at http://wiki.x.org
 for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

 ddxSigGiveUp: Closing log

[Chris Halse Rogers (raof)]

Moving to xorg-server. The upstream bug report has been moved to the server, as this is crashing in common Xserver code.

Although the upstream bug has not been marked as closed, can anyone reproduce on Xserver 1.9 (which is currently in Maverick)?

[Diego Schulz (dschulzg)]

I'm currently running Lucid in a Dell Latitude E6510 with Intel graphics, but using vesa driver and modesetting disabled (can't even boot in graphics mode with intel driver, I've got to use 'xforcevesa nomodeset' kernel parameters).

I'm going to try maverick ASAP and try to reproduce this bug (assuming the problem with modesetting is fixed and intel is usable at all).

[Bryce Harrington (bryce)]

As we haven't heard from anyone in several months, I'm closing the bug as expired (believed fixed).

If anyone can reproduce this on Natty, feel free to file a new bug, using apport or 'ubuntu-bug xorg'. Please also be sure to collect a new full backtrace - apport does this automatically some times, or see http://wiki.ubuntu.com/X/Backtracing for manual directions.

[Diego Schulz (dschulzg)]

I tried but was unable to reproduce this bug by the same means I described early in this thread.
I've not had any graphics issues using Maverick. I think this bug could be considered fixed since Ubuntu 10.10.

[Renato Caldas (seventhguardian)]

I cannot reproduce this with 1.9.5, and judging by the date of this bug I assume it can be closed, right?

[Simon Schubert (corecode)]

I experience a related bug when using KiCad:

[ 2507.868]
Backtrace:
[ 2507.868] 0: /usr/bin/X (xorg_backtrace+0x26) [0x566a86]
[ 2507.868] 1: /usr/bin/X (0x400000+0x16a6e9) [0x56a6e9]
[ 2507.868] 2: /lib/libpthread.so.0 (0x7fa9d12c8000+0xf8a0) [0x7fa9d12d78a0]
[ 2507.868] 3: /usr/lib/xorg/modules/libfb.so (fbBresSolid+0x21c) [0x7fa9cd94a1cc]
[ 2507.868] 4: /usr/lib/xorg/modules/libfb.so (fbSegment+0x3f7) [0x7fa9cd94b667]
[ 2507.868] 5: /usr/lib/xorg/modules/libfb.so (fbPolySegment32+0x4bd) [0x7fa9cd93f88d]
[ 2507.868] 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7fa9ce380000+0x380cc) [0x7fa9ce3b80cc]
[ 2507.868] 7: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7fa9ce380000+0x2f1ec) [0x7fa9ce3af1ec]
[ 2507.868] 8: /usr/bin/X (0x400000+0xf9a3f) [0x4f9a3f]
[ 2507.868] 9: /usr/bin/X (0x400000+0x302a3) [0x4302a3]
[ 2507.868] 10: /usr/bin/X (0x400000+0x33cb9) [0x433cb9]
[ 2507.868] 11: /usr/bin/X (0x400000+0x22eea) [0x422eea]
[ 2507.868] 12: /lib/libc.so.6 (__libc_start_main+0xed) [0x7fa9d017f38d]
[ 2507.868] 13: /usr/bin/X (0x400000+0x231dd) [0x4231dd]
[ 2507.868] Segmentation fault at address 0x7fa9cc816ffc

It is reproducible.

No idea why the intel driver symbols don't show up, but addr2line shows me:

0x380cc = xf86-video-intel-2.17.0/uxa/uxa-unaccel.c:24 = uxa_check_poly_segment()
0x2f1ec = xf86-video-intel-2.17.0/uxa/uxa-accel.c:624 = uxa_poly_segment()

[Simon Schubert (corecode)]

Created attachment 56113
gdb backtrace

gdb backtrace of the bug. dst is out of bounds. I can provide core file and binaries if required.

[Simon Schubert (corecode)]

The problem seems to be that there are negative coordinates being passed in to ProcPolySegment:

(gdb) p/x *(xSegment*)&((xPolySegmentReq *)0x2918e1c)[1]
$11 = {x1 = 0x24, y1 = 0x10, x2 = 0xfffe, y2 = 0xffff}

I don't know who is supposed to catch this. Looking at the call sequence, nobody really makes sure that these values are in bounds.

[Chris Wilson (ickle)]

Clipping is performed in fbSegment(), see OUTCODES() and miZeroClipLine().

[Simon Schubert (corecode)]

Ah. I believe this is the problem, or at least very closely related:

<http://cgit.freedesktop.org/xorg/xserver/tree/fb/fbseg.c#n693>:
     if (clip2 != 0 || drawLast)
  len++;

in combination with these variables:

        new_x1 = 36
        new_x2 = 0
        new_y1 = 16
        new_y2 = 0
        clip2 = 10
        len = 37

This incremented len to 37, extending (in reverse) the line below (0, 0), which leads to a segmentation fault.

[Simon Schubert (corecode)]

Ok, I see what is going on there.

The len++ is to make the end coordinates inclusive, which they should be if drawLast is set, or if we clipped the end.

Now, we changed the end coordinates, but we keep the Bresenham error terms, because we want the same angle (I suppose).

However, if we look at fbBresSolid, we see this sequence:

 while (len--)
 {
...
/// (1) ///
  WRITE(dst, FbDoMaskRRop (READ(dst), and, xor, bits));
  bits = 0;
  dst += signdx;
...
     e += e1;
/// (2) ///
     if (e >= 0)
     {
/// (3) ///
  WRITE(dst, FbDoMaskRRop (READ(dst), and, xor, bits));
  bits = 0;
  dst += dstStride;
  e += e3;
     }
 }

Now assume we have arrived at len = 1. We start the last iteration for the last pixel, at (x2,y2). We draw the pixel (location (1)), and we *should* be done. However, because of the previously unmodified Bresenham error terms, it can happen that the error total overflows (location (2)), and we will draw another pixel, now at (x2+signdx,y2), before adjusting the error terms and exiting the loop.

In short, it might happen that (I'm using signdx=-1, just because my case happens to be that way):

- (orig_x2, orig_y2) get clipped
- the algorithm then goes on to draw:

(x1,y1), (x1-1,y1), ..., (x2,y2), (x2-1,y2)

Now, if x2 = 0, y2 = 0, then we overshoot into negative address land (-1,0) and might segfault (actually do).

Solutions
=========

I don't directly see how this could be fixed:

a) Check dst for every Bresenham error pixel, but that seems excessive.
b) Adjust the error terms, but that would change the slope of the line (slightly)
c) Check for this case in advance and reduce len, but then you'd lose one pixel at the end
d) Rewrite fbseg to draw the error pixel in the next iteration, instead of in the same. This touches central code though.

[Simon Schubert (corecode)]

Just a follow-up to say that solution (d) seems to work for me.

[Simon Schubert (corecode)]

Created attachment 57155
reorder Bresenham error correction to avoid overshoot.

When fbBresSolid draws a line, it can happen that after the last
pixel, the Bresenham error term overflows, and fbBresSolid paints
another pixel before adjusting the error term.

However, if this happens on the last pixel (len=0), this extra pixel
might overshoot the boundary, and, in rare cases, lead to a segfault.

Fix this issue by adjusting for the Bresenham error term before
drawing the main pixel, not after.

[Mjd+freedesktop-org (mjd+freedesktop-org)]

I am getting this crash when doing zone fills in KiCad. Fedora 16, unaccelerated video. I have applied Simon Schubert's patch, and the crashes no longer happen.

[Mjd+freedesktop-org (mjd+freedesktop-org)]

Created attachment 59095
A backtrace of a crash caused by this problem

[Mattst88 (mattst88)]

Committed as http://cgit.freedesktop.org/xorg/xserver/commit/?id=863d528a9f76d0e8f122aebf19f8564a4c67a938

[Jeremy Sequoia (jeremyhu)]

This has caused a regression:
https://bugs.freedesktop.org/show_bug.cgi?id=54168

[Slapinid (slapinid)]

This bug still occurs with Kicad and recent X11

[Tormod Volden (tormodvolden)]

I am getting the same stack trace on Ubuntu 12.04.4 (Intel Arrandale IGP) when using kicad. This is also reported in Kicad, bug #911963.

[Ajax-a (ajax-a)]

commit 1b94fd77792310c80b0a2bcf4bf6d4e4c4c23bca
Author: Alex Orange <email address hidden>
Date: Fri Oct 3 15:41:38 2014 -0600

    fb: Fix Bresenham algorithms for commonly used small segments.