Bug #25409 | embedded server crashes on startup | ||
---|---|---|---|
Submitted: | 4 Jan 2007 11:32 | Modified: | 10 Apr 2007 16:57 |
Reporter: | Ian Greenhoe | Email Updates: | |
Status: | Can't repeat | Impact on me: | |
Category: | MySQL Server: Embedded Library ( libmysqld ) | Severity: | S1 (Critical) |
Version: | 5.1 | OS: | Linux (Linux (Debian, SuSE)) |
Assigned to: | Damien Katz | CPU Architecture: | Any |
[4 Jan 2007 11:32]
Ian Greenhoe
[4 Jan 2007 14:41]
MySQL Verification Team
Thank you for the bug report. Verified on Fedora Core 6.
[8 Jan 2007 18:00]
Ian Greenhoe
Problem is that the THD class has a different size in innodb than outside of innodb. (There may be other instances of this as well.) This may be caused by incorrect #DEFINEs while compiling.
[10 Jan 2007 14:39]
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: http://lists.mysql.com/commits/17850 ChangeSet@1.2375, 2007-01-10 06:38:26-08:00, igreenhoe@ra.greendragongames.com +1 -0 Fix for bug #25409, "embedded server crashes on startup". This was caused by several interlocking problems: 1) The actual cause of the crash was that THD was compiled with different sets of parameters in different .o files in the libmysqld.a library (specifically, ha_innodb.cc was compiled without EMBEDDED_SERVER, causing considerable problems.) Due to this, when the program was examined under gdb, nonsensical results occurred: It appeared that a variable was being (consistently) assigned a specific garbage value. Further, a printf in the code showed different results than the gdb "p" command on the same variables that were being assigned from. 2) Next problem was that ha_innodb.cc was not being compiled in the libmysqld dir. 3) Next, there were multiple ha_innodb.o objects in the libmysqld.a library; this allowed the compiler to choose a random object. This was true for almost all of the object files in the libmysqld directory (the only object files not effected were lib_sql.cc, emb_qcache.cc, and libmysqld.c) 4) The last problem: ********************************************************************** *** RECENT VERSIONS OF THE GNU CORE UTILITIES, SUCH AS LS AND SORT *** *** HAVE A SORTING ORDER THAT IS DEPENDENT ON THE LOCALE! *** ********************************************************************** This caused apparently random versions of the various .o files to be placed in the resulting library. Setting the locale to "C" restored the expected behavior. In the bash shell, you can set the locale to "C" via the command: export LANG=C It is unknown at this time if this change in the behavior of sort and ls will cause other problems in the code or compilation process.
[3 Feb 2007 21:08]
Sergei Golubchik
The patch is wrong. The solution was implemented for the Bug#23369. Apparently it was broken recently, and this is the bug that should be fixed.
[10 Apr 2007 16:57]
Timothy Smith
Several testers, myself included, are unable to repeat at this time. There were a number of embedded fixes added since this bug was originally verified. Setting to Can't repeat.