| Bug #44805 | crash in vanilla 5.0.67 | ||
|---|---|---|---|
| Submitted: | 11 May 2009 20:58 | Modified: | 12 May 2009 10:36 |
| Reporter: | d di (Basic Quality Contributor) | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | 5.0.67 | OS: | Windows (Windows Server 2008) |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | qc | ||
[11 May 2009 22:06]
MySQL Verification Team
Thank you for the bug report. Could you please try with latest release 5.0.81 and comment the results?. Thanks in advance.
[11 May 2009 22:18]
d di
I can't even reproduce it on 5.0.67. I thought that perhaps you could look up the addresses in the backtrace...
[11 May 2009 22:24]
MySQL Verification Team
Thank you for the feedback. It is the 32-bit or 64-bit server binary?. Thank you in advance.
[11 May 2009 22:29]
d di
64-bit. 'version%' variables: version 5.0.67-community-nt version_comment MySQL Community Edition (GPL) version_compile_machine unknown version_compile_os Win64
[11 May 2009 23:37]
MySQL Verification Team
Call Stack extracted: 00677B95, MYSQLD-NT.EXE, strdup_root, c:\cygwin\home\mysqldev\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\mysys\my_alloc.c line 400 00549B35, MYSQLD-NT.EXE, acl_insert_user, c:\cygwin\home\mysqldev\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\sql\sql_acl.cc line 1105 0054A7E5, MYSQLD-NT.EXE, replace_user_table, c:\cygwin\home\mysqldev\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\sql\sql_acl.cc line 1955 0055218A, MYSQLD-NT.EXE, mysql_routine_grant, c:\cygwin\home\mysqldev\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\sql\sql_acl.cc line 3136 00555FD4, MYSQLD-NT.EXE, sp_grant_privileges, c:\cygwin\home\mysqldev\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\sql\sql_acl.cc line 5893 0059CB82, MYSQLD-NT.EXE, mysql_execute_command, c:\cygwin\home\mysqldev\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\sql\sql_parse.cc line 4658 005A1899, MYSQLD-NT.EXE, dispatch_command, c:\cygwin\home\mysqldev\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\sql\sql_parse.cc line 1900 005A2C47, MYSQLD-NT.EXE, do_command, c:\cygwin\home\mysqldev\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\sql\sql_parse.cc line 1595 005A2FC6, MYSQLD-NT.EXE, handle_one_connection, c:\cygwin\home\mysqldev\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\sql\sql_parse.cc line 1187 0068B669, MYSQLD-NT.EXE, pthread_start, c:\cygwin\home\mysqldev\build\mysql-5.0.67-winbuild\mysql-community-nt-5.0.67-build\mysys\my_winthread.c line 85 007D5C37, MYSQLD-NT.EXE, _callthreadstart, f:\rtm\vctools\crt_bld\self_64_amd64\crt\src\thread.c line 295 007D5D05, MYSQLD-NT.EXE, _threadstart, f:\rtm\vctools\crt_bld\self_64_amd64\crt\src\thread.c line 275
[12 May 2009 0:00]
d di
Thanks! Is it a null dereference in strlen() in strdup_root() on the str parameter from acl_insert_user()? Looks odd to me, there are no null values in the mysql.user table at least.. The server's SQL mode is: sql_mode=strict_all_tables,no_zero_in_date,no_zero_date Guess I'll add "no_auto_create_user" and hope that takes care of the problem. Haven't found a way to reproduce it. Keep the issue open if you have any good ideas.
[12 May 2009 8:45]
Sveta Smirnova
There is bug #44798 which can be related.
[12 May 2009 8:48]
d di
Ah yes, looks like exactly the same issue. Thanks!
[12 May 2009 10:36]
Sveta Smirnova
Thank you for the feedback. Closed as duplicate of bug #44798
Description: GPF'd a vanilla 5.0.67 with a simple CREATE PROCEDURE statement: ==================================================== 090511 13:48:30 [Note] MySQL: ready for connections. Version: '5.0.67-community-nt' socket: '' port: 3306 MySQL Community Edition (GPL) 090511 22:44:26 - mysqld got exception 0xc0000005 ; 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=201326592 read_buffer_size=4194304 max_used_connections=129 max_connections=1910 threads_connected=129 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3260416 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=00000000175A7950 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... 0000000000677B95 mysqld-nt.exe!??? 0000000000549B35 mysqld-nt.exe!??? 000000000054A7E5 mysqld-nt.exe!??? 000000000055218A mysqld-nt.exe!??? 0000000000555FD4 mysqld-nt.exe!??? 000000000059CB82 mysqld-nt.exe!??? 00000000005A01D8 mysqld-nt.exe!??? 00000000005A1899 mysqld-nt.exe!??? 00000000005A2C47 mysqld-nt.exe!??? 00000000005A2FC6 mysqld-nt.exe!??? 000000000068B669 mysqld-nt.exe!??? 00000000007D5C37 mysqld-nt.exe!??? 00000000007D5D05 mysqld-nt.exe!??? 0000000076EC466D kernel32.dll!BaseThreadInitThunk() 0000000076FF8791 ntdll.dll!RtlUserThreadStart() Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 000000001017C210=CREATE PROCEDURE p (OUT ver_param VARCHAR(25)) BEGIN SELECT VERSION() INTO ver_param; SELECT 1; END thd->thread_id=6273 The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. ==================================================== How to repeat: Not sure; the 'root' user lacks the 'alter procedure' privilege which could be related. Suggested fix: