MySQL Bugs: #48515: Mysqldump hangs with ** DEAD ** processes in the processlist with kernel Oops

Bug #48515	Mysqldump hangs with DEAD processes in the processlist with kernel Oops
Submitted:	3 Nov 2009 20:20	Modified:	14 Jan 2013 18:32
Reporter:	Lisa Williams	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: mysqldump Command-line Client	Severity:	S3 (Non-critical)
Version:	5.0.67, 5.1.40	OS:	Linux (openSUSE 11.1 x86_64)
Assigned to:	Matthew Lord	CPU Architecture:	Any
Tags:	* DEAD *, checking permissions, mysqldump, process hang

Description:
Mysqldump hangs with ** DEAD ** processes in the processlist and concurrently
an Oops is reported in the kernel messages.

We've seen this in relation to mysqldump and other scripts that issue mysql queries SHOW
TABLES LIKE 'xxx' or even 'DROP DATABASE'

I have been able to reproduce this on two different machines.

After this happens I a normal stop/start of mysql fails and I must forcibly restart (kill -9) mysql. 
If I then initiate the mysqldump prior to any other scripts, it usually completes successfully.

We have seen this on both
openSUSE 11.1 (x86_64)
openSUSE 10.3 (X86-64)

with mysql versions:
Server version:         5.0.67 SUSE MySQL RPM
Server version:         5.0.45 SUSE MySQL RPM
Server version:         5.1.40-log Source distribution
However on 5.1 the processlist shows ‘checking permissions’ instead of *** DEAD ***

Following are examples of the ** DEAD ** processes:
| *** DEAD *** | SHOW TRIGGERS LIKE 'stats\_333'
| *** DEAD *** | SHOW TRIGGERS LIKE 'stats\_132'

| 4019 | LogicMonitor | 207.178.145.207:44287 | NULL  | Query   | 7660 | ***
DEAD *** | show table status from logicmonitor

| Query   |  110 | checking permissions | SHOW TRIGGERS LIKE 'atable\_50' |
| Query  |  899 | checking permissions | show table status like 'session'  |

This started happening on 10/27/09
Since then we have since tried different my.cnf settings to optimize our system
and see if we can fix this issue. We have also tried a completely different my.cnf based on one found on a high performance blog for a 64bit machine with 8GB RAM...  same issue.
In the course of changing my.cnf parameters, I tried turning the query cache off - and the only
difference was that it seemed to make the issue happen much faster.

We had not done any upgrades of the system OS or of mysql anytime in the months
prior to this event.

We have since applied system patches and run the DELL hardware diagnostics (all
passes).
We have also replicated the event on another system, with hardware that also
passes all diagnostics.

Here is the output of the kernel Oops:
BUG: unable to handle kernel paging request at 00007f17dc076000
IP: [<ffffffffa00fe5c9>] 0xffffffffa00fe5c9
PGD 217898067 PUD 2149d7067 PMD 1ccbb0067 PTE 0
Oops: 0002 [23] SMP
last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
CPU 0
Modules linked in: nls_utf8 af_packet ipmi_devintf ipmi_si ipmi_msghandler dell_rbu(X) binfmt_misc ipv6 fuse loop dm_mod joydev usbhid hid usb_storage ff_memless bnx2 sr_mod ses cdrom enclosure sg shpchp pci_hotplug iTCO_wdt dcdbas(X) iTCO_vendor_support rtc_cmos button pcspkr serio_raw rtc_core rtc_lib i5000_edac edac_core ehci_hcd uhci_hcd usbcore sd_mod crc_t10dif edd ext3 mbcache jbd fan ide_pci_generic ide_core ata_generic ata_piix libata dock thermal processor thermal_sys hwmon megaraid_sas scsi_mod
Supported: Yes, External
Pid: 8933, comm: mysqld Tainted: G      D   2.6.27.29-0.1-default #1
RIP: 0010:[<ffffffffa00fe5c9>]  [<ffffffffa00fe5c9>] 0xffffffffa00fe5c9
RSP: 0018:ffff88019096be18  EFLAGS: 00010297
RAX: 00007f17dc076000 RBX: 00007f17dc10f8e8 RCX: 0000000000000028
RDX: 00000000000000ec RSI: 0000000000000000 RDI: ffff88022c9691e4
RBP: ffff88019096bf78 R08: ffff88022f1461c0 R09: 0000000000000292
R10: 00190a64c28a4626 R11: ffffffff80220fe6 R12: 000000000ad54c60
R13: 000000000b61ea78 R14: 00007f17dc10ca30 R15: 00007f17dc10ca28
FS:  00007f17dc10f950(0000) GS:ffffffff80a43080(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f17dc076000 CR3: 000000015a946000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mysqld (pid: 8933, threadinfo ffff88019096a000, task ffff880217976700)
Stack:  00000000000005a1 0000000000000ff0 000000000000000f 00000000802afefe
 000000000000000f 0000100000000001 000000000b61ea78 000005a109d12b50
 612f636f72702f2f 0000000061616161 00007f17dc075000 00007f17dc076000
Call Trace:
Inexact backtrace:

 [<ffffffff802b4952>] ? sys_newfstat+0x20/0x29
 [<ffffffff8020bfbb>] system_call_fastpath+0x16/0x1b

Code: 85 08 ff ff ff 48 03 85 f8 fe ff ff 48 89 45 e0 48 89 55 d8 89 4d d4 c7 45 d0 00 00 00 00 eb 1b 48 8b 45 d8 0f b6 10 48 8b 45 e0 <88> 10 48 83 45 e0 01 48 83 45 d8 01 83 45 d0 01 8b 45 d0 3b 45
RIP  [<ffffffffa00fe5c9>] 0xffffffffa00fe5c9
 RSP <ffff88019096be18>
CR2: 00007f17dc076000
---[ end trace 72db581422bc71a6 ]---

Any ideas are appreciated.

How to repeat:
Reproducible: Sometimes

Steps to Reproduce:

I am able to reproduce this issue almost all the time on the production and backup systems system
if I do the following:

1.  run a mysql instensive script (only necessary on a non-production machine) 
2.  run a script that does mysql dumps of each database outputting them to text
files.
3.  watch the processlist in mysql and wait for ** DEAD ** process
4.  check dmesg and look for Oops

Actual Results:
1. the mysqldump script hangs -
2. a ** DEAD ** process is listed in the mysql processlist (under 5.1 it’s “checking permissions”)
3. and Oops is reported in the dmesg output

Expected Results:
1. mysqldump should finish without incident.

my.cnf we used prior to any of this happening

Attachment: my.cnf_after.txt (text/plain), 5.19 KiB.

my.cnf with some changes afterwards - it still occurs

Attachment: my.cnf_after.txt (text/plain), 5.19 KiB.

current my.cnf based on performance model found on web with some edits

Attachment: my.cnf.now (text/plain), 17.73 KiB.

output of show variables

Attachment: mysql_vars.txt (text/plain), 14.94 KiB.

* Hardware this system is running on

PowerEdge 2950 III
Two Dual Core Intel® Xeon® E5205, 6MB Cache, 1.86GHz,1066MHz FSB

8GB 667MHz memory
4 250GB 250GB 7.2K RPM Serial ATA 3Gbps 3.5-in hard drives

reproduced on a machine with similar hardware but machine with only 2GB memory.

I put the wrong info about when this started happening.
It started 9/27/09.

Thank you for the bug report. Are you tried with 5.0.87 released version?. Thanks in advance.

[3 Nov 22:21] Miguel Solorzano

Thank you for the bug report. Are you tried with 5.0.87 released
version?. Thanks in advance.

Answer - No - I haven't - but I did try with 5.1.40
5.1.40-log Source distribution

I would be nice to know if recent versions, 5.0.88 and/or 5.1.41, are affected.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I am experiencing the same problem. I have seen this error occurring while using phpmyadmin on php/apache. The page would take a long time to load, when checking "SHOW PROCESSLIST" from a shell it first showed:

 191381 | root        | localhost | gebruiker     | Query          |   35 | checking permissions | SELECT *,
                    `TABLE_SCHEMA`       AS `Db`,
                    `TABLE_NAME`         |

This changed to the following a few seconds later:
| 191381 | root        | localhost | gebruiker     | Query          |   38 | *** DEAD ***       | SELECT *,
                    `TABLE_SCHEMA`       AS `Db`,
                    `TABLE_NAME`         |

Shutting mysqld down in the traditional way doesnt work. I had to "kill -9" it after getting this error.
I have also repeatedly experienced this error using a tcl/mysqltcl script, the error occured after running the query "SHOW DATABASES;"

In my search to solve this error I compiled mysql-5.1.40 from tar.gz. On this mysqld version the status wouldn't change to *** DEAD ***, the process would just hang forever.

Processor: AMD Athlon(tm) 64 X2 Dual Core Processor 3600+
OS: Ubuntu 8.04 LTS 32bits

Other steps I took in an attempt to solve the problem:
- Rebooted OS
- myisamchk'd all tables in all databases
- mysqldumped all tables and recreated them from scratch
- mv /var/lib/mysql /var/lib/mysql_old; /usr/bin/mysql_install_db; #and then imported the mysql dumps for the other db's to newly created db's

Additional note: I have -not- been using mysqldump at all before running the "show databases;" query or before using phpmyadmin.

Additional note (sorry): The mysql installation from ubuntu repository on which I also receive this error on is: 5.0.51a-3ubuntu5.4-log

my.cnf

Attachment: my.cnf.txt (text/plain), 3.92 KiB.

Thank you for the feedback.

Could you please run SHOW FULL PROCESSLIST to see full query what hangs, then run SELECT COUNT(*) FROM the table affected?

I'd rather avoid making this happen again as it's a production server. It's quite simple to not make it happen, just don't use phpMyAdmin and let things be. If it is crucial information in order to solve this bug I am however willing to try and recreate the error to give you the information needed, at a 'quiet' time (night).

I can however tell you this error also occurred with the quite simple query "SHOW DATABASES;" that showed up in the processlist after running the "mysql::info $handle databases" command (mysqltcl library), that one would get the *** DEAD *** message next to it in "show processlist". 
One of my scripts used to run that query over and over again from many different threads for a purpose the PING query should've been used instead; checking if the server connection was still up.
Then at a seemingly random day the encountered error started popping up. I hadn't changed anything to the scripts in weeks, and the "SHOW DATABASES;" bit had been in there for years. I then changed to the mysql::ping method and the problem disappeared. (But still occurs when using phpMyAdmin) 

Maybe I can run the COUNT query on whichever table "SHOW DATABASES;" consults? You'd have to tell me which table that is.

Update:
I have managed to recreate the error on mysqld 5.1.40-log running on the same server from a normal user account. (I copied the datadir /var/lib/mysql and started a second mysqld on the same box with different paths in my.cnf)

I then spawned multiple clients repeatedly running the query "SHOW DATABASES;" from a simple shell script. At first this would immediately return a list of databases. After letting it run for a while, I noticed the first script hanging.

Mind that as this is 5.1.40-log it doesn't show *** DEAD *** in the processlist, it just keeps running the query forever. 

mysql> show full processlist;
+------+------+-----------+--------+---------+------+-----------+-----------------------+
| Id   | User | Host      | db     | Command | Time | State     | Info                  |
+------+------+-----------+--------+---------+------+-----------+-----------------------+
| 1350 | root | localhost | db2 | Query   |  996 | executing | SHOW DATABASES        |
| 3454 | root | localhost | db2 | Query   |  279 | executing | SHOW DATABASES        |
| 3540 | root | localhost | db2 | Query   |    0 | NULL      | show full processlist |
+------+------+-----------+--------+---------+------+-----------+-----------------------+

Thank you for the feedback.

Yes, SELECT COUNT(*) FROM INFORMATION_SCHEMA.SCHEMATA; should be good in this case.

Some more info I forgot to mention:
If for instance phpMyadmin got stuck, this would not just affect the phpMyadmin client, but also other clients. Those other client's wouldn't get *** DEAD *** next to their queries in processlist, as far as I can remember their SELECT queries just returned results, but not the right results they would get with normal behavior. 
(I'm running a mysql myisam database to which rows get inserted, clients then usually fetch the latest added rows. The biggest table currently has about 4 million rows in it)

I can't really get into detail about what did, and what didnt work when there was a dead client in the processlist. I was always in too big of a hurry to get things going again.

mysql> SELECT COUNT(*) FROM INFORMATION_SCHEMA.SCHEMATA;
+----------+
| COUNT(*) |
+----------+
|        9 | 
+----------+
1 row in set (0.00 sec)

Jasper,

thank you for the feedback. Could you please run shell test script with version 5.1.43? I can not repeat described behavior with current development sources.

I have succesfully recreated this error on mysqld-5.1.43.
These are the steps I took (slightly modded):

Downloaded:
Generic Linux (Architecture Independent), Compressed TAR Archive 5.1.43
(mysql-5.1.43.tar.gz)

### Installation
$ cd ~/downloads
$ wget http://dev.mysql.com/get/Downloads/MySQL-5.1/mysql-5.1.43.tar.gz/from/http://mirror.leasew...
$ tar -xzf *gz
$ cd *43
$ ./configure --prefix=/home/foo/mysqld-5.1.43 --with-tcp-port=3600 --with-named-curses-libs=/lib/libncurses.so.5.6
$ make
$ make install

### Configuration
$ cd /home/foo/mysqld-5.1.43/
$ mkdir etc && mkdir data-dir && mkdir var
$ cp ~/my.cnf ./etc/
# I will post this my.cnf as attachment below
$ cd bin
$ ./mysql_install_db --defaults-file=/home/foo/mysqld-5.1.43/etc/my.cnf
# So I have been using a *fresh* database without adding any other databases myself!
$ cd ..
$ ./bin/mysqld_safe --defaults-file=/home/foo/mysqld-5.1.43/etc/my.cnf &

Created file cmd.sh:

#!/bin/bash
echo "SHOW DATABASES;" | /home/foo/mysqld-5.1.43/bin/mysql --defaults-file=/home/foo/mysqld-5.1.43/etc/my.cnf -u root
#EOF

Created run.sh file:

#!/bin/bash
screen -dmS s01 watch --interval=1 sh cmd.sh
screen -dmS s02 watch --interval=1 sh cmd.sh
screen -dmS s03 watch --interval=1 sh cmd.sh
screen -dmS s04 watch --interval=1 sh cmd.sh
screen -dmS s05 watch --interval=1 sh cmd.sh
screen -dmS s06 watch --interval=1 sh cmd.sh
screen -dmS s07 watch --interval=1 sh cmd.sh
screen -dmS s08 watch --interval=1 sh cmd.sh
screen -dmS s09 watch --interval=1 sh cmd.sh
screen -dmS s10 watch --interval=1 sh cmd.sh
#EOF

$ ./run.sh

Waited a while:
$ echo "show processlist;" | /home/foo/mysqld-5.1.43/bin/mysql --defaults-file=/home/foo/mysqld-5.1.43/etc/my.cnf -u root
Id      User    Host    db      Command Time    State   Info
4       root    localhost       NULL    Query   366     executing       SHOW DATABASES
10      root    localhost       NULL    Query   366     executing       SHOW DATABASES
11      root    localhost       NULL    Query   366     executing       SHOW DATABASES
58      root    localhost       NULL    Query   359     executing       SHOW DATABASES
59      root    localhost       NULL    Query   359     executing       SHOW DATABASES
163     root    localhost       NULL    Query   337     executing       SHOW DATABASES
231     root    localhost       NULL    Query   322     executing       SHOW DATABASES
309     root    localhost       NULL    Query   299     executing       SHOW DATABASES
620     root    localhost       NULL    Query   0       NULL    show processlist

^ processes hanging

my.cnf used on error recreation on mysqld-5.1.43

Attachment: my.cnf.txt (text/plain), 4.40 KiB.

Output from "SHOW VARIABLES;" while threads are stuck.

Attachment: variables.txt (text/plain), 5.47 KiB.

Jasper,

thank you for the feedback.

I still can not repeat described behavior. Could you please try if this is repeatable if you compile without option --with-named-cources-lib and if it is still repeatable attach gdb to the running process and issue command `thread apply all bt` it time when it hangs

I have recompiled it without the ncurses option and I can confirm the error still occurs.

$ gdb /home/foo/mysqld-5.1.43/libexec/mysqld 26273
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Attaching to program: /home/foo/mysqld-5.1.43/libexec/mysqld, process 26273
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 0xb7c4e8d0 (LWP 26273)]
[New Thread 0xa5c9db90 (LWP 26273)]
[New Thread 0xa5cceb90 (LWP 26273)]
[New Thread 0xa5cffb90 (LWP 26448)]
[New Thread 0xa6358b90 (LWP 26273)]
[New Thread 0xa6389b90 (LWP 26446)]
[New Thread 0xa63bab90 (LWP 26443)]
[New Thread 0xa63ebb90 (LWP 26273)]
[New Thread 0xa641cb90 (LWP 26273)]
[New Thread 0xa644db90 (LWP 26275)]
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/tls/i686/cmov/libm.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xb7f47410 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 10 (Thread 0xa644db90 (LWP 26275)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7f33b1a in do_sigwait () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7f33bbf in sigwait () from /lib/tls/i686/cmov/libpthread.so.0
#3  0x081cc4fc in signal_hand ()
#4  0xb7f2b4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5  0xb7d25e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 9 (Thread 0xa641cb90 (LWP 26273)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7d1e881 in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x081d1190 in handle_connections_sockets ()
#3  0x081d1ef3 in main ()

Thread 8 (Thread 0xa63ebb90 (LWP 26273)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7d1e881 in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x081d1190 in handle_connections_sockets ()
#3  0x081d1ef3 in main ()

Thread 7 (Thread 0xa63bab90 (LWP 26443)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7f2faa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x081cc83d in one_thread_per_connection_end ()
#3  0x081d5cf0 in handle_one_connection ()
#4  0xb7f2b4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5  0xb7d25e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 6 (Thread 0xa6389b90 (LWP 26446)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7f2faa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x081cc83d in one_thread_per_connection_end ()
#3  0x081d5cf0 in handle_one_connection ()
#4  0xb7f2b4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5  0xb7d25e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 5 (Thread 0xa6358b90 (LWP 26273)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7d1e881 in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x081d1190 in handle_connections_sockets ()
#3  0x081d1ef3 in main ()

Thread 4 (Thread 0xa5cffb90 (LWP 26448)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7f2faa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0x081cc83d in one_thread_per_connection_end ()
#3  0x081d5cf0 in handle_one_connection ()
#4  0xb7f2b4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5  0xb7d25e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 3 (Thread 0xa5cceb90 (LWP 26273)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7d1e881 in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x081d1190 in handle_connections_sockets ()
#3  0x081d1ef3 in main ()

Thread 2 (Thread 0xa5c9db90 (LWP 26273)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7d1e881 in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x081d1190 in handle_connections_sockets ()
#3  0x081d1ef3 in main ()

Thread 1 (Thread 0xb7c4e8d0 (LWP 26273)):
#0  0xb7f47410 in __kernel_vsyscall ()
#1  0xb7d1e881 in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x081d1190 in handle_connections_sockets ()
#3  0x081d1ef3 in main ()
#0  0xb7f47410 in __kernel_vsyscall ()

Additional note: At the time of the gdb commands pasted above there were no active mysql client connections. I first killed the mysql clients and then issued the gdb commands.

Sveta,

Did I issue the gdb commands correctly? Is there anything else I can do to help fixing this issue?

Jasper,

yes, you issue commands correctly. Probably would be good if you attach gdb to client process, then see what happens in client.

Also this can be duplicate of bug #52528 with repeatable test case, but we can not be sure until that bug is fixed and you check in your environment.

Dear Sveta,
I have attached gdb to a hanging mysql client, the result:

$ gdb /home/foo/mysqld-5.1.43/bin/mysql 6722
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Attaching to program: /home/foo/mysqld-5.1.43/bin/mysql, process 6722
Reading symbols from /lib/libncurses.so.5...done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 0xb7c456c0 (LWP 6722)]
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /home/foo/mysqld-5.1.43/lib/mysql/libmysqlclient.so.16...done.
Loaded symbols for /home/foo/mysqld-5.1.43/lib/mysql/libmysqlclient.so.16
Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/tls/i686/cmov/libm.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0xb7fdf410 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 1 (Thread 0xb7c456c0 (LWP 6722)):
#0  0xb7fdf410 in __kernel_vsyscall ()
#1  0xb7f9a973 in __read_nocancel () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7f57c38 in vio_read () from /home/foo/mysqld-5.1.43/lib/mysql/libmysqlclient.so.16
#3  0xb7f57c8b in vio_read_buff () from /home/foo/mysqld-5.1.43/lib/mysql/libmysqlclient.so.16
#4  0xb7f5873f in my_real_read () from /home/foo/mysqld-5.1.43/lib/mysql/libmysqlclient.so.16
#5  0xb7f58a36 in my_net_read () from /home/foo/mysqld-5.1.43/lib/mysql/libmysqlclient.so.16
#6  0xb7f52598 in cli_safe_read () from /home/foo/mysqld-5.1.43/lib/mysql/libmysqlclient.so.16
#7  0xb7f54b45 in cli_read_query_result () from /home/foo/mysqld-5.1.43/lib/mysql/libmysqlclient.so.16
#8  0xb7f51b94 in mysql_real_query () from /home/foo/mysqld-5.1.43/lib/mysql/libmysqlclient.so.16
#9  0x080558c3 in mysql_real_query_for_lazy ()
#10 0x08057b0d in com_go ()
#11 0x08059709 in read_and_execute ()
#12 0x0805a745 in main ()
#0  0xb7fdf410 in __kernel_vsyscall ()
(gdb)

Jasper,

thank you for the update. Still looks similar to bug #52528. I suggest to wait when it is fixed.

I am unable to repeat the issue using 5.5.29-Enterprise on Ubuntu 12.10 x86_64.

I need a clear test case in order to try something else.