Xorg crash

Any thoughts on this bug? It's making my laptop environment unusable. :(

I don't see a backtrace here.

On Mar 06, 2014, at 11:37 AM, Maarten Lankhorst wrote:

>I don't see a backtrace here.

I have an /etc/X11/core file, but I can't seem to get a backtrace out of it.
ubuntu-bug refuses to file the bug because vmware is involved. Tell me what
you need and I'll happily provide it.

I've narrowed it down to some interaction between Terminal and Emacs 24. You can discount Claws and Gnome Do.

I can reproduce this every time with this recipe:

* reboot
* login
* hit Alt to bring up the launcher
* start up a Terminal
* In the Terminal, enter "emacs -q" to bring up a vanilla Emacs 24
* Go back to the Terminal and maximize it (i.e. hit the third button from the left in the menu bar, the square)
* Go to the global menu bar and double click as if de-maximizing the Terminal
* X crashes

FWIW, neither gnome-terminal nor emacs24 have been updated in a long while, so this is clearly a regression in the X stack somewhere.

More fun facts:

If, after you start up emacs -q, you immediate quit it, the recipe in #5 still crashes X.

Starting non-X emacs (e.g. `emacs -nw` in a terminal) does not crash X.

Starting multiple terminals does not crash X.

I'm going to try to rebuild Emacs against the current Trusty package set and see if that can provoke the problem.

Problem still exhibits with a rebuild of emacs24. I'm still going to upload a new Debian merge of emacs24 even though it doesn't fix this problem. Makes some sense though: it should never be possible for an application to crash X (or cause some data corruption just by running that allows some other application to crash X ;).

What version of vmware are you using?

I've created a clean vm with the trusty daily image using vmware workstation.
I've installed emacs24.3+1-2ubuntu1 and tried running it with emacs -q. It opens a separate X window which doesn't crash.

In one of my attempts I managed to make it crash, but I can't reproduce it in any reliable way.

Can you post the steps that get you a reliable crash?

At Barry's request I've tried to reproduce the steps given in comment #5.

Caveat: If I type 'alt' and enter 'terminal' I get no completion to launch the terminal, so for the test I launched it using the sidebar.

Having done so, launching 'emacs -q &' from the terminal and doing the maximize and minimize steps as stated do not crash X.

I'm running VMWare Version 6.0.2 (1398658) on the latest Mavericks.

My version of Trusty is up-to-date but 'apt-get upgrade' shows held-back packages. I'm running:

Linux trusty64 3.13.0-8-generic #28-Ubuntu SMP Tue Feb 11 17:55:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

ii xserver-xorg 1:7.7+1ubuntu8 amd64 X.Org X server
ii emacs24 24.3+1-2ubuntu1 amd64 GNU Emacs editor (with GTK+ user interface)
ii xserver-xorg-video-vmware 1:13.0.1.git.20140115.8da9817-0ubuntu2 amd64 X.Org X server -- VMware display driver

VMware Fusion 6.0.2 (1398658) on OS X 10.9.2.

It's quite easy and reproducible to crash. Here are the steps:

* Log in
* Hit Alt to bring up the launcher
* Start up gnome-terminal
* In the terminal, type `emacs -q`
* In Emacs 24, hit `Ctrl-x Ctrl-c RET` to quit Emacs.
* Go back to the terminal and double click on its menu bar to globally maximize the window
* Go to the global menu bar and double click on it to de-maximize the terminal

At this point, X crashes every time.

One other note: I am fully dist-upgraded on Trusty (no held back packages), but I cannot run the 3.13.0-16-generic #36 kernel because that exhibits the log in freeze of LP: #1289410. So at grub select "Advanced options for Ubuntu" and boot the 3.13.0-15.generic kernel. This allows me to log in and reproduce the bug.

@Brad thanks for trying to reproduce. Note that when I hit Alt to bring up the launcher, just type enough of "Terminal" to see it in Applications. Then I use the arrow keys to select the Terminal. I actually don't think it matters *how* gnome-terminal is started though. Same thing happens if you start it with Gnome Do. I just wanted to eliminate one non-standard package from the mix.

The problem clearly is that even just starting Emacs 24 corrupts something in X. Emacs doesn't even have to be running when you crash X, hence the suggestion to start it and then immediately kill it before triggering the bug.

Also @Brad: you could take a disk snapshot, then dist-upgrade away your held packages. It would then be easy to restore the disk snapshot if things break for you.

Note too that there are certainly other surprising ways to crash X, it's just that the recipe in #13 is completely reproducible every time.

% dpkg-query -W xserver-xorg emacs24 xserver-xorg-video-vmware
emacs24 24.3+1-2ubuntu1
xserver-xorg 1:7.7+1ubuntu8
xserver-xorg-video-vmware 1:13.0.1.git.20140115.8da9817-0ubuntu2

(gdb) bt
#0 0x00007f8d7fb3ff79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f8d7fb43388 in __GI_abort () at abort.c:89
#2 0x00007f8d7fb38e36 in __assert_fail_base (fmt=0x7f8d7fc8a4b8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f8d7c2f58fd "svga->curr.sampler[i]",
    file=file@entry=0x7f8d7c2f5898 "../../../../../../src/gallium/drivers/svga/svga_state_fs.c", line=line@entry=246, function=function@entry=0x7f8d7c2f595d "make_fs_key")
    at assert.c:92
#3 0x00007f8d7fb38ee2 in __GI___assert_fail (assertion=0x7f8d7c2f58fd "svga->curr.sampler[i]",
    file=0x7f8d7c2f5898 "../../../../../../src/gallium/drivers/svga/svga_state_fs.c", line=246, function=0x7f8d7c2f595d "make_fs_key") at assert.c:101
#4 0x00007f8d7c2d0f12 in ?? () from /usr/lib/x86_64-linux-gnu/libxatracker.so.2
#5 0x00007f8d7c2cd64b in ?? () from /usr/lib/x86_64-linux-gnu/libxatracker.so.2
#6 0x00007f8d7c2c9be6 in ?? () from /usr/lib/x86_64-linux-gnu/libxatracker.so.2
#7 0x00007f8d7bd87924 in u_vbuf_draw_vbo () from /usr/lib/x86_64-linux-gnu/libgallium.so.0
#8 0x00007f8d7bd0d4e4 in cso_draw_arrays () from /usr/lib/x86_64-linux-gnu/libgallium.so.0
#9 0x00007f8d7bd612ec in util_draw_user_vertex_buffer () from /usr/lib/x86_64-linux-gnu/libgallium.so.0
#10 0x00007f8d7c2a7b08 in ?? () from /usr/lib/x86_64-linux-gnu/libxatracker.so.2
#11 0x00007f8d7c2ba949 in xa_composite_done () from /usr/lib/x86_64-linux-gnu/libxatracker.so.2
#12 0x00007f8d7c52a6b0 in vmwgfx_composite_done (driver=0x7f8d82bb6650) at ../../vmwgfx/vmwgfx_saa.c:1239
#13 0x00007f8d7c532260 in saa_driver_composite (width=<optimized out>, height=<optimized out>, dst_reg=0x7fff3fab2e90, mask_reg=0x0, src_reg=0x7f8d82bb6a70,
    yDst=<optimized out>, xDst=<optimized out>, yMask=<optimized out>, xMask=<optimized out>, ySrc=14, xSrc=-10, pDst=<optimized out>, pMask=0x0, pSrc=<optimized out>,
    op=1 '\001') at ../../saa/saa_render.c:285
#14 saa_composite (op=<optimized out>, pSrc=<optimized out>, pMask=0x0, pDst=<optimized out>, xSrc=<optimized out>, ySrc=<optimized out>, xMask=0, yMask=0, xDst=0, yDst=0,
    width=1462, height=925) at ../../saa/saa_render.c:383
#15 0x00007f8d82120f84 in ?? ()
#16 0x00007f8d820d0b37 in ?? ()
#17 0x00007f8d820d1d6d in ?? ()
#18 0x00007f8d820cf2dc in ?? ()
#19 0x00007f8d8211b6a3 in ?? ()
#20 0x00007f8d8206e77f in ConfigureWindow ()
#21 0x00007f8d8203ec9b in ?? ()
#22 0x00007f8d82043a9e in ?? ()
#23 0x00007f8d8204789a in ?? ()
#24 0x00007f8d7fb2aec5 in __libc_start_main (main=0x7f8d82032e50, argc=11, argv=0x7fff3fab3408, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
    stack_end=0x7fff3fab33f8) at libc-start.c:285
#25 0x00007f8d82032e7e in _start ()

I'm no longer able to reproduce this bug Barry, Maarten can you?

On Mar 20, 2014, at 05:42 PM, Jakob Bornecrantz wrote:

>I'm no longer able to reproduce this bug Barry, Maarten can you?

Oh yes, it's definitely still happening.

Did you fully upgrade the VM?

Tho I no longer need to press enter to close emacs,
could this have something to do with it?

On Mar 21, 2014, at 11:43 AM, Jakob Bornecrantz wrote:

>Did you fully upgrade the VM?

Yes.

>Tho I no longer need to press enter to close emacs, could this have something
>to do with it?

I'm not sure what this means. Did you try the recipe in comment #5 and #7?

Oh I got it crashing again...

I was trying the steps in update #13 and that did not repro,
trying #5 caused it to crash once, then after several tries it
crashed again for me. Okay sorry for the noise, it looks like
it is there just hard to repro. Thanks again for the info.

It affects an essential hardware component (disk controller, built-in networking, video card, keyboard, mouse).

Hi Jakob. Is there anything else I can do to help push this issue along? It's so painful ;)

With today's dist-upgrade, this problem seems to have gone away. At least, I can no longer reproduce it with the last given known recipe. I'll mark this as Incomplete for now and reopen later if necessary.

This should have been fixed in libgl1-mesa-dri 10.1.0-4ubuntu4, I can't see it either, please comfirm.

On Apr 15, 2014, at 06:37 PM, Jakob Bornecrantz wrote:

>This should have been fixed in libgl1-mesa-dri 10.1.0-4ubuntu4, I can't
>see it either, please comfirm.

I'm currently running

libgl1-mesa-dri:amd64 10.1.0-4ubuntu2

and haven't seen it in a while. I'll check again after my next opportunity to
upgrade.