Comment 11 for bug 355021

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.