Unplugging USB tablet crashes xserver

[Neil Woolford]

Binary package hint: xserver-xorg-input-aiptek

I am using Jaunty beta, updated to 4th of April.

For several days now my Aiptek tablet has been working, but with a persistent bug.

If I unplug the tablet, the xserver crashes, giving a few moments of screen garbage followed by a return to GDM from which I start a new session.

I am not experiencing crashes if the tablet is left plugged in all the time. (Contrary to earlier experience with Intrepid, where the xserver would not start if the tablet was plugged in.)

[Neil Woolford (neil-neilwoolford)]

Problem persists for me in the released version of Jaunty. I'd be happy to provide more information or do more tests (maybe even lend the tablet) if anyone wants to work on this.

[Martin Olsson (mnemo)]

@Neil, can you please start the automatic crasher reporter and then trigger the bug? This will hopefully give us a full backtrace showing exactly where in the X server the crash happens. To start the crash reporter run this command:

sudo force_start=1 /etc/init.d/apport start

...afterwards just unplug the tablet to trigger the crash. When you login again, just wait like 1-2 minutes and there should be a dialog saying that "a crash was detected, would you like to submit a bug report?" so similar. Press SUBMIT and let it open a new bug report (then mark that new bug report as a duplicate of this one so we can grab the full backtrace from the logs in that report).

Also, please attach the output of "lsusb -v" to the bug report (run the command with the tablet connected). And finally it would also be nice if you saved the output of the "dmesg" command recorded after you have first triggered the crash /by unplugging), and then logged in again and then re-connected the tablet.

[Neil Woolford (neil-neilwoolford)]

Ok Martin.

I've tried to use apport to capture a crash report, but it just isn't happening... What appears to be a crash to me, the instant ending of my x session on unplugging the tablet isn't appearing as a crash to apport.

I have run "lsusb -v" and "dmesg" as you have asked and am uploading the results.

I'd still be happy to collect more debugging information manually.

[Martin Olsson (mnemo)]

Okay, what we need is to collect a full backtrace where each stacktrace has both local variable information and a proper function name. For this we're going to need debug symbols installed. Start by installing these packages (you mostly need the core package but it doesn't hurt to throw in all of them):

sudo apt-get -y install libc6-dbg xserver-xorg-core-dbg libgl1-mesa-dri-dbg libgl1-mesa-glx-dbg xserver-xorg-video-intel-dbg xserver-xorg-video-radeon-dbg xserver-xorg-video-ati-dbg libx11-6-dbg libice6-dbg

And that, please add the ddebs repository to your /etc/apt/sources.list file (and run "apt-get update") as explained here:
https://wiki.ubuntu.com/DebuggingProgramCrash
Once you have ddebs repository correctly setup you should be able to install these packages:

sudo apt-get -y install xserver-xorg-input-aiptek-dbgsym xserver-xorg-input-evdev-dbgsym xserver-xorg-input-mouse-dbgsym xserver-xorg-input-kbd-dbgsym
Again, I think you probably just need the "xserver-xorg-input-aiptek-dbgsym" one but more debug symbols are always nice to have.

Once you got the debug symbols installed you will be able to attach gdb to the X process and run "bt full" to see exactly what X is doing and the values of its variables and so forth. The best way to do this is to login to the buggy machine using ssh and attach gdb from there using "sudo gdb -p $(pidof X)" because once you freeze the X process for debugging all of X will be frozen. Once inside gdb, attached to X, just type "c" to let it continue running. Then you unplug the tablet so trigger the crash and instead of returning to GDM directly the debugger should switch back into "prompt mode" and at the "(gdb)" prompt just type "backtrace full" to see the full list of functions leading up to the crash. Please attach the full output of this "bt full" command to the bug report.

More info on obtaining backtraces for X is available here:
https://wiki.ubuntu.com/X/Backtracing

PS. It would also be useful if you attached the files /var/log/Xorg.0.log and also /var/log/Xorg.0.log.old recorded just after the crash happened, plus also the output of "lspci -vvnn".

[Neil Woolford (neil-neilwoolford)]

I'll run the backtraces in a bit, when I can get to a machine to ssh in from.

Neil

[Neil Woolford (neil-neilwoolford)]

After crash and restart, not trying backtrace yet.

[Neil Woolford (neil-neilwoolford)]

After crash and restart, not trying backtrace yet.

[Neil Woolford (neil-neilwoolford)]

The backtrace

[Martin Olsson (mnemo)]

There are some stack frames that still miss proper function names, for example there is:

      #12 0xb7f22749 in ?? () from /usr/lib/libhal.so.1

to get a proper function name for that one you need to install debug symbols for the package that ships the file "/usr/lib/libhal.so.1" and to find out which package that is you need to run "dpkg -S /usr/lib/libhal.so.1" (in this case the package is "libhal1" so you need "libhal1-dbgsym". Seems you also need symbols for "/lib/libdbus-1.so.3" which means "libdbus-1-3-dbgsym".

So please install:
sudo apt-get install libhal1-dbgsym libdbus-1-3-dbgsym

After that retrieve another "backtrace full" just like before.

[Martin Olsson (mnemo)]

btw, this also explains why the apport crash reporter didn't detect the crash. It's not actually a traditional "segmentation fault", instead it's a consistency check in the C library that notices that something is not right and then abort the program.

One thing that perplexes me about this backtrace is that Xfree(NULL) seems to call free(non_NULL_value), i.e. this part:

#5 0xb7c155b6 in *__GI___libc_free (mem=0x953c9c8) at malloc.c:3625
 ar_ptr = (mstate) 0xb7d04140
 p = (mchunkptr) 0x953c9c0
 hook = (void (*)(void *, const void *)) 0x6
#6 0x08139021 in Xfree (ptr=0x0) at ../../os/utils.c:1165
No locals.

I've have no explanation of how the above could possibly make sense (except "maybe its some weird gcc optimization" but if I said that I would be in the longshot guess department) ... let's ignore it for now.

Moving on, since this is a "double free" it owuld be interesting to see if the xf86AiptekUninit function is called multiple times with the same pointer value. Getting full backtraces of both of these calls would be useful. Especially since the weird Xfree() happens to call libc_free() with the exact same pointer value as the one pass to xf86AiptekUninit() in stackframe #8.

Once you have captured the full backtrace as I asked in the previous comment (I think it's still nice to have this when we upstream the bug report). Can you then try to put breakpoints on the functions xf86DeleteInput(), xf86AiptekUninit() and DeleteInputDeviceRequest() and then re-trigger the bug by disconnecting the tablet. Then please record a "backtrace full" every single time you hit a breakpoint and paste the log here again. You can activate logging to a file using the command "set logging file aiptek_gdb_log.txt" followed by the command "set logging on". Thanks.

[Neil Woolford (neil-neilwoolford)]

Backtrace with more debugging symbols available...

[Jon Nordby (jonnor)]

This bug is also present in Arch Linux current, with xf86-input-aiptek 1.2.0 and xorg-server 1.6.1. These packages are unpatched, so it is almost certain that this is an upstream problem. There has not been any commits to the aiptek driver git repo after 1.2.0

Some information I've gathered (likely not very useful, but included here just in case):
- The error seems to occur when the aiptek driver is removed: "rmmod aiptek" with the device plugged in produces this bug. When it is not connected, "modprobe aiptek && rmmod aiptek" works as expected; no crash.
- Removing the device is removed while hal is not running (in the middle of restarting hal for instance), it doesnt crash. Likely because the driver doesnt get removed.

I will produce a backtraces, dmesg and lsusb on a jaunty system shortly and add them here.

[Jon Nordby (jonnor)]

Had to set up a VM, so it took a while longer than expected. Hopefully the following backtraces will be useful. If not, let me know what to do. Remote access to this VM can also be arranged if wanted.

[Jon Nordby (jonnor)]

The breakpoints only seemed to trigger once.

[Jon Nordby (jonnor)]

Experienced with USB device:
08ca:0021 Aiptek International, Inc. APT-2 Tablet

Steps to reproduce:
1) insert tablet
2) rmmod aiptek

Tracebacks and other information avaliable here:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-aiptek/+bug/355021

As noted, root access to a system exhibiting this behavior can be arranged. Contact me by email.

[Jon Nordby (jonnor)]

Have you been able to reproduce this? Do you think there is enough information to reproduce the bug and/or solve?
If not, be sure to let me know what you need.

Known workarounds, if existing, would also be welcomed. Thanks in advance!

[Markus Birth (mbirth)]

Just wanted to add that for me (Jaunty, all updates as of today) X/GDM won't start correctly if the tablet is plugged in. Also I got X crashing when trying to start a new console (Terminator) while the tablet is plugged in. And yes, unplugging the tablet also hangs and then restarts X.

[Markus Birth (mbirth)]

Forgot to add: I'm using an Aiptek SlimTablet 600U (Model WCK-C121) and have NOT installed xserver-xorg-input-aiptek but xserver-xorg-input-wacom (the tablet also uses the "wacom" kernel module). The problem seems to be the same though. So it might have nothing to do with the specific input driver.

dmesg when "rmmod wacom" before unplugging:
[88552.356250] usb 1-3.7: new full speed USB device using ehci_hcd and address 8
[88552.457776] usb 1-3.7: configuration #1 chosen from 1 choice
[88552.463935] input: WALTOP International Corp. Slim Tablet as /devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3.7/1-3.7:1.0/input/input13
[88552.496047] generic-usb 0003:172F:0031.0005: input,hidraw4: USB HID v1.10 Mouse [WALTOP International Corp. Slim Tablet] on usb-0000:00:1d.7-3.7/input0
[88554.365260] usbcore: registered new interface driver wacom
[88554.365272] wacom: v1.49:USB Wacom Graphire and Wacom Intuos tablet driver
[88583.409105] usbcore: deregistering interface driver wacom
[88591.062127] usb 1-3.7: USB disconnect, address 8
[88601.443834] Xorg[8402]: segfault at 8 ip b431bd80 sp bfb8dec0 error 4 in wacom_drv.so[b430e000+14000]

dmesg when simply unplugging the tablet:
[89756.380299] usb 1-3.1: new full speed USB device using ehci_hcd and address 9
[89756.536442] usb 1-3.1: configuration #1 chosen from 1 choice
[89756.542949] input: WALTOP International Corp. Slim Tablet as /devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3.1/1-3.1:1.0/input/input14
[89756.581618] generic-usb 0003:172F:0031.0006: input,hidraw4: USB HID v1.10 Mouse [WALTOP International Corp. Slim Tablet] on usb-0000:00:1d.7-3.1/input0
[89756.843587] usbcore: registered new interface driver wacom
[89756.843593] wacom: v1.49:USB Wacom Graphire and Wacom Intuos tablet driver
[89876.688260] Xorg[3947]: segfault at 100001a ip 080d8832 sp bff3e560 error 4 in Xorg[8048000+19d000]

[Jon Nordby (jonnor)]

This seems to me to be a fairly trivial issue to fix. So I am personally adding a 30usd bounty for anyone who fixes this in a good way (needs to go upstream). Preferably with a test-case. If this is not trivial, please say so.

[Peter Hutterer (peter-hutterer)]

Created an attachment (id=28772)
0001-Reset-local-private-to-NULL-after-freeing-it.-22693.patch

Can you test this patch please. Seems to be a bug that affects some other input drivers too.

[Peter Hutterer (peter-hutterer)]

Pushed as 3337f41ca5af021fb7ed8db0efc5e39f04e3d012.

[Zermati Nicolas (nicoolas25)]

It's working with the Peter Hutterer's patch at https://bugs.freedesktop.org/attachment.cgi?id=28772 on 1.2.0 version of input aiptek driver.

Thanks to him.

[Jon Nordby (jonnor)]

I can confirm that this patch solves the issue.

I've experienced one crash upon unplugging, but do not know the reason for this or have been able to reproduce. Will update or file a new bug if this happens again and I can find which component that seems to be at fault.

[coCoKNIght (cocoknight)]

I can confirm this bug happening with Karmic. Tablet: G-Pen 560

[Dorian (ikolpm)]

I confirm this bug in Karmic, with Trust TB-4200.

[HotHello (popperoga)]

same as Dorian, the bug appears in Karmic with Trust 200-v2 (actually, a Aiptek International, Inc. APT-2 Tablet)

[Aaron (armahillo)]

I'm using a Wacom Intuos 3.

The default factory packages did not crash my system, but I had limited functionality. After installing an updated version of the linux-wacom package (directly from the project site), I cannot successfully boot my laptop without either:

a) plugging in the tablet (and unplugging it at any time thereafter crashes the system)
b) commenting out the lines in xorg.conf defining it as an inputdevice.

Curiously -- commenting out the lines still allows me to use the tablet, but only the Stylus & Eraser show up in wacomcpl. To get the Pad to show up, I need to have its line uncommented in the xorg.conf.

[Matthew Todd (matcatprg)]

I confirm this bug in Lucid w/ Adesso 6400 (Aiptek)

[tjal (tjal777)]

I confirm this bug in 10.04 LTS w/ Logitech USB mouse

[Jon Nordby (jonnor)]

traj: What you explain is not the same bug as here, as the device you mention does not make use of the driver which had the problem. Please add your information to the appropriate bug if you find it, or file a new one.

[tjal (tjal777)]

I wonder what my problem/bug is. The problem is exactly like described here, but I'll look further. thx anyway

[Timo Aaltonen (tjaalton)]

I'm confused. The upstream commit is included in version 1.3.0, which is in 10.04 and later. So if you still have crashes, they might be something else and thus deserve a bug of it's own. Closing this one.

[Alexey Spiridonov (snarkmaster)]

The upstream commit clearly does not fix the bug, since I'm still experiencing it on an up-to-date 10.04. Since you wanted a new bug, here it is:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-aiptek/+bug/793338