Bug #4967 | Disable innodb at startup, and then any innodb based query crashes the server | ||
---|---|---|---|
Submitted: | 9 Aug 2004 22:32 | Modified: | 20 Aug 2004 12:10 |
Reporter: | Nathaniel Blanchard | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S2 (Serious) |
Version: | 4.1.4 | OS: | Linux (Linux) |
Assigned to: | CPU Architecture: | Any |
[9 Aug 2004 22:32]
Nathaniel Blanchard
[11 Aug 2004 0:40]
Hartmut Holzgraefe
Couldn't reproduce it so far with 4.1.3 and command line client, tables are created as MyISAM when server started with --skip-innodb, will try 4.1 bitkeeper sources and C API tomorrow ...
[11 Aug 2004 1:40]
Nathaniel Blanchard
In case it helps, here is the crash log. Number of processes running now: 0 040809 16:05:14 mysqld restarted /usr/local/mysql/libexec/mysqld: ready for connections. Version: '4.1.4-beta-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; 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=1048576 read_buffer_size=20967424 max_used_connections=1 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1131119 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x858a7e0 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=0xbf5fdc58, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80b3247 0x8317306 0x83154d0 0x8214e07 0x8132777 0x8136583 0x812c47d 0x813a92a 0x8141701 0x813a12b 0x8139ba1 0x80c7c73 0x80c98c1 0x80c3d5c 0x80c37d6 0x80c2fbf 0x8314aaf 0x834b06a New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/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 0x85a55e8 = drop database test3 thd->thread_id=1 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.
[11 Aug 2004 1:42]
Nathaniel Blanchard
Also, lets assume that it doesn't crash. Is defaulting to a MyISAM table type even when the user specifies a different type the correct action? I would want/expect an error message to be returned. Obviously, I the developer know what I am doing in saying I want an InnoDB table. What is the correct way to test that InnoDB is enabled?
[19 Aug 2004 17:20]
Hartmut Holzgraefe
Regarding your last comment: Starting with version 4.1.1 you will get a warning if you try to create a table using a handler that is not enabled. You can see (starting with 4.1.2) which table handlers are available and which is the default using SHOW STORAGE ENGINES; ( http://dev.mysql.com/doc/mysql/en/SHOW_ENGINES.html ) So four your purpose SHOW STORAGE ENGINES would be the best solution. But if you plan to also support mysql 4.0.x i'm afraid you have to create a table and use SHOW CREATE TABLE to verify that it was really created as requested and not with the default storage engine type.
[20 Aug 2004 12:10]
Hartmut Holzgraefe
Even with 4.1 bitkeeper source i cannot repeat the crash. (test source file is attached)
[20 Aug 2004 12:11]
Hartmut Holzgraefe
test file that creates a table using C API
Attachment: create_test.c (text/plain), 1.53 KiB.