We encoutered the crash with an unusually complicated stored procedure we restored from a mysql dump (works on mysql 5.5.40-0+wheezy1).
We trimmed it down to the attached test case:
On a clean install, as root, create database, use database, load dump, call procedure as:
"CALL SP1(1);"
The server will crash on the first to third call (usually first).
syslog content:
Oct 30 15:26:18 mariadblab mysqld: 141030 15:26:18 [ERROR] mysqld got signal 11 ;
|
Oct 30 15:26:18 mariadblab mysqld: This could be because you hit a bug. It is also possible that this binary
|
Oct 30 15:26:18 mariadblab mysqld: or one of the libraries it was linked against is corrupt, improperly built,
|
Oct 30 15:26:18 mariadblab mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.
|
Oct 30 15:26:18 mariadblab mysqld:
|
Oct 30 15:26:18 mariadblab mysqld: To report this bug, see http://kb.askmonty.org/en/reporting-bugs
|
Oct 30 15:26:18 mariadblab mysqld:
|
Oct 30 15:26:18 mariadblab mysqld: We will try our best to scrape up some info that will hopefully help
|
Oct 30 15:26:18 mariadblab mysqld: diagnose the problem, but since we have already crashed,
|
Oct 30 15:26:18 mariadblab mysqld: something is definitely wrong and this may fail.
|
Oct 30 15:26:18 mariadblab mysqld:
|
Oct 30 15:26:18 mariadblab mysqld: Server version: 10.0.14-MariaDB-1~wheezy-log
|
Oct 30 15:26:18 mariadblab mysqld: key_buffer_size=134217728
|
Oct 30 15:26:18 mariadblab mysqld: read_buffer_size=2097152
|
Oct 30 15:26:18 mariadblab mysqld: max_used_connections=1
|
Oct 30 15:26:18 mariadblab mysqld: max_threads=102
|
Oct 30 15:26:18 mariadblab mysqld: thread_count=1
|
Oct 30 15:26:18 mariadblab mysqld: It is possible that mysqld could use up to
|
Oct 30 15:26:18 mariadblab mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 759123 K bytes of memory
|
Oct 30 15:26:18 mariadblab mysqld: Hope that's ok; if not, decrease some variables in the equation.
|
Oct 30 15:26:18 mariadblab mysqld:
|
Oct 30 15:26:18 mariadblab mysqld: Thread pointer: 0x0x824da008
|
Oct 30 15:26:18 mariadblab mysqld: Attempting backtrace. You can use the following information to find out
|
Oct 30 15:26:18 mariadblab mysqld: where mysqld died. If you see no messages after this, something went
|
Oct 30 15:26:18 mariadblab mysqld: terribly wrong...
|
Oct 30 15:26:18 mariadblab mysqld: stack_bottom = 0x83b6c30c thread_stack 0x48000
|
Oct 30 15:26:18 mariadblab kernel: [ 1503.693631] mysqld[8445]: segfault at b77ae674 ip b64de54f sp 83b68958 error 7 in libc-2.13.so[b646e000+15f000]
|
Oct 30 15:26:18 mariadblab mysqld_safe: Number of processes running now: 0
|
Oct 30 15:26:18 mariadblab mysqld_safe: mysqld restarted
|
Although this procedure as it is is badly written (and we fixed it and the server no longer crashes), it should not bring down the whole the server.
We also tried building the package from source (deb-src) to no avail.
We reproduced this on 3 different physical servers, with default my.cnf settings as well as innoDB optimized settings for lots of RAM, on a new install as well as on a fully loaded server.
For what it's worth, we noticed that the problem seems to be linked to the connection: if the server does not crash on the first call, quitting the client and connecting again seems to somehow delay the occurance of the crash.
Best regards,
Laurent
Bug
Critical
