[MDEV-6985] MariaDB crashes on stored procedure call - JIRA

Details

Type: Bug
Status: Closed
Priority: Critical
Resolution: Fixed
Affects Version/s: 5.5.40, 10.0.14
Fix Version/s: 10.0.16, 5.5.41
Component/s: Optimizer
Labels:
Environment:

Hide
Linux mariadblab 3.2.0-4-686-pae #1 SMP Debian 3.2.60-1+deb7u3 i686 GNU/Linux
Server is a Xen VM

Mirror used: deb http://nwps.ws/pub/mariadb/repo/10.0/debian wheezy main

Fresh debian install with those packages (plus nginx/phpmyadmin):

ii libmariadbclient18 10.0.14+maria-1~wheezy i386
ii libmysqlclient18 10.0.14+maria-1~wheezy i386
ii mariadb-client-10.0 10.0.14+maria-1~wheezy i386
ii mariadb-client-core-10.0 10.0.14+maria-1~wheezy i386
ii mariadb-common 10.0.14+maria-1~wheezy all
ii mariadb-server 10.0.14+maria-1~wheezy all
ii mariadb-server-10.0 10.0.14+maria-1~wheezy i386
ii mariadb-server-core-10.0 10.0.14+maria-1~wheezy i386
ii mysql-common 10.0.14+maria-1~wheezy all

Show
Linux mariadblab 3.2.0-4-686-pae #1 SMP Debian 3.2.60-1+deb7u3 i686 GNU/Linux Server is a Xen VM Mirror used: deb http://nwps.ws/pub/mariadb/repo/10.0/debian wheezy main Fresh debian install with those packages (plus nginx/phpmyadmin): ii libmariadbclient18 10.0.14+maria-1~wheezy i386 ii libmysqlclient18 10.0.14+maria-1~wheezy i386 ii mariadb-client-10.0 10.0.14+maria-1~wheezy i386 ii mariadb-client-core-10.0 10.0.14+maria-1~wheezy i386 ii mariadb-common 10.0.14+maria-1~wheezy all ii mariadb-server 10.0.14+maria-1~wheezy all ii mariadb-server-10.0 10.0.14+maria-1~wheezy i386 ii mariadb-server-core-10.0 10.0.14+maria-1~wheezy i386 ii mysql-common 10.0.14+maria-1~wheezy all

Description

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

Gliffy Diagrams

Attachments

Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

Attachments

bug-db-dump.sql
4 kB
2014-10-30 17:00
debian.my.cnf
5 kB
2014-10-31 15:13
sql-edi-my.cnf
2 kB
2014-10-31 15:11

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Elena Stepanova added a comment - 2014-10-31 14:40

Hi,

Could you please attach your cnf file(s) or the output of SHOW VARIABLES?

Thanks.

Show

Elena Stepanova added a comment - 2014-10-31 14:40 Hi, Could you please attach your cnf file(s) or the output of SHOW VARIABLES ? Thanks.

8 older comments

Hide

Permalink

Oleksandr Byelkin added a comment - 2014-11-16 11:18

everything happened in subquery where is really only one table. So why in subquery it tries to find external table field that is the question.

Show

Oleksandr Byelkin added a comment - 2014-11-16 11:18 everything happened in subquery where is really only one table. So why in subquery it tries to find external table field that is the question.

Hide

Permalink

Oleksandr Byelkin added a comment - 2014-11-16 15:30

The field resolved from cache and does not marked as "outer".

Show

Oleksandr Byelkin added a comment - 2014-11-16 15:30 The field resolved from cache and does not marked as "outer".

Hide

Permalink

Oleksandr Byelkin added a comment - 2014-11-17 14:18

Problem is that can_be_dependent is not set on the second execution (but set on the first)

Show

Oleksandr Byelkin added a comment - 2014-11-17 14:18 Problem is that can_be_dependent is not set on the second execution (but set on the first)

Hide

Permalink

Oleksandr Byelkin added a comment - 2014-11-17 14:46

The problem is that Item_ident can't stand double cleanup:

first cleanup() set depended_from to NULL
second cleanup drop can_be_depended flag because depended_from was zeroed by first cleanup

Show

Oleksandr Byelkin added a comment - 2014-11-17 14:46 The problem is that Item_ident can't stand double cleanup: first cleanup() set depended_from to NULL second cleanup drop can_be_depended flag because depended_from was zeroed by first cleanup

Hide

Permalink

Oleksandr Byelkin added a comment - 2014-11-17 15:28

Could you review this please?

Show

Oleksandr Byelkin added a comment - 2014-11-17 15:28 Could you review this please?

People

Assignee:

Oleksandr Byelkin

Reporter:

Laurent Mahieux

Votes:

0 Vote for this issue

Watchers:

4 Start watching this issue

Dates

Created:

2014-10-30 17:00

Updated:

2014-12-17 15:48

Resolved:

2014-12-17 15:48

Time Tracking

Estimated:

Not Specified

Remaining:

Logged:

1h 20m

Agile

View on Board