MySQL Bugs: #62512: Crash on MacOSX

Bug #62512	Crash on MacOSX
Submitted:	23 Sep 2011 10:53	Modified:	3 Mar 2012 16:35
Reporter:	Thomas Werner	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Options	Severity:	S3 (Non-critical)
Version:	5.5.15	OS:	MacOS (10.6 and 10.7)
Assigned to:		CPU Architecture:	Any

Description:
Hi everyone,

database keeps crashing on MacOSX. I tried a lot of version in past like 5.1.51, 5.5.8 and the current one 5.5.15. I tried the binary or self compiled but MySql crashes. The only version wich is currently working on MacOSX is 5.0.38 (but self compiled). The production server is Linux with a lot of users but there are no problems. The test machine with Windows is working as well, but not my development machine under MacOSX. I have no idea anymore, what i can do, thats why i can only attach the log.

Thx Thomas

How to repeat:
N/A

Log

Attachment: loox.local.err (application/octet-stream, text), 53.74 KiB.

Please, attach error log with information from the crash.

Our submission obviously crossed. 

Log is already is attached.

Any chance to pinpoint SQL that crashes? general query log or some application-level log maybe?

I guess, it has something to todo with (the queries in) stored procedures, but i try to check it with the logs next days (end of the week) because currently on the way. If have something i let you know.

I spend some time and i got it. I found a simple stored procedure, which causes the crash and contains only a simple UPDATE:

mysql> CALL cmf_contact_set( 1017639 ); => CRASH

mysql> UPDATE `contact` SET `contact_name` = cmf_contact_get_cn( `contact_id` ) WHERE `contact_id` = 1017639 LIMIT 1; => NO CRASH

After disabling the triggers for table "contact" or "emptied" the "deepest" stored procedure/function (removed a simple SELECT statement) which was called from trigger it was working. But with SELECT statement in "depeest" stored procedure/function, it crashes again.

Then i simple increased "thread_stack" and now no crash anymore.

So, can we assume that this problem was not a result of any bug and you just had to set proper thread_stack size, taking into account deep nesting of triggers and stored routines?

Yes, but on windows or linux i get an error message. I think a crash is not the right answer if a configuration parameter is to low. An error message would have saved me much time. 

Strange was, that with the error message on linux i updated my.cnf on osx as well but the setting

[mysqld]
thread_stack = 512K

was not recognized in my.cnf on osx. SHOW VARIABLES did show always the default value. I checked the processes and i'm sure that my.cnf is loaded:

/usr/local/mysql/bin/mysqld --defaults-extra-file=/usr/local/mysql/data/my.cnf --basedir=/usr/local/mysql/ --datadir=/usr/local/mysql/data/ --plugin-dir=/usr/local/mysql/lib/plugin --user=tom

but than i only added --thread-stack=512K to the daemon and now everything is working. I did not continue to follow it to find out the trouble maker, maybe there is a "parse error" in my local cnf file... but anyway, with crash it was not easy to find the problem, because the last query change everytime in crash log.

Please, check if this problem ever happens with a newer version, 5.5.21.

With new version no problems anymore.

Now the param "thread_stack" in my.cnf will be used and the defined value is shown in "SHOW VARIABLES;". I used only the the same my.cnf which was not working with my previous versions, everything else is re-installed/replaced (e.g. my changed startup script) and with a too low thread stack now get an error "stack overrun.." instead of a crash.

Thumbs up...

Not repeatable with 5.5.21.

On 5.5.25 this behavior is back again (on OSX 10.7.4

Astelix