Bug 723777 - X crashes shortly before end of installation
X crashes shortly before end of installation
Status: VERIFIED FIXED
: 720571 721671 721676 724347 724713 725045 (view as bug list)
Classification: openSUSE
Product: openSUSE 12.1
Classification: openSUSE
Component: Installation
Factory
x86-64 Other
: P1 - Urgent : Critical (vote)
: ---
Assigned To: Egbert Eich
Jiri Srain
:
Depends on:
Blocks: 721676 724713
  Show dependency treegraph
 
Reported: 2011-10-13 07:10 UTC by Harald Koenig
Modified: 2013-06-26 07:39 UTC (History)
9 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
yast logs after crash (1.28 MB, application/x-gzip)
2011-10-13 07:10 UTC, Harald Koenig
Details
X log file (82.35 KB, text/plain)
2011-10-13 07:13 UTC, Harald Koenig
Details
more yast logs & dmesg output (25.40 KB, application/x-gzip)
2011-10-13 23:31 UTC, Harald Koenig
Details
bzipped Xorg core dump (6.02 MB, application/x-bzip2)
2011-10-14 17:55 UTC, Bernhard Wiedemann
Details
xf86debug output (14.91 KB, text/plain)
2011-10-14 18:05 UTC, Bernhard Wiedemann
Details
Xlog after udevadm trigger ... (83.00 KB, text/plain)
2011-10-17 12:38 UTC, Harald Koenig
Details
Fix. (2.00 KB, patch)
2011-10-18 19:01 UTC, Egbert Eich
Details | Diff
Opensuse 12.1 domu setup (75.81 KB, image/jpeg)
2011-11-18 19:01 UTC, Romain Pelissier
Details
y2log at the crash time (9.48 MB, text/plain)
2011-11-20 16:49 UTC, Bruno Friedmann
Details
Xorg.0.log with segfault (26.55 KB, text/plain)
2011-11-20 16:53 UTC, Bruno Friedmann
Details
kvm/libvirtd VM definition (2.66 KB, application/xml)
2011-11-20 17:54 UTC, Bruno Friedmann
Details
AutoConfigure installation file used (68.62 KB, application/xml)
2011-11-21 15:02 UTC, Bruno Friedmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koenig 2011-10-13 07:10:02 UTC
Created attachment 456144 [details]
yast  logs after crash

this happend twice now (for 2 tries), so it's not just a spurious problem:

I'm booting from Beta1 via usb stick and start network installation directly from factory. I've selected XFCE desktop which installs ~2500+ packages. this takes >2h for my slow DSL line.

more or less at the end of installation (shortly after I've seen ~2 min left) the Xserver crashes (see Xorg.0.log) and the installation stuck in text mode...


this is the end of y2log -- full log attached...

2011-10-13 05:35:28 <1> noname(3444) [zypp:fetcher] Fetcher.cc(provideFromCache):350 start fetcher with 1 cache directories.
2011-10-13 05:35:28 <1> noname(3444) [zypp:fetcher] Fetcher.cc(provideToDest):548 Not found in cache, downloading
2011-10-13 05:35:28 <1> noname(3444) [zypp++] MediaSetAccess.cc(provide):203 Going to try to provide  file ./suse/x86_64/xorg-x11-Xvnc-7.6_1.10.4-34.2.x86_64.rpm from media number 1
2011-10-13 05:35:28 <1> noname(3444) [zypp++] MediaManager.cc(checkDesired):112 checkDesired(5): desired (cached)
2011-10-13 05:35:28 <1> noname(3444) [zypp++] MediaManager.cc(checkDesired):112 checkDesired(5): desired (cached)
2011-10-13 05:35:28 <1> noname(3444) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1266 dest: /mnt/var/tmp/AP_0x00000001/suse/x86_64/xorg-x11-Xvnc-7.6_1.10.4-34.2.x86_64.rpm
2011-10-13 05:35:28 <1> noname(3444) [zypp++] MediaMultiCurl.cc(doGetFileCopy):1267 temp: /mnt/var/tmp/AP_0x00000001/suse/x86_64/xorg-x11-Xvnc-7.6_1.10.4-34.2.x86_64.rpm.new.zypp.gSJUGZ
2011-10-13 05:35:28 <1> noname(3444) [zypp++] MediaCurl.cc(doGetFileCopyFile):1320 ./suse/x86_64/xorg-x11-Xvnc-7.6_1.10.4-34.2.x86_64.rpm
2011-10-13 05:35:28 <1> noname(3444) [zypp++] MediaCurl.cc(doGetFileCopyFile):1330 URL: http://download.opensuse.org/factory/repo/oss/suse/x86_64/xorg-x11-Xvnc-7.6_1.10.4-34.2.x86_64.rpm
2011-10-13 05:35:28 <2> noname(3444) [qt-ui] YQUI.cc(qMessageHandler):729 <libqt-warning> YaST2: Fatal IO error: client killed
2011-10-13 05:35:28 <3> noname(3444) [qt-ui] YQUI.cc(qMessageHandler):744 Client killed. Possibly caused by X server shutdown or crash.
2011-10-13 05:35:28 <1> noname(3444) [zypp] PathInfo.cc(recursive_rmdir):429 recursive_rmdir /var/tmp/zypp.RJkCec 
2011-10-13 05:35:28 <1> noname(3444) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/zypp.RJkCec{d 0700 0/0}
2011-10-13 05:35:28 <1> noname(3444) [zypp] PathInfo.cc(recursive_rmdir):429 recursive_rmdir /var/tmp/TmpDir.xGar88 
2011-10-13 05:35:28 <1> noname(3444) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/TmpDir.xGar88{d 0700 0/0}
2011-10-13 05:35:28 <1> noname(3444) [Pkg] PkgFunctions.cc(~PkgFunctions):147 Releasing the zypp pointer...
2011-10-13 05:35:28 <1> noname(3444) [Pkg] PkgFunctions.cc(~PkgFunctions):149 Zypp pointer released
2011-10-13 05:35:28 <1> noname(3444) [zypp] PathInfo.cc(recursive_rmdir):429 recursive_rmdir /var/tmp/TmpDir.6ulJhL 
2011-10-13 05:35:28 <1> noname(3444) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/TmpDir.6ulJhL{d 0700 0/0}
2011-10-13 05:35:28 <1> noname(3444) [zypp] PathInfo.cc(recursive_rmdir):429 recursive_rmdir /var/tmp/TmpDir.m76rxn 
2011-10-13 05:35:28 <1> noname(3444) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/TmpDir.m76rxn{d 0700 0/0}
2011-10-13 05:35:28 <1> noname(3444) [zypp] PathInfo.cc(recursive_rmdir):429 recursive_rmdir /var/tmp/TmpDir.OQfDVv 
2011-10-13 05:35:28 <1> noname(3444) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/TmpDir.OQfDVv{d 0700 0/0}
2011-10-13 05:35:28 <1> noname(3444) [zypp] PathInfo.cc(recursive_rmdir):429 recursive_rmdir /var/tmp/TmpDir.Cf5P4o 
2011-10-13 05:35:28 <1> noname(3444) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/TmpDir.Cf5P4o{d 0700 0/0}
2011-10-13 05:35:28 <1> noname(3444) [zypp] PathInfo.cc(recursive_rmdir):429 recursive_rmdir /var/tmp/TmpDir.ysL27y 
2011-10-13 05:35:28 <1> noname(3444) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/TmpDir.ysL27y{d 0700 0/0}
2011-10-13 05:35:28 <1> noname(3444) [zypp] PathInfo.cc(recursive_rmdir):429 recursive_rmdir /var/tmp/TmpDir.QZ0Yqc 
2011-10-13 05:35:28 <1> noname(3444) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/TmpDir.QZ0Yqc{d 0700 0/0}
2011-10-13 05:35:28 <1> noname(3444) [zypp] PathInfo.cc(recursive_rmdir):429 recursive_rmdir /var/tmp/TmpDir.oX0l2P 
2011-10-13 05:35:28 <1> noname(3444) [zypp++] TmpPath.cc(~Impl):78 TmpPath cleaned up /var/tmp/TmpDir.oX0l2P{d 0700 0/0}
2011-10-13 05:35:28 <1> noname(3444) [zypp++] MediaSetAccess.cc(release):431 Releasing all media IDs held by this MediaSetAccess
Comment 1 Harald Koenig 2011-10-13 07:13:15 UTC
Created attachment 456146 [details]
X log file

Xserver seems to crash in "regular" shutdown du do earlier problems ?!

[   458.710] (II) config/udev: Adding input device Avocent USB Composite Device-0 (/dev/input/mouse1)
[   458.710] (II) No input driver/identifier specified (ignoring)
[  6312.019] (II) config/udev: removing device Power Button
[  6312.048] (II) Power Button: Close
[  6312.048] (II) UnloadModule: "evdev"
[  6312.048] (II) Unloading evdev
...
[  6312.101] (II) UnloadModule: "evdev"
[  6312.101] (II) Unloading evdev
[  6312.102] (II) config/udev: Adding input device Avocent USB Composite Device-0 (/dev/input/event3)
[  6312.102] (**) Avocent USB Composite Device-0: Applying InputClass "evdev pointer catchall"
[  6312.102] (II) Using input driver 'evdev' for 'Avocent USB Composite Device-0'
[  6312.102] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
[  6312.102] (**) Avocent USB Composite Device-0: always reports core events
[  6312.102] (**) Avocent USB Composite Device-0: Device: "/dev/input/event3"
[  6312.102] (--) Avocent USB Composite Device-0: Found 3 mouse buttons
[  6312.102] (--) Avocent USB Composite Device-0: Found scroll wheel(s)
[  6312.102] (--) Avocent USB Composite Device-0: Found relative axes
[  6312.102] (--) Avocent USB Composite Device-0: Found absolute axes
[  6312.102] (--) Avocent USB Composite Device-0: Found x and y absolute axes
[  6312.102] (II) Avocent USB Composite Device-0: Configuring as mouse
[  6312.102] (II) Avocent USB Composite Device-0: Adding scrollwheel support
[  6312.102] (**) Avocent USB Composite Device-0: YAxisMapping: buttons 4 and 5
[  6312.102] (**) Avocent USB Composite Device-0: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[  6312.102] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:13.2/usb2/2-2/2-2:1.1/input/input3/event3"
[  6312.102] (II) XINPUT: Adding extended input device "Avocent USB Composite Device-0" (type: MOUSE)
[  6312.102] (EE) Avocent USB Composite Device-0: failed to initialize for relative axes.
[  6312.103] (II) Avocent USB Composite Device-0: initialized for absolute axes.
[  6312.103] (**) Avocent USB Composite Device-0: (accel) keeping acceleration scheme 1
[  6312.103] (**) Avocent USB Composite Device-0: (accel) acceleration profile 0
[  6312.103] (**) Avocent USB Composite Device-0: (accel) acceleration factor: 2.000
[  6312.103] (**) Avocent USB Composite Device-0: (accel) acceleration threshold: 4
[  6312.103] 
Backtrace:
[  6312.103] 0: Xorg (xorg_backtrace+0x26) [0x462286]
[  6312.103] 1: Xorg (0x400000+0x66819) [0x466819]
[  6312.103] 2: /lib64/libpthread.so.0 (0x7effb8ddf000+0xfd00) [0x7effb8deed00]
[  6312.103] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7effb39a1000+0x5cf9) [0x7effb39a6cf9]
[  6312.103] 4: Xorg (WakeupHandler+0x5b) [0x43712b]
[  6312.104] 5: Xorg (WaitForSomething+0x1b6) [0x45fda6]
[  6312.104] 6: Xorg (0x400000+0x32fe2) [0x432fe2]
[  6312.104] 7: Xorg (0x400000+0x2727e) [0x42727e]
[  6312.104] 8: /lib64/libc.so.6 (__libc_start_main+0xed) [0x7effb7d5723d]
[  6312.104] 9: Xorg (0x400000+0x2756d) [0x42756d]
[  6312.104] Segmentation fault at address (nil)
[  6312.104] 
Fatal server error:
[  6312.104] Caught signal 11 (Segmentation fault). Server aborting
[  6312.104] 
[  6312.104] 
Please consult the The X.Org Foundation support
Comment 2 Harald Koenig 2011-10-13 23:31:54 UTC
Created attachment 456416 [details]
more yast logs & dmesg output

update: tried to install "minimal text only" setup -- crashed too.

this time I noticed lots of btrfs kernel messages (did't check dmesg output before) like this, full output in the attached tar file...

could btrfs be the reason for the yast crashes due to I/O errors ?!?

[ 1625.208245] ------------[ cut here ]------------
[ 1625.208285] WARNING: at /usr/src/packages/BUILD/kernel-default-3.1.rc7/linux-3.1-rc7/fs/btrfs/extent-tree.c:5711 use_block_rsv+0xc8/0x160 [btrfs]()
[ 1625.208293] Hardware name: ProLiant MicroServer
[ 1625.208297] Modules linked in: btrfs zlib_deflate dm_mod multipath raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 parport_pc parport vfat fat arc4 ecb powernow_k8 mperf fan thermal nfs nfs_acl lockd fscache auth_rpcgss sunrpc nls_iso8859_1 nls_cp437 af_packet st sr_mod cdrom usbhid usb_storage uas sg ata_generic ohci_hcd ssb mmc_core button processor ehci_hcd thermal_sys tg3 pata_atiixp pcmcia pcmcia_core usbcore edd squashfs loop [last unloaded: parport]
[ 1625.208382] Pid: 4811, comm: btrfs-freespace Tainted: G        W   3.1.0-rc7-3-default #1
[ 1625.208387] Call Trace:
[ 1625.208414]  [<ffffffff810042fa>] dump_trace+0x9a/0x270
[ 1625.208426]  [<ffffffff81522128>] dump_stack+0x69/0x6f
[ 1625.208439]  [<ffffffff81051f5b>] warn_slowpath_common+0x7b/0xc0
[ 1625.208467]  [<ffffffffa0349b18>] use_block_rsv+0xc8/0x160 [btrfs]
[ 1625.208543]  [<ffffffffa0352989>] btrfs_alloc_free_block+0x49/0x220 [btrfs]
[ 1625.208626]  [<ffffffffa0344e02>] split_leaf+0x122/0x710 [btrfs]
[ 1625.208679]  [<ffffffffa0345d9e>] btrfs_search_slot+0x70e/0x770 [btrfs]
[ 1625.208739]  [<ffffffffa0357e7f>] btrfs_csum_file_blocks+0x49f/0x5f0 [btrfs]
[ 1625.208843]  [<ffffffffa0363c4d>] add_pending_csums.isra.35+0x3d/0x60 [btrfs]
[ 1625.208980]  [<ffffffffa0367c60>] btrfs_finish_ordered_io+0x230/0x340 [btrfs]
[ 1625.209125]  [<ffffffffa037b6b0>] end_bio_extent_writepage+0x120/0x170 [btrfs]
[ 1625.209334]  [<ffffffffa03879e1>] worker_loop+0xa1/0x2a0 [btrfs]
[ 1625.209547]  [<ffffffff8107341e>] kthread+0x7e/0x90
[ 1625.209560]  [<ffffffff81544234>] kernel_thread_helper+0x4/0x10
[ 1625.209570] ---[ end trace 8dd42cedbf231f45 ]---
Comment 3 Harald Koenig 2011-10-14 06:51:09 UTC
update: it's *not* a btrfs problem!

I've started one more installation without btrfs (only LVM, all defaults) and this crashes the same way:

[qt-ui] YQUI.cc(qMessageHandler):729 <libqt-warning> YaST2: Fatal IO error: client killed


now I wonder if
- yast breaks because Xserver is dying (then: why does X crash)
- yast crashes (why?) and this causes the Xserver to shutdown 

any suggestions how to distinguish which cash is the first one (yast or Xserver) ?


for now I've started an installation in text mode... :-(
Comment 4 Egbert Eich 2011-10-14 16:07:23 UTC
*** Bug 720571 has been marked as a duplicate of this bug. ***
Comment 5 Bernhard Wiedemann 2011-10-14 17:55:06 UTC
Created attachment 456721 [details]
bzipped Xorg core dump

I managed to get a core dump from the segfaulting Xorg process by adding to bootloader: info=http://zq1.de/i insecure=1

however, no debug symbols were resolved in the gdb backtrace within inst-sys, so I hope you can do that with the backtrace and current Factory xorg debuginfo packages.
Comment 6 Bernhard Wiedemann 2011-10-14 18:05:15 UTC
Created attachment 456724 [details]
xf86debug output

just noticed that there are actually line numbers and variable contents in this
Comment 7 Bernhard Wiedemann 2011-10-17 07:51:27 UTC
just noticed that both in the y2log from Harald and in one I got when installing on my laptop, the last package installed before the crash is
xorg-x11-driver-input
So the installation of it in /mnt can somehow cause problems in the X-server of the install system.
Maybe through post-install scripts?
Comment 8 Stefan Dirsch 2011-10-17 08:21:22 UTC
I guess udevadmin %post is the trigger of the Xserver crash. Seen bnc #724347.
Comment 9 Harald Koenig 2011-10-17 09:58:44 UTC
just a few observations from last friday's night only -- this weekend the weather was just too good... :-(

* reading the Xorg.0.log, Egbert and I guess that the evdev crash might be caused in Xserver restart since X does an unload to evdev and other drivers 1st before reinitializing (despite that X is running with "-noreset" option -- strange ?!)

"proof" of idea:   if I start "xterm -display :0" on VC2 to keep at least one xclient connected, the Xserver does not crash anymore and the installations finishes as expected!


BUT: I can't reproduce the X crash in the install environment with a 2nd Xserver by running

     X :1 -noreset .... (all other options from :0) &
     xterm -display :1 &

and then "exit" in xterm as single client.  even without "-noreset" the Xserver :1 keeps running for multiple start/stop of that single xterm.


* question: what's going on and who exits/crashes first (yast or X).
idea: run strace on both yast and xserver with timestamps etc.
and check output for the sequence of events.

BUT: running strace with foll output of all syscalls covers the problem, installation works ok, no Xserver crash anymore 

so the problem might be some race condition ?!?


next planned tests (TBD): 
- run strace only either on yast or Xserver -- which one causes the issues ?
- run strace with "-e write" or "-e connect" to reduce output (still show signals like SIGSEGV),
  to keep the chance to catch the race 
- attach gdb to the running X :0 and set a breakpoint to the evdev stuff to get some more info why it runns into that code... 

- other ideas ?
Comment 10 Stefan Dirsch 2011-10-17 10:31:23 UTC
Thanks, Harald. Could you give the possible udevadm trigger a try.
Comment 11 Egbert Eich 2011-10-17 11:29:15 UTC
(In reply to comment #9)

>   to keep the chance to catch the race 
> - attach gdb to the running X :0 and set a breakpoint to the evdev stuff to get
> some more info why it runns into that code... 

This will most likely also work.
You may try Stefan's idea. This however doesn't bring us much closer to the resolution of this bug.
I'm going to build an evdev module with debug symbols for you. So when you get the crash I can use the offset to find where it is crashing. With a bit of luck the Xserver may already dump the function that's crashing.

Looks like you are using an x86_64 image, so I will build evdev for this.
Comment 12 Harald Koenig 2011-10-17 12:38:28 UTC
Created attachment 456975 [details]
Xlog after udevadm trigger ...
Comment 13 Harald Koenig 2011-10-17 12:39:34 UTC
(In reply to comment #10)
> Thanks, Harald. Could you give the possible udevadm trigger a try.

nope, this does not trigger the probem.  tried multiple times:-(

installation shows "Installationsmodus" (new installation / update an existing system) when I switched to VC2 to run "udevadm trigger --subsystem-match=input --action=change". that starts at time stamp 689.941 in the attached log file...

the first lines in the log file after that event look the same as in the real installation issue, but the SEGV does not happen (this time)
Comment 14 Harald Koenig 2011-10-18 07:01:21 UTC
(In reply to comment #10)
> Thanks, Harald. Could you give the possible udevadm trigger a try.

thanks, voila:

Program received signal SIGSEGV, Segmentation fault.
0x00007f7db7e73647 in EvdevMBEmuWakeupHandler (data=0xabc620, i=1, LastSelectMask=0x7eb220) at emuMB.c:273
273     emuMB.c: No such file or directory.
        in emuMB.c
(gdb) where
#0  0x00007f7db7e73647 in EvdevMBEmuWakeupHandler (data=0xabc620, i=1, LastSelectMask=0x7eb220) at emuMB.c:273
#1  0x000000000043712b in WakeupHandler ()
#2  0x000000000045fda6 in WaitForSomething ()
#3  0x0000000000432fe2 in ?? ()
#4  0x000000000042727e in ?? ()
#5  0x00007f7dbc22423d in __libc_start_main () from /lib64/libc.so.6
#6  0x000000000042756d in _start ()


the last lines in Xorg.0.log while keeping Xserver at that break:

...
[   677.025] (**) Logitech USB Receiver: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[   677.025] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:12.0/usb4/4-2/4-2:1.1/input/input8/event8"
[   677.025] (II) XINPUT: Adding extended input device "Logitech USB Receiver" (type: KEYBOARD)
[   677.025] (**) Option "xkb_rules" "evdev"
[   677.025] (**) Option "xkb_model" "evdev"
[   677.025] (**) Option "xkb_layout" "us"
[   677.025] (II) Logitech USB Receiver: initialized for relative axes.
[   677.025] (**) Logitech USB Receiver: (accel) keeping acceleration scheme 1
[   677.025] (**) Logitech USB Receiver: (accel) acceleration profile 0
[   677.025] (**) Logitech USB Receiver: (accel) acceleration factor: 2.000
[   677.025] (**) Logitech USB Receiver: (accel) acceleration threshold: 4




a few more notes for debugging:

switching just once from X11 to VC2 and back seems to be "enough" to avoid the problem, no more crash!

so I have to set "start shell before/after yast" in the install settings to get a shell before starting X11 to initialize network and ssh.  then I can run "udevadm trigger" via ssh and still crash the Xserver (and run gdb in ssh).
Comment 15 Harald Koenig 2011-10-18 07:12:08 UTC
more details:

with ssh it's now easy to reproduce/debug:  just

gdb Xorg
run

and then just "udevadm trigger ..." in a 2nd ssh login...
please attach source for emuMB.c


FYI: EvdevMBEmuWakeupHandler gets called *many* times before it crashes:

...
Breakpoint 1, EvdevMBEmuWakeupHandler (data=0x9df630, i=1, LastSelectMask=0x7eb220) at emuMB.c:269
269     in emuMB.c
1: x/i $pc
=> 0x7ffff1db962f <EvdevMBEmuWakeupHandler+20>: mov    -0x38(%rbp),%rax
(gdb) 
Continuing.

Breakpoint 1, EvdevMBEmuWakeupHandler (data=0x9e3300, i=1, LastSelectMask=0x7eb220) at emuMB.c:269
269     in emuMB.c
1: x/i $pc
=> 0x7ffff1db962f <EvdevMBEmuWakeupHandler+20>: mov    -0x38(%rbp),%rax
(gdb) 
Continuing.

Breakpoint 1, EvdevMBEmuWakeupHandler (data=0x9ce6f0, i=1, LastSelectMask=0x7eb220) at emuMB.c:269
269     in emuMB.c
1: x/i $pc
=> 0x7ffff1db962f <EvdevMBEmuWakeupHandler+20>: mov    -0x38(%rbp),%rax
(gdb) 
Continuing.

Breakpoint 1, EvdevMBEmuWakeupHandler (data=0x9df630, i=1, LastSelectMask=0x7eb220) at emuMB.c:269
269     in emuMB.c
1: x/i $pc
=> 0x7ffff1db962f <EvdevMBEmuWakeupHandler+20>: mov    -0x38(%rbp),%rax
(gdb) 
Continuing.

Breakpoint 1, EvdevMBEmuWakeupHandler (data=0x9e3300, i=1, LastSelectMask=0x7eb220) at emuMB.c:269
269     in emuMB.c
1: x/i $pc
=> 0x7ffff1db962f <EvdevMBEmuWakeupHandler+20>: mov    -0x38(%rbp),%rax
(gdb) 
Continuing.

Breakpoint 1, EvdevMBEmuWakeupHandler (data=0x9ce6f0, i=1, LastSelectMask=0x7eb220) at emuMB.c:269
269     in emuMB.c
1: x/i $pc
=> 0x7ffff1db962f <EvdevMBEmuWakeupHandler+20>: mov    -0x38(%rbp),%rax
(gdb) 
Continuing.

Breakpoint 1, EvdevMBEmuWakeupHandler (data=0x9df630, i=1, LastSelectMask=0x7eb220) at emuMB.c:269
269     in emuMB.c
1: x/i $pc
=> 0x7ffff1db962f <EvdevMBEmuWakeupHandler+20>: mov    -0x38(%rbp),%rax
(gdb) 
Continuing.

Breakpoint 1, EvdevMBEmuWakeupHandler (data=0x9e3300, i=1, LastSelectMask=0x7eb220) at emuMB.c:269
269     in emuMB.c
1: x/i $pc
=> 0x7ffff1db962f <EvdevMBEmuWakeupHandler+20>: mov    -0x38(%rbp),%rax
(gdb) 
Continuing.

Breakpoint 1, EvdevMBEmuWakeupHandler (data=0x9ce6f0, i=1, LastSelectMask=0x7eb220) at emuMB.c:269
269     in emuMB.c
1: x/i $pc
=> 0x7ffff1db962f <EvdevMBEmuWakeupHandler+20>: mov    -0x38(%rbp),%rax
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff1db9647 in EvdevMBEmuWakeupHandler (data=0x9ce6f0, i=1, LastSelectMask=0x7eb220) at emuMB.c:273
273     in emuMB.c
1: x/i $pc
=> 0x7ffff1db9647 <EvdevMBEmuWakeupHandler+44>: movzbl 0x2c1(%rax),%eax
(gdb) 
Continuing.

Backtrace:
0: /usr/bin/Xorg (xorg_backtrace+0x26) [0x462286]
1: /usr/bin/Xorg (0x400000+0x66819) [0x466819]
2: /lib64/libpthread.so.0 (0x7ffff71f2000+0xfd00) [0x7ffff7201d00]
3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7ffff1db2000+0x7647) [0x7ffff1db9647]
4: /usr/bin/Xorg (WakeupHandler+0x5b) [0x43712b]
5: /usr/bin/Xorg (WaitForSomething+0x1b6) [0x45fda6]
6: /usr/bin/Xorg (0x400000+0x32fe2) [0x432fe2]
7: /usr/bin/Xorg (0x400000+0x2727e) [0x42727e]
8: /lib64/libc.so.6 (__libc_start_main+0xed) [0x7ffff616a23d]
9: /usr/bin/Xorg (0x400000+0x2756d) [0x42756d]
Segmentation fault at address 0x2e2
Comment 16 Bernhard Wiedemann 2011-10-18 07:53:31 UTC
ship stopper? because it affects (randomly) all graphical installations
also there are many dups
Comment 17 Bernhard Wiedemann 2011-10-18 08:16:10 UTC
(In reply to comment #14)
> a few more notes for debugging:
> 
> switching just once from X11 to VC2 and back seems to be "enough" to avoid the
> problem, no more crash!
ah, this is why it stopped occurring on openQA (I dump some info on tty2 there)

> so I have to set "start shell before/after yast" in the install settings to get
> a shell before starting X11 to initialize network and ssh.  then I can run
> "udevadm trigger" via ssh and still crash the Xserver (and run gdb in ssh).

you can use ctrl-alt-shift-x for an xterm as documented now in
http://en.opensuse.org/SDB:YaST_tricks#YaST_Hotkeys
Comment 18 Stephan Kulow 2011-10-18 09:17:21 UTC
I never saw it, but many do ;(
Comment 19 James Ogley 2011-10-18 09:35:23 UTC
*** Bug 721676 has been marked as a duplicate of this bug. ***
Comment 20 Egbert Eich 2011-10-18 19:01:57 UTC
Created attachment 457368 [details]
Fix.

When reloading the input drivers the UnregisterHandler() function is called from within a Block/WakeupHandler. In this case the list if handlers is not corrected immediately but a handler is marked deleted. If the deleted handler is in the call chain behind the handler that calls unregister it may access data structures that might no longer exist thus leading to a crash.
Thus check for the "deleted" flag before calling.
Comment 21 Egbert Eich 2011-10-18 19:03:00 UTC
Patch submitted.
Comment 22 Egbert Eich 2011-10-18 19:06:56 UTC
Harald, many thanks for your help!
And thanks to everyone else involved - like Bernhard Widemann and Jan Engelhardt for the right hint.
Comment 23 Egbert Eich 2011-10-18 19:10:48 UTC
*** Bug 724347 has been marked as a duplicate of this bug. ***
Comment 24 Egbert Eich 2011-10-19 05:50:30 UTC
*** Bug 724713 has been marked as a duplicate of this bug. ***
Comment 25 Andreas Jaeger 2011-10-19 07:45:34 UTC
*** Bug 725045 has been marked as a duplicate of this bug. ***
Comment 26 Jiří Suchomel 2011-10-25 10:35:55 UTC
*** Bug 721671 has been marked as a duplicate of this bug. ***
Comment 27 Romain Pelissier 2011-11-18 19:01:24 UTC
Created attachment 462974 [details]
Opensuse 12.1 domu setup
Comment 28 Romain Pelissier 2011-11-18 19:02:37 UTC
Sorry to re open this bug report but the issue is till there for me:

- Dom0 Xen opensuse 12.1
- Domu opensuse 12.1 full virtualized

Romain
Comment 29 Bruno Friedmann 2011-11-20 16:36:36 UTC
Same here : just test a minimal Xorg install from PXE and with btrfs as / under KVM

Crash : in the sense nothing happen without ctrl-alt-del after the now starting system with kexec 

Attachment of all log at that stage will follow
Comment 30 Bruno Friedmann 2011-11-20 16:49:22 UTC
Created attachment 463054 [details]
y2log at the crash time

the y2log crash file 
before the ctrl-alt-del
Comment 31 Bruno Friedmann 2011-11-20 16:53:05 UTC
Created attachment 463055 [details]
Xorg.0.log with segfault
Comment 32 Bruno Friedmann 2011-11-20 17:54:57 UTC
Created attachment 463057 [details]
kvm/libvirtd VM definition
Comment 33 Bruno Friedmann 2011-11-21 15:02:58 UTC
Created attachment 463190 [details]
AutoConfigure installation file used 

If you replace my local mirror (yoda) by the normal repositories you should be able to have a quick way to auto-install and reproduce. 

Used with pxe
Comment 34 Romain Pelissier 2011-11-23 17:48:33 UTC
I am just wondering if in case the issue is with X that segfault for some reason, we can still use a different method to install a domu with opensuse 12.1, like:

- During domu creation, use a standard vga virtual card instead a one that of a 'standard' one. The installer could then use the ncurses install instead the X graphical install
- Use a parameter a boot time (?) to tell the installer to use ncurses installer.

I haven't tested this solutions. I am pretty sure that when booting the dvd/iso, we can use a screen resolution that will force the installer to use ncurses. 

I will test this soon
Any comments?
Thanks
Comment 35 Egbert Eich 2013-06-26 07:39:44 UTC
.