Bug #28210 MySQL 5.0.37 & 5.0.40 hangs, 5.0.27 works perfectly
Submitted: 2 May 2007 23:57 Modified: 14 Jun 2007 15:34
Reporter: jocelyn fournier (Silver Quality Contributor) Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S2 (Serious)
Version:5.0.37, 5.0.40 OS:Linux (Debian Sarge)
Assigned to: CPU Architecture:Any
Tags: qc, regression

[2 May 2007 23:57] jocelyn fournier
Description:
Hi,

Following the discussion initiated here :

http://lists.mysql.com/internals/34599

, here is the stack trace associated with the some stuck processes :

(gdb) where
#0  0x4003a604 in __pthread_sigsuspend () from /lib/libpthread.so.0
#1  0x4003a3c8 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0
#2  0x4003ba6b in __pthread_lock () from /lib/libpthread.so.0
#3  0x40038b5d in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x081e8c51 in open_table ()
#5  0x081e9e6b in open_tables ()
#6  0x081ea32e in open_and_lock_tables ()
#7  0x081c9b8f in mysql_execute_command ()
#8  0x081cf00e in mysql_parse ()
#9  0x081c6e3c in dispatch_command ()
#10 0x081c6922 in do_command ()
#11 0x081c5f8e in handle_one_connection ()
#12 0x40037e51 in pthread_start_thread () from /lib/libpthread.so.0
#13 0x401bf8aa in clone () from /lib/libc.so.6

(gdb) where
#0  0x4003a604 in __pthread_sigsuspend () from /lib/libpthread.so.0
#1  0x4003a3c8 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0
#2  0x4003bd99 in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x40038ba5 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x401590fd in free () from /lib/libc.so.6
#5  0x0843c6f9 in delete_dynamic ()
#6  0x081a618d in THD::cleanup ()
#7  0x081b2e1e in end_thread ()
#8  0x081c5e26 in handle_one_connection ()
#9  0x40037e51 in pthread_start_thread () from /lib/libpthread.so.0
#10 0x40037ecf in pthread_start_thread_event () from /lib/libpthread.so.0
#11 0x401bf8aa in clone () from /lib/libc.so.6

(gdb) where
#0  0x4003a604 in __pthread_sigsuspend () from /lib/libpthread.so.0
#1  0x4003a3c8 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0
#2  0x4003ba6b in __pthread_lock () from /lib/libpthread.so.0
#3  0x40038b5d in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x081c58ac in check_user ()
#5  0x081d1e6f in check_connection ()
#6  0x081c5de3 in handle_one_connection ()
#7  0x40037e51 in pthread_start_thread () from /lib/libpthread.so.0
#8  0x40037ecf in pthread_start_thread_event () from /lib/libpthread.so.0
#9  0x401bf8aa in clone () from /lib/libc.so.6

Used my.cnf :

[mysqld]
skip-locking
#skip-networking
skip-name-resolve
skip-bdb
skip-log-warnings
ft_stopword_file=/dev/null
delay-key-write=OFF
skip-innodb
user                    = mysql
port                    = 3306
socket                  = /home/mysql/mysql.sock
datadir                 = /home/mysql/data
log-error               = /home/mysql/log/mysql.err
ft_min_word_len         = 1
max_allowed_packet      = 16M
key_buffer_size         = 512M
table_cache             = 1024
read_buffer_size        = 512K
read_rnd_buffer_size    = 512K
back_log                = 300
thread_cache_size       = 20
query_cache_limit       = 1M
query_cache_size        = 16M
delayed_insert_limit    = 80
max_delayed_threads     = 20
join_buffer_size        = 32M
sort_buffer_size        = 1M
delayed_insert_timeout  = 20
wait_timeout            = 150
max_connections         = 200
myisam_sort_buffer_size = 512M
thread_concurrency      = 4

The system is a linux 32 bit box on a debian sarge distrib, with a 2.4.27-3-686-smp kernel and a 2.3.2 glibc.

The issue only occurs with 5.0.37 & 5.0.40 (non RPM packages) glibc 2.3 build, 5.0.27 glibc 2.3 build works perfectly.
However, I've just tested 5.0.37 (x86, glibc-2.2, "standard" is static), and it seems to works perfectly as well.

Is there any change in the build process / systems for 5.0.37/5.0.40, especially glibc related ?

Regards,
  Jocelyn

How to repeat:
Launch MySQL 5.0.37 build against glibc 2.3 on a debian sarge system and wait.
[3 May 2007 1:06] jocelyn fournier
Hi,

I've just compiled a 5.0.37 build (using my system with debian sarge & glibc 2.3.2) based on 5.0.37 src, and it also works perfectly, so it definitly seems to be a build issue here.

Thanks,
  Jocelyn
[3 May 2007 9:41] Valeriy Kravchuk
Thank you for a problem report. What exact configure command line you had used to get successfull build?

Please, take a look at bug #24507 (and http://bugs.mysql.com/bug.php?id=27970) for some (possibly related) recent changes in NPTL usage, and their results...
[3 May 2007 10:36] jocelyn fournier
Hi,

My server doesn't use NPTL, just linuxthreads :

getconf GNU_LIBPTHREAD_VERSION                                                                                                                                                                          
linuxthreads-0.10

uname -a                                                                                                                                                                                                
Linux xxx 2.4.27-3-686-smp #1 SMP Tue Dec 5 23:12:28 UTC 2006 i686 GNU/Linux

To get a successfull build :

./BUILD/compile-pentium

Thanks,
  Jocelyn
[3 May 2007 17:53] Valeriy Kravchuk
What exact binaries failed (give URLs/file names)? I want ot check if they were icc-compiled...
[3 May 2007 17:57] jocelyn fournier
Hi,

Both icc-compiled and standard one fail the same way.

(I've tested :

http://dev.mysql.com/get/Downloads/MySQL-5.0/mysql-5.0.37-linux-i686-glibc23.tar.gz/from/p...
http://dev.mysql.com/get/Downloads/MySQL-5.0/mysql-5.0.37-linux-i686-icc-glibc23.tar.gz/fr...

+ mysql-enterprise-gpl-5.0.40-linux-i686-icc-glibc23.tar.gz

with the same result).

http://dev.mysql.com/get/Downloads/MySQL-5.0/mysql-5.0.37-linux-i686.tar.gz/from/pick

and manually built from

http://dev.mysql.com/get/Downloads/MySQL-5.0/mysql-5.0.37.tar.gz/from/pick

work just fine.

  Jocelyn
[29 May 2007 15:39] James Green
For the sake of clarity, could this be a duplicate of bug #27168 by any chance?
[4 Jun 2007 20:05] Magnus BlÄudd
See BUG#28690
[14 Jun 2007 15:34] Valeriy Kravchuk
Looks like a duplicate of bug #28690.