[SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

Ochi · 2010-10-06 02:15:01

Hi everyone,

I'm experiencing a perfectly reproducible (even with a completely fresh Arch install) Xorg segfault with a certain constellation.

When using the latest binary nvidia drivers (works with the 260 beta also), dragging the mouse pointer within a qt window (vlc, smplayer, skype, qtconfig) crashes Xorg with a segfault when using a Xinerama configuration. Twinview or single screen works fine however.

Xinerama configuration (crashing): http://pastebin.com/3VdVZqkU
Twinview configuration (works): http://pastebin.com/QjL4Nibg

Xorg log when crashing: http://pastebin.com/qby9uSxN

Can anyone confirm this?

Ochi

Last edited by Ochi (2010-11-15 14:40:33)

pielgrzym · 2010-10-06 06:51:07

Yup, Xorg never will be stable I just have to run skype to flip whole damn xorg server. Hate updating this ***t.:(

Azriel · 2010-10-06 15:06:56

I had the same problem that I reported here. In my case I didn't care much about using xinerama so I just kicked it out, but I can confirm this bug as far as i'm concerned.

Ochi · 2010-10-06 15:46:39

Yup, I'd just use Twinview as well, but I'm normally using three monitors on two nvidia cards so Twinview is not an option for me. And it's still a bug that should be taken care of anyway. ^^

kevin1024 · 2010-10-06 19:24:28

Confirmed. This has been driving me nuts for weeks. I have a 4 monitor setup.

This appears to be the same bug: https://bugs.launchpad.net/ubuntu/+sour … bug/650539
So does this: http://bugs.gentoo.org/show_bug.cgi?id=339135

The bug happens when Xinerama is enabled, a qt app is launched, and you move your mouse cursor over the qt app.

I can start kcalc and everything is fine until I move my cursor over the application, at which point Xorg segfaults.

Also, just for kicks, I tried this with the nouveau drivers instead of the nvidia binary blob, and had the same problem.

kevin1024 · 2010-10-06 20:27:45

I'm pretty sure this is a bug in qt, so let's direct our attention toward the qt bugtracker instead of these distro bugtrackers, since it's an upstream problem and they can't do anything about it. Here's the bug:

http://bugreports.qt.nokia.com/browse/QTBUG-14260

mlee · 2010-10-07 12:21:07

I also have the same problem. I have 3 screens that I run in xinerama (2 cards). I use the awesome window manager and run klipper and kmix. For me, running emacs causes X to immediately crash. I also couldn't run kdm as it would fall in to an endless loop of crashes/restarts.

I have since downgraded to xorg 1.8 until the problem is resolved.

Ochi · 2010-10-10 03:14:12

Just for the fun of it, I was digging around some more and compiled a debug version of Xorg 1.9.0 on a testing Arch and stuff. gdb told me that the crash happens at

panoramiXprocs.c:637

So I looked at the sauce and.. well, actually I had to beautify it a bit first, manually, then I looked at it and thought I'd really like to hear your opinion on the function

int PanoramiXTranslateCoords(ClientPtr client)

where the crash happens. The slightly beautified code is available at http://pastebin.org/87390. For some reason (maybe someone can enlighten me) the expression

(pDst == screenInfo.screens[0]->root)

in line 58 seems to be false just in the case of the pointer wandering about QT windows (oh btw, it seems like starting the qt3 config tool crashes even without the pointer being on the window). Anyways, in case that this first expression is false, this expression is evaluated

(pWin->drawable.id == screenInfo.screens[0]->screensaver.wid)

But hey, wait a tick... wasn't there a while-loop just before that if which made sure that pWin is 0 (lines 29ff)? Take a close look and tell me what you think. ^^

Last edited by Ochi (2010-10-10 03:16:54)

benvd · 2010-10-10 09:22:20

Same problem here. Xorg also crashes when I open gitk, which as far as I know uses tcl/tk, and not qt...

kevin1024 · 2010-10-11 18:52:05

benvd wrote:

Xorg also crashes when I open gitk

gitk doesn't crash for me. 4-monitor setup with xorg 1.9 / nvidia binary / xinerama.

Ochi wrote:

Just for the fun of it, I was digging around some more

Great work! So it looks like the bug could be in xorg itself? Perhaps we should open a bug there instead.

securitybreach · 2010-10-11 19:08:28

Well I am glad I am not the only one experiencing crashes with Xorg, Nvidia, and QT applications. I am also running two nvidia cards with 3 monitors using XInerama.

listdata · 2010-10-12 18:58:30

Confirmed. I'm using 2 monitors with Xmonad and I have the same Xorg segfaults with QT apps. Sort of annoying, since both SMplayer and VLC use QT.

benvd wrote:

Same problem here. Xorg also crashes when I open gitk, which as far as I know uses tcl/tk, and not qt...

gitk works perfectly fine for me. I don't think that's related to this problem.

Ochi wrote:

But hey, wait a tick... wasn't there a while-loop just before that if which made sure that pWin is 0 (lines 29ff)? Take a close look and tell me what you think. ^^

Yes, it looks like the while loop at line 29 will run forever until pWin is NULL (line 49), so that by the time the if-statement is executed, the pWin->drawable.id would be trying to dereference a NULL pointer. Of course, I could be wrong, since I have never touched any X source code before.

I suggest you apply a patch to change that if-statement --- maybe even trying just deleting that second OR condition entirely. I'll try to make a patch myself and get around to this later this weekend if I can.

mir · 2010-10-12 21:38:26

So, it looks like a bug in Xorg, not nvidia?

Ochi · 2010-10-12 21:51:57

Unfortunately, I don't have the time to really play around with this at the moment since I'm preparing a seminar. But feel free to use the info in my former post as you wish. I didn't touch any Xorg code yet either, I don't know what else would break if I'd just change the code there. ^^

@mir: My guess is that Xorg is at least not totally innocent. Even if for instance qt does something awkward to the x server (I still don't know why it happens only(?) with qt apps), X should handle this more gracefully.

wor · 2010-10-15 15:30:12

ok I patched that bit of code and now I can run Qt applications again and Emacs ( !!! ).

DISCLAIMER: I have little clue about what this code does, why or when. I just patched to keep the general logic of the code intact - making guesswork about the intent of the author when he cut&pasted that piece of code. This could cause glitches esp. with screensavers. Also, i686 untested.

to test it proper, you will need to download a tarball from contrib svn repo (i686: http://repos.archlinux.org/wsvn/package … xtra-i686/ ; x86_64 http://repos.archlinux.org/wsvn/package … ra-x86_64/ ), edit the PKGBUILD and add my patch to the list. patch line should be "patch -Np1 -i "${srcdir}/0001-guesswork.patch". I'm attaching a PKGBUILD that comes from xorg-server x86_64 tree.

PATCH: http://pastebin.org/208910
PKGBUILD : http://pastebin.org/208909

PS: I don't know if this have been reported upstream or is beeing tracked at all somewhere.

Last edited by wor (2010-10-15 15:37:32)

listdata · 2010-10-15 17:42:21

wor wrote:

PS: I don't know if this have been reported upstream or is beeing tracked at all somewhere.

The Ubuntu folks are on it as well https://bugs.launchpad.net/ubuntu/+sour … bug/650539 (they've linked back to our discussion, too), but I don't think it has been reported upstream (bugs.freedesktop.org) yet. This issue probably affects less than 30 people on Earth right now.

Last edited by listdata (2010-10-15 17:43:45)

listdata · 2010-10-15 18:45:04

wor wrote:

ok I patched that bit of code and now I can run Qt applications again and Emacs ( !!! ).
DISCLAIMER: I have little clue about what this code does, why or when. I just patched to keep the general logic of the code intact - making guesswork about the intent of the author when he cut&pasted that piece of code. This could cause glitches esp. with screensavers.

I see that you just replaced the pWin pointer with pDst. I think your guesswork strategy is a lot better than my suggestion of deleting out the OR condition entirely.

wor wrote:

I'm attaching a PKGBUILD that comes from xorg-server x86_64 tree.
PATCH: http://pastebin.org/208910
PKGBUILD : http://pastebin.org/208909

The PKGBUILD from there fails because of a CRLF error --- strange.

Anyway, I followed your instructions and built the package. Doing

makepkg -s

resulted in the following packages:

xorg-server-1.9.0-1-x86_64.pkg.tar.xz
xorg-server-1.9.0.tar.bz2
xorg-server-common-1.9.0-1-x86_64.pkg.tar.xz
xorg-server-devel-1.9.0-1-x86_64.pkg.tar.xz
xorg-server-xdmx-1.9.0-1-x86_64.pkg.tar.xz
xorg-server-xephyr-1.9.0-1-x86_64.pkg.tar.xz
xorg-server-xnest-1.9.0-1-x86_64.pkg.tar.xz
xorg-server-xvfb-1.9.0-1-x86_64.pkg.tar.xz

After upgrading to these package, it all works very well now! VLC, SMplayer, etc. work very fine for me now.

listdata wrote:

benvd wrote:
Same problem here. Xorg also crashes when I open gitk, which as far as I know uses tcl/tk, and not qt...
gitk works perfectly fine for me. I don't think that's related to this problem.

Actually benvd, I take that back. I just remembered that fontforge also segfaulted X on me just like all the other QT apps (only difference was that fontforge crashed X when I moved my mouse cursor to the intro screen, whereas QT apps all crashed after starting up). And fontforge uses tcl/tk IIRC.

So now, fontforge works as well.

Last edited by listdata (2010-10-15 18:49:34)

jimduchek · 2010-10-15 18:45:24

This is killing VirtualBox and Blender for me, which... well, it sucks. Trying wor's PKGBUILD.

jimduchek · 2010-10-15 19:10:16

Yes, this patch allows me to run VirtualBox and Blender without crashing... so kudos, wor. Hopefully this gets upstream soon.

listdata · 2010-10-15 19:33:44

Just to do some more analysis on this, I tried to compare the sources between the old working xorg-server that Arch packaged (version 1.8.1.902, found at http://www.x.org/releases/individual/xserver/ and the latest 1.9 xorg release that Arch uses (version 1.9.0, found at the same aforementioned URL).

In version 1.8.1.902, the file Xext/panoramiXprocs.c has this version of the critical if-statement that Ochi originally mentioned:

    if((pDst == WindowTable[0]) || 
       (pDst->drawable.id == savedScreenInfo[0].wid))
    {
    rep.dstX += panoramiXdataPtr[0].x;
    rep.dstY += panoramiXdataPtr[0].y;
    }

Anyway, I got the git repo to see which commit decided to change pDst to pWin in that second OR condition.

git clone git://anongit.freedesktop.org/xorg/xserver
git log -p Xext/panoramiXprocs.c

And found this commit: 80b5d3a3264d2c5167e5ac85a3b04af0f89cece1 which did the change. You can use

git show 80b5d3a3264d2c5167e5ac85a3b04af0f89cece1

to see the commit's full diff. That commit was a big commit that changed lots of things in many files. Here is the portion that concerns our discussion (see the very bottom part)):

diff --git a/Xext/panoramiXprocs.c b/Xext/panoramiXprocs.c
index 8752ca5..08ea3ec 100644
--- a/Xext/panoramiXprocs.c
+++ b/Xext/panoramiXprocs.c
@@ -130,7 +130,7 @@ int PanoramiXCreateWindow(ClientPtr client)
     orig_x = stuff->x;
     orig_y = stuff->y;
     parentIsRoot = (stuff->parent == WindowTable[0]->drawable.id) ||
-                   (stuff->parent == savedScreenInfo[0].wid);
+                   (stuff->parent == screenInfo.screens[0]->screensaver.wid);
     FOR_NSCREENS_BACKWARD(j) {
         stuff->wid = newWin->info[j].id;
         stuff->parent = parent->info[j].id;
@@ -329,7 +329,7 @@ int PanoramiXReparentWindow(ClientPtr client)
     x = stuff->x;
     y = stuff->y;
     parentIsRoot = (stuff->parent == WindowTable[0]->drawable.id) ||
-                   (stuff->parent == savedScreenInfo[0].wid);
+                   (stuff->parent == screenInfo.screens[0]->screensaver.wid);
     FOR_NSCREENS_BACKWARD(j) {
     stuff->window = win->info[j].id;
     stuff->parent = parent->info[j].id;
@@ -476,7 +476,7 @@ int PanoramiXConfigureWindow(ClientPtr client)
     }
 
     if(pWin->parent && ((pWin->parent == WindowTable[0]) ||
-                        (pWin->parent->drawable.id == savedScreenInfo[0].wid)))
+                        (pWin->parent->drawable.id == screenInfo.screens[0]->screensaver.wid)))
     {
     if ((Mask)stuff->mask & CWX) {
         x_offset = 0;
@@ -563,7 +563,7 @@ int PanoramiXGetGeometry(ClientPtr client)
     rep.x = pWin->origin.x - wBorderWidth (pWin);
     rep.y = pWin->origin.y - wBorderWidth (pWin);
     if((pWin->parent == WindowTable[0]) || 
-           (pWin->parent->drawable.id == savedScreenInfo[0].wid))
+           (pWin->parent->drawable.id == screenInfo.screens[0]->screensaver.wid))
         {
        rep.x += panoramiXdataPtr[0].x;
        rep.y += panoramiXdataPtr[0].y;
@@ -597,7 +597,7 @@ int PanoramiXTranslateCoords(ClientPtr client)
     rep.child = None;
 
     if((pWin == WindowTable[0]) || 
-       (pWin->drawable.id == savedScreenInfo[0].wid))
+       (pWin->drawable.id == screenInfo.screens[0]->screensaver.wid))
     { 
     x = stuff->srcX - panoramiXdataPtr[0].x;
     y = stuff->srcY - panoramiXdataPtr[0].y;
@@ -635,7 +635,7 @@ int PanoramiXTranslateCoords(ClientPtr client)
     rep.dstX = x - pDst->drawable.x;
     rep.dstY = y - pDst->drawable.y;
     if((pDst == WindowTable[0]) || 
-       (pDst->drawable.id == savedScreenInfo[0].wid))
+       (pWin->drawable.id == screenInfo.screens[0]->screensaver.wid))
     {
     rep.dstX += panoramiXdataPtr[0].x;
     rep.dstY += panoramiXdataPtr[0].y;

Git tells me all the contact info I need:

commit 80b5d3a3264d2c5167e5ac85a3b04af0f89cece1
Author: Jamey Sharp <jamey@minilop.net>
Date:   Fri May 21 23:13:51 2010 -0700

    Move each screen's screensaver data into ScreenRec.
    
    Most references to the savedScreenInfo array already had the
    corresponding screen pointer handy, which meant they usually looked like
    "savedScreenInfo[pScreen->myNum]". Adding a field to ScreenRec instead
    of keeping this information in a parallel array simplifies those
    expressions, and eliminates a MAXSCREENS-sized array.
    
    Since dix uses this data, a screen private entry isn't appropriate.
    
    Signed-off-by: Jamey Sharp <jamey@minilop.net>
    Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
    Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)

So I will send the developers an email and simply ask him if he meant to change that pDst to pWin in Xext/panoramiX.c, or if it was a copy/paste error (seems like it is). I'll report back here afterwards.

Last edited by listdata (2010-10-17 21:23:09)

listdata · 2010-10-15 19:51:23

E-mail sent. Hopefully this issue will be resolved soon...

securitybreach · 2010-10-17 03:06:28

listdata wrote:

E-mail sent. Hopefully this issue will be resolved soon...

Thanks a lot!

listdata · 2010-10-17 19:54:56

A patch has been created and has been submitted upstream: http://lists.x.org/archives/xorg-devel/ … 14150.html

I just wanted to add that Ochi's work in pinpointing the bug and the logic behind it has been invaluable.

Last edited by listdata (2010-10-17 19:59:42)

Ochi · 2010-10-17 20:57:28

I'm glad I could help.

gryphius · 2010-10-18 06:33:18

I can confirm this patch fixes the problem for me as well. Many many thanks!

Arch Linux

#1 2010-10-06 02:15:01

[SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#2 2010-10-06 06:51:07

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#3 2010-10-06 15:06:56

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#4 2010-10-06 15:46:39

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#5 2010-10-06 19:24:28

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#6 2010-10-06 20:27:45

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#7 2010-10-07 12:21:07

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#8 2010-10-10 03:14:12

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#9 2010-10-10 09:22:20

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#10 2010-10-11 18:52:05

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#11 2010-10-11 19:08:28

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#12 2010-10-12 18:58:30

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#13 2010-10-12 21:38:26

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#14 2010-10-12 21:51:57

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#15 2010-10-15 15:30:12

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#16 2010-10-15 17:42:21

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#17 2010-10-15 18:45:04

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#18 2010-10-15 18:45:24

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#19 2010-10-15 19:10:16

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#20 2010-10-15 19:33:44

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#21 2010-10-15 19:51:23

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#22 2010-10-17 03:06:28

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#23 2010-10-17 19:54:56

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#24 2010-10-17 20:57:28

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

#25 2010-10-18 06:33:18

Re: [SOLVED] Xorg 1.9 + qt 4.7 + nvidia + xinerama = Xorg segfault

Board footer