Bug #15185 Server crashes if InnoDB table is opened when InnoDB is disabled
Submitted: 23 Nov 2005 14:29 Modified: 6 Jan 2006 5:38
Reporter: Eldad Ran Email Updates:
Status: Closed Impact on me:
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.0.17-BK, 5.0.16-standard OS:Linux (Linux)
Assigned to: Jim Winstead CPU Architecture:Any

[23 Nov 2005 14:29] Eldad Ran
Server crashes, befor that I've tried to use MySQL Query Browser to edit table stracture and got "Could not fetch columns", this is a fresh installtion.

How to repeat:
Have no idea just did a basic operation of editing table, I'm able to query tables, but not editing table stracture.
[23 Nov 2005 14:29] Eldad Ran
error file

Attachment: mysql.txt (text/plain), 15.14 KiB.

[23 Nov 2005 15:13] Eldad Ran
lite hand on the keyboard, not a bug, sorry.
[23 Nov 2005 17:44] Heikki Tuuri
If the server crashes, it looks like a bug to me. Please resolve the stack traces.

[23 Nov 2005 19:11] Valeriy Kravchuk
Thank you for a crash report. Please, send the resolved stack trace as Heikki asked. 

What version of Query Browser you used? What exact steps you performed before you get the crash? And why do you think it is not a MySQL bug?
[23 Nov 2005 21:12] Eldad Ran
Looking deeper into the error log, I've found that the TMPDIR for bash pointed /root/tmp that didn't have the right permissions to allow mysql to right to it, as soon as the TMPDIR changed to /tmp all got back to normal.
If you still think it is a bug, as the server crashed, I'll be more then happy to resolve the stack, I'll send it as soon as I get back to the office tomorrow morning.
[23 Nov 2005 22:30] Heikki Tuuri
Yes, it is a bug if mysqld cannot handle missing permissions to TMPDIR gracefully.

Please resolve the stack trace.


[24 Nov 2005 7:36] Eldad Ran
[root@vox01 mysql]# resolve_stack_dump -s /usr/lib/mysql/mysqld.sym -n mysql.stack
0x80a13b7 handle_segfault + 423
0x82e77a8 pthread_sighandler + 184
0x8192a64 srv_export_innodb_status + 276
0x81427eb innodb_export_status__Fv + 11
0x8134414 ha_update_statistics__Fv + 20
0x815c088 fill_status__FP3THDP13st_table_listP4Item + 40
0x815d15c get_schema_tables_result__FP4JOIN + 316
0x80e157b exec__4JOIN + 1291
0x80e28c9 mysql_select__FP3THDPPP4ItemP13st_table_listUiRt4List1Z4ItemP4ItemUiP8st_orderT7T5T7UlP13select_resultP18st_select_lex_unitP13s + 873
0x80df251 handle_select__FP3THDP6st_lexP13select_resultUl + 193
0x80b32d0 mysql_execute_command__FP3THD + 1360
0x80b9a9a mysql_parse__FP3THDPcUi + 282
0x80b1843 dispatch_command__F19enum_server_commandP3THDPcUi + 1827
0x80b1114 do_command__FP3THD + 196
0x80b0634 handle_one_connection + 772
0x82e4f5c pthread_start_thread + 220
0x830e85a thread_start + 4
[27 Nov 2005 9:38] Valeriy Kravchuk
Thank you for a real bug report.

It is easily repeatable on Linux, even with latest 5.0.17-BK build (ChangeSet@1.2009.1.2, 2005-11-25 20:48:26+03:00). User simply needs to set TMPDIR to some directory to which he has no access, and start mysqld - the crash is ready to begin:

[openxs@Fedora srv]$ export TMPDIR=/root/
[openxs@Fedora openxs]$ cd ~/dbs/5.0/
[openxs@Fedora 5.0]$ bin/mysqld_safe &
[1] 1462
[openxs@Fedora 5.0]$ Starting mysqld daemon with databases from /home/openxs/dbs/5.0/var

[openxs@Fedora 5.0]$ bin/mysql -uroot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.17

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

Number of processes running now: 0
051127 12:19:26  mysqld restarted

mysql> show tables;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: test

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (111)
Can't connect to the server

Number of processes running now: 0
051127 12:19:49  mysqld restarted

mysql> exit
051127 12:19:49  mysqld restarted
/home/openxs/dbs/5.0/libexec/mysqld: Can't read dir of '/root/' (Errcode: 13)
/home/openxs/dbs/5.0/libexec/mysqld: Can't create/write to file '/root/ibTPGNg0'
 (Errcode: 13)
051127 12:19:50  InnoDB: Error: unable to create temporary file; errno: 13
051127 12:19:50 [Note] /home/openxs/dbs/5.0/libexec/mysqld: ready for connection
Version: '5.0.17'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
[openxs@Fedora 5.0]$ tail -50 var/Fedora.err
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

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=0xbebf7b84, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
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 0x98dec80 =
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
051127 12:19:49  mysqld restarted
/home/openxs/dbs/5.0/libexec/mysqld: Can't read dir of '/root/' (Errcode: 13)
/home/openxs/dbs/5.0/libexec/mysqld: Can't create/write to file '/root/ibTPGNg0'
 (Errcode: 13)
051127 12:19:50  InnoDB: Error: unable to create temporary file; errno: 13
051127 12:19:50 [Note] /home/openxs/dbs/5.0/libexec/mysqld: ready for connections.
Version: '5.0.17'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution

My resolved stack trace looks more reasonable, though:

[openxs@Fedora 5.0]$ bin/resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack
0x814e97d handle_segfault + 565
0x64ef18 (?)
0x81f4aa7 _ZN11ha_innobase4openEPKcij + 219
0x81eb9f4 _ZN7handler7ha_openEPKcii + 28
0x818dc03 _Z7openfrmP3THDPKcS2_jjjP8st_table + 3963
0x818807d _Z17open_unireg_entryP3THDP8st_tablePKcS4_S4_P13st_table_listP11st_mem
_root + 89
0x8187375 _Z10open_tableP3THDP13st_table_listP11st_mem_rootPbj + 1821
0x8188783 _Z11open_tablesP3THDPP13st_table_listPjj + 547
0x8188c31 _Z30open_normal_and_derived_tablesP3THDP13st_table_listj + 25
0x820accf _Z18mysqld_list_fieldsP3THDP13st_table_listPKc + 23
0x8160a50 _Z16dispatch_command19enum_server_commandP3THDPcj + 2048
0x8160215 _Z10do_commandP3THD + 129
0x815f6b2 handle_one_connection + 466
0x64879c (?)
0x49527a (?)
[14 Dec 2005 22:13] Jim Winstead
This happens because 'SHOW TABLES' is trying to open an InnoDB table, but InnoDB has been disabled because TMPDIR is unwritable.
[14 Dec 2005 23:00] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

[6 Jan 2006 1:53] Jim Winstead
Fixed in 5.0.19. (Was not a problem in 5.1, at least in recent versions.)
[6 Jan 2006 5:38] Paul Dubois
Noted in 5.0.19 changelog.