Bug #27773 | server crash | ||
---|---|---|---|
Submitted: | 12 Apr 2007 2:06 | Modified: | 29 Mar 2011 18:53 |
Reporter: | Roberto Spadim (Basic Quality Contributor) | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server | Severity: | S1 (Critical) |
Version: | 5.1.16 | OS: | Linux (64bits don't work, 32bits is ok) |
Assigned to: | CPU Architecture: | Any | |
Tags: | qc, regression, server crash |
[12 Apr 2007 2:06]
Roberto Spadim
[12 Apr 2007 11:10]
Roberto Spadim
the same error occurred today with mysql 5.0.31 64 bits: 070412 07:56:05 mysqld started 070412 7:56:05 [ERROR] Can't open shared library 'mysql-udf-base64.so' (errno: 0 mysql-udf-base64.so: cannot open shared object file:$ 070412 7:56:05 [ERROR] Can't open shared library 'mysql-udf-base64.so' (errno: 0 mysql-udf-base64.so: cannot open shared object file:$ 070412 7:56:05 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.37-log' socket: '/tmp/mysql.prod.sock' port: 3307 MySQL Community Server (GPL) mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=10485760 read_buffer_size=2093056 max_used_connections=11 max_connections=50 threads_connected=9 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 214839 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x2aaaac09e700 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x40b8e078, backtrace may not be correct. Stack range sanity check OK, backtrace follows: (nil) Stack trace seems successful - bottom reached Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolv$ stack trace is much more helpful in diagnosing the problem, so please do resolve it Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0xd39b20 = (SELECT 'cc' AS tipo,evento_id,devedor_tipo,devedor_id,credor_tipo,credor_id,hash_origem,origem_tipo,data_ent$ SELECT 'cc' AS tipo,evento_id,devedor_tipo,devedor_id,credor_tipo,credor_id,hash_origem,origem_tipo,data_entrada_gmt,data_emissao_face$ thd->thread_id=41 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0
[12 Apr 2007 13:42]
Roberto Spadim
now information was output to stdout! *** glibc detected *** /usr/sbin/mysqld: double free or corruption (!prev) : 0x0000000000e30b90 *** ======= Backtrace: ========= /lib/libc.so.6[0x2ab16eccbf3d] /lib/libc.so.6(__libc_free+0x76)[0x2ab16eccd576] /usr/sbin/mysqld(hp_free_level+0x79)[0x80aa59] /usr/sbin/mysqld(hp_clear+0x15)[0x80a735] /usr/sbin/mysqld(hp_free+0x26)[0x809a06] /usr/sbin/mysqld(heap_delete_table+0x6b)[0x809aab] /usr/sbin/mysqld(_ZN7ha_heap12delete_tableEPKc+0x25)[0x5fe335] /usr/sbin/mysqld(_Z14free_tmp_tableP3THDP8st_table+0x132)[0x595fa2] /usr/sbin/mysqld(_ZN18st_select_lex_unit7cleanupEv+0x52)[0x641092] /usr/sbin/mysqld(_Z11mysql_unionP3THDP6st_lexP13select_resultP18st_select_lex_unitm+0x40)[0x642e70] /usr/sbin/mysqld(_Z13handle_selectP3THDP6st_lexP13select_resultm+0x55)[0x5af325] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x4bd)[0x5613cd] /usr/sbin/mysqld(_Z11mysql_parseP3THDPcj+0x201)[0x566251] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x41d)[0x5666dd] /usr/sbin/mysqld(_Z10do_commandP3THD+0xb6)[0x5678a6] /usr/sbin/mysqld(handle_one_connection+0x910)[0x568300] /lib/libpthread.so.0[0x2ab16e4770e5] /lib/libc.so.6(__clone+0x6d)[0x2ab16ed1d8cd] ======= Memory map: ======== 00400000-00a53000 r-xp 00000000 08:03 4248294 /usr/sbin/mysqld 00b53000-00bac000 rw-p 00653000 08:03 4248294 /usr/sbin/mysqld 00bac000-00e6b000 rw-p 00bac000 00:00 0 [heap] 40000000-40001000 ---p 40000000 00:00 0 40001000-40041000 rwxp 40001000 00:00 0 40041000-40042000 ---p 40041000 00:00 0 40042000-40082000 rwxp 40042000 00:00 0 40082000-40083000 ---p 40082000 00:00 0 40083000-400c3000 rwxp 40083000 00:00 0 2aaaac000000-2aaaac021000 rw-p 2aaaac000000 00:00 0 2aaaac021000-2aaab0000000 ---p 2aaaac021000 00:00 0 2ab16db6b000-2ab16db85000 r-xp 00000000 08:03 37750207 /lib/ld-2.5.so 2ab16db85000-2ab16db86000 rw-p 2ab16db85000 00:00 0 2ab16dc84000-2ab16dc85000 r--p 00019000 08:03 37750207 /lib/ld-2.5.so 2ab16dc85000-2ab16dc86000 rw-p 0001a000 08:03 37750207 /lib/ld-2.5.so 2ab16dc86000-2ab16dc8e000 r-xp 00000000 08:03 37750189 /lib/librt-2.5.so 2ab16dc8e000-2ab16dd8d000 ---p 00008000 08:03 37750189 /lib/librt-2.5.so 2ab16dd8d000-2ab16dd8f000 rw-p 00007000 08:03 37750189 /lib/librt-2.5.so 2ab16dd8f000-2ab16dd90000 rw-p 2ab16dd8f000 00:00 0 2ab16dd90000-2ab16dda4000 r-xp 00000000 08:03 54557386 /usr/lib/libz.so.1.2.3 2ab16dda4000-2ab16dea4000 ---p 00014000 08:03 54557386 /usr/lib/libz.so.1.2.3 2ab16dea4000-2ab16dea5000 rw-p 00014000 08:03 54557386 /usr/lib/libz.so.1.2.3 2ab16dea5000-2ab16deac000 r-xp 00000000 08:03 54752834 /usr/lib/libwrap.so.0.7.6 2ab16deac000-2ab16dfab000 ---p 00007000 08:03 54752834 /usr/lib/libwrap.so.0.7.6 2ab16dfab000-2ab16dfad000 rw-p 00006000 08:03 54752834 /usr/lib/libwrap.so.0.7.6 2ab16dfad000-2ab16dfaf000 r-xp 00000000 08:03 37750191 /lib/libdl-2.5.so 2ab16dfaf000-2ab16e0af000 ---p 00002000 08:03 37750191 /lib/libdl-2.5.so 2ab16e0af000-2ab16e0b1000 rw-p 00002000 08:03 37750191 /lib/libdl-2.5.so 2ab16e0b1000-2ab16e0b2000 rw-p 2ab16e0b1000 00:00 0 2ab16e0b2000-2ab16e0f4000 r-xp 00000000 08:03 54676688 /usr/lib/libssl.so.0.9.8 2ab16e0f4000-2ab16e1f4000 ---p 00042000 08:03 54676688 /usr/lib/libssl.so.0.9.8 2ab16e1f4000-2ab16e1fa000 rw-p 00042000 08:03 54676688 /usr/lib/libssl.so.0.9.8 2ab16e1fa000-2ab16e34b000 r-xp 00000000 08:03 54676691 /usr/lib/libcrypto.so.0.9.8 2ab16e34b000-2ab16e44b000 ---p 00151000 08:03 54676691 /usr/lib/libcrypto.so.0.9.8 2ab16e44b000-2ab16e46e000 rw-p 00151000 08:03 54676691 /usr/lib/libcrypto.so.0.9.8 2ab16e46e000-2ab16e471000 rw-p 2ab16e46e000 00:00 0 2ab16e471000-2ab16e486000 r-xp 00000000 08:03 37750190 /lib/libpthread-2.5.so 2ab16e486000-2ab16e585000 ---p 00015000 08:03 37750190 /lib/libpthread-2.5.so 2ab16e585000-2ab16e587000 rw-p 00014000 08:03 37750190 /lib/libpthread-2.5.so 2ab16e587000-2ab16e58c000 rw-p 2ab16e587000 00:00 0 2ab16e58c000-2ab16e591000 r-xp 00000000 08:03 37750202 /lib/libcrypt-2.5.so 2ab16e591000-2ab16e690000 ---p 00005000 08:03 37750202 /lib/libcrypt-2.5.so 2ab16e690000-2ab16e692000 rw-p 00004000 08:03 37750202 /lib/libcrypt-2.5.so 2ab16e692000-2ab16e6c0000 rw-p 2ab16e692000 00:00 0 2ab16e6c0000-2ab16e6d3000 r-xp 00000000 08:03 37750205 /lib/libnsl-2.5.so 2ab16e6d3000-2ab16e7d2000 ---p 00013000 08:03 37750205 /lib/libnsl-2.5.so 2ab16e7d2000-2ab16e7d4000 rw-p 00012000 08:03 37750205 /lib/libnsl-2.5.so 2ab16e7d4000-2ab16e7d6000 rw-p 2ab16e7d4000 00:00 0 2ab16e7d6000-2ab16e8b9000 r-xp 00000000 08:03 54527850 /usr/lib/libstdc++.so.6.0.8 2ab16e8b9000-2ab16e9b9000 ---p 000e3000 08:03 54527850 /usr/lib/libstdc++.so.6.0.8 2ab16e9b9000-2ab16e9bf000 r--p 000e3000 08:03 54527850 /usr/lib/libstdc++.so.6.0.8 2ab16e9bf000-2ab16e9c2000 rw-p 000e9000 08:03 54527850 /usr/lib/libstdc++.so.6.0.8 2ab16e9c2000-2ab16e9d5000 rw-p 2ab16e9c2000 00:00 0 2ab16e9d5000-2ab16ea54000 r-xp 00000000 08:03 37750244 /lib/libm-2.5.so 2ab16ea54000-2ab16eb53000 ---p 0007f000 08:03 37750244 /lib/libm-2.5.so 2ab16eb53000-2ab16eb55000 rw-p 0007e000 08:03 37750244 /lib/libm-2.5.so 2ab16eb55000-2ab16eb62000 r-xp 00000000 08:03 54527842 /usr/lib/libgcc_s.so.1 2ab16eb62000-2ab16ec61000 ---p 0000d000 08:03 54527842 /usr/lib/libgcc_s.so.1 2ab16ec61000-2ab16ec62000 rw-p 0000c000 08:03 54527842 /usr/lib/libgcc_s.so.1 2ab16ec62000-2ab16ed90000 r-xp 00000000 08:03 37750245 /lib/libc-2.5.so 2ab16ed90000-2ab16ee90000 ---p 0012e000 08:03 37750245 /lib/libc-2.5.so 2ab16ee90000-2ab16ee93000 r--p 0012e000 08:03 37750245 /lib/libc-2.5.so 2ab16ee93000-2ab16ee95000 rw-p 00131000 08:03 37750245 /lib/libc-2.5.so 2ab16ee95000-2ab16ee9d000 rw-p 2ab16ee95000 00:00 0 2ab16ee9d000-2ab16eea7000 r-xp 00000000 08:03 37750247 /lib/libnss_files-2.5.so 2ab16eea7000-2ab16efa6000 ---p 0000a000 08:03 37750247 /lib/libnss_files-2.5.so 2ab16efa6000-2ab16efa8000 rw-p 00009000 08:03 37750247 /lib/libnss_files-2.5.so 2ab16efa8000-2ab171884000 rw-p 2ab16efa8000 00:00 0 7fff3cf29000-7fff3cf3d000 rwxp 7fff3cf29000 00:00 0 [stack] 7fff3cf3d000-7fff3cf3f000 rw-p 7fff3cf3d000 00:00 0 ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vdso]
[12 Apr 2007 13:47]
Roberto Spadim
using innodb don't crash i didn't tested my app on innodb, since i don't use transactions could i have problems changing to innodb? i don't do lock tables too, just delete,insert,update,select, select subquery,select union,select from (select)
[12 Apr 2007 14:43]
Roberto Spadim
my linux distro: archlinux 0.8 [root@kassel_srv1 other]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping : 6 cpu MHz : 1862.042 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 3727.04 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping : 6 cpu MHz : 1862.042 cache size : 2048 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 3724.28 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
[12 Apr 2007 17:27]
Valeriy Kravchuk
Please, send the results of: getconf GNU_LIBC_VERSION getconf GNU_LIBPTHREAD_VERSION from your system(s) affected by this problem.
[12 Apr 2007 20:57]
Roberto Spadim
[root@kassel_srv1 ~]# getconf GNU_LIBC_VERSION glibc 2.5 [root@kassel_srv1 ~]# getconf GNU_LIBPTHREAD_VERSION NPTL 2.5
[12 Apr 2007 21:04]
Roberto Spadim
i changed (lote_unidade,lote_tipo,lote_data,lote_numero)=(12,'r','2007-04-11',12) to: lote_unidade=12 and lote_tipo='r' and lote_data='2007-04-11' AND lote_numero=12 and (SELECT devedor_tipo FROM mov_contacorrente WHERE cc_hash_key=a.cc_hash_key) AS devedor_tipo to 'f' AS devedor_tipo and the subquerie value i get after from php aplication now the server don't crash more, i'm using now myisam since innodb worked too i think that's a problem in (many fields)=(many values) but i don't understand why 32bits don't crash since it's the same source (i didn't checked) ok i'm happy that i have an work around to work, but the bug is open.. :/
[20 Apr 2007 10:08]
Valeriy Kravchuk
Please, send EXPLAIN results for original (crashing) and modified queries.
[8 Jul 2007 15:38]
Valeriy Kravchuk
Please, try to repeat with a newer version, 5.1.20, and inform about the results.
[8 Aug 2007 23:00]
Bugs System
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".
[13 Aug 2007 9:58]
Sveta Smirnova
Thank you for the feedback. Please try with version 5.1.20 as Valeriy requested and if you can repeat error upload to our FTP server tables which participate in the query.
[13 Sep 2007 23:00]
Bugs System
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".
[28 Oct 2008 6:06]
Valeriy Kravchuk
Is this repeatable with 5.1.29?
[29 Nov 2008 0:00]
Bugs System
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".
[29 Mar 2011 18:53]
Roberto Spadim
not a problem in 5.5