MySQL Bugs: #14286: mysqld --bootstrap fails if without transactional storage engines

Bug #14286	mysqld --bootstrap fails if without transactional storage engines
Submitted:	25 Oct 2005 9:30	Modified:	30 Oct 2006 7:45
Reporter:	Hiroshi Takenaka	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S2 (Serious)
Version:	5.0.15	OS:	FreeBSD (FreeBSD 4.7, 4.8)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
if none of BekeleyDB, InnoDB, or ndbcluster is compiled in,
mysqld --bootstrap will dump core.

How to repeat:
build mysql like:

  ./configure --without-innodb --without-berkeley-db --without-ndbcluster
  make install

and run ./mysqld --bootstrap.

Suggested fix:
apply one (or both) of following patches.

Patch A:

*** sql_class.h.orig Mon Oct 17 10:27:44 2005
--- sql_class.h       Tue Oct 25 18:27:01 2005
***************
*** 1220,1233 ****
        free_root(&mem_root,MYF(MY_KEEP_PREALLOC));
  #endif
      }
- #ifdef USING_TRANSACTIONS
      st_transactions()
      {
        bzero((char*)this, sizeof(*this));
        xid_state.xid.null();
        init_sql_alloc(&mem_root, ALLOC_ROOT_MIN_BLOCK_SIZE, 0);
-     }
  #endif
    } transaction;
    Field      *dupp_field;
  #ifndef __WIN__
--- 1220,1233 ----
        free_root(&mem_root,MYF(MY_KEEP_PREALLOC));
  #endif
      }
      st_transactions()
      {
        bzero((char*)this, sizeof(*this));
+ #ifdef USING_TRANSACTIONS
        xid_state.xid.null();
        init_sql_alloc(&mem_root, ALLOC_ROOT_MIN_BLOCK_SIZE, 0);
  #endif
+     }
    } transaction;
    Field      *dupp_field;
  #ifndef __WIN__

Patch B:

*** sql_parse.cc.orig   Tue Oct 25 18:28:08 2005
--- sql_parse.cc        Tue Oct 25 18:28:27 2005
***************
*** 1374,1385 ****
--- 1374,1387 ----
      my_error(ER_COMMIT_NOT_ALLOWED_IN_SF_OR_TRG, MYF(0));
      DBUG_RETURN(1);
    }
+ #ifdef USING_TRANSACTIONS
    if (thd->transaction.xid_state.xa_state != XA_NOTR)
    {
      my_error(ER_XAER_RMFAIL, MYF(0),
               xa_state_names[thd->transaction.xid_state.xa_state]);
      DBUG_RETURN(1);
    }
+ #endif
    switch (completion) {
    case COMMIT:
      /*

Can't reproduce with latest 5.0bk on Linux, 
maybe already fixed since release
or FreeBSD specific (although unlikely)

What results had you got from mysqld --bootstrap really?

Look, I had performed the following steps with 5.0.15 on FreeBSD 4.7:

cd valeriy/mysql-5.0.15
./configure --prefix=/usr/home/mysqldev/valeriy/dbs/5.0 --without-innodb --without-berkeley-db --without-ndbcluster
make install
cd ../dbs/5.0/
bin/mysql_install_db

(mysqld --bootstrap is called by this script, according to the manual). Then:

mysqldev@cane:/usr/home/mysqldev/valeriy/dbs/5.0> bin/mysqld_safe --skip-networking --socket=/tmp/my.sock &
[1] 48667
mysqldev@cane:/usr/home/mysqldev/valeriy/dbs/5.0> Starting mysqld daemon with databases from /usr/home/mysqldev/valeriy/dbs/5.0/var

mysqldev@cane:/usr/home/mysqldev/valeriy/dbs/5.0> bin/mysql -uroot --socket=/tmp/my.sock
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.0.15

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

mysql> use test;
Database changed
mysql> exit
Bye
mysqldev@cane:/usr/home/mysqldev/valeriy/dbs/5.0> uname -a
FreeBSD cane.mysql.com 4.7-RC2 FreeBSD 4.7-RC2 #0: Mon Sep 30 17:35:51 EEST 2002      root@cane.mysql.fi:/usr/src/sys/compile/CANE  i386

There is nothing special in the error log:

mysqldev@cane:/usr/home/mysqldev/valeriy/dbs/5.0> cat var/cane.mysql.com.err
051025 19:29:05  mysqld started
051025 19:29:05 [Note] /usr/home/mysqldev/valeriy/dbs/5.0/libexec/mysqld: ready for connections.
Version: '5.0.15'  socket: '/tmp/my.sock'  port: 0  Source distribution

So, all the usual steps works OK for me even with the configure options you provided. What exact steps should I perform to repeat the problem you described, and what the results you got?

Sorry, I forgot to write the detail of the problem.

When sql_parse.cc:end_trans() is called during bootstrap,
thd->transaction.xid_state.xa_state doesn't seem to be initialized,
and its value happens to be a large negative integer on my environment.
So, in the following code (in end_trans()), reading
xa_state_names[thd->transaction.xid_state.xa_state]
causes segmentation fault:

    if (thd->transaction.xid_state.xa_state != XA_NOTR)
    {
      my_error(ER_XAER_RMFAIL, MYF(0),
               xa_state_names[thd->transaction.xid_state.xa_state]);
      DBUG_RETURN(1);
    }

Some additional info:
I'm using FreeBSD 4.8 and gcc 2.95.4 on a x86 machine.

How about --with-debug=full? Here's what I tried just now:

# ./configure --prefix=/path/to/mytestdir --with mysqld-user=myaccount \
       --with-debug=full --without-innodb \
       --without-berkeley-db --without-ndbcluster \
# gmake install
# ./sql/mysqld --bootstrap --debug:t
>my_realpath
<my_realpath
>my_load_path
<my_load_path
   :
 (snip)
   :
>handle_bootstrap
| >_mymalloc
| <_mymalloc
| >ha_enable_transaction
| | >end_trans
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=8388572
read_buffer_size=131072
max_used_connections=0
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 = 225788 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

I'll try the exact steps you listed on the same FreeBSD 4.7 with GCC 2.95.4. That is the closest platfrom to yours I can get.

After performing:

mysqldev@cane:/usr/home/mysqldev/valeriy/mysql-5.0.15> ./configure --prefix=/usr/home/mysqldev/valeriy/dbs/5.0 --with-debug=full --without-innodb --without-berkeley-db --without-ndbcluster

gmake install gave me:

g++ -g -DDBUG_ON -DSAFE_MUTEX -DSAFEMALLOC -fno-implicit-templates -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=1000000 -DHAVE_BROKEN_REALPATH -DUSE_PRAGMA_IMPLEMENTATION -o mysqlmanager command.o mysqlmanager.o manager.o log.o thread
_registry.o listener.o protocol.o mysql_connection.o user_map.o messages.o commands.o instance.o instance_map.o instance_options.o buffer.o parse.o guardian.o parse_output.o  liboptions.a libnet.a ../../vio/libvio.a ../../mysys/libmysys.a .
./../strings/libmystrings.a ../../dbug/libdbug.a -lz -lcrypt -lm -pthread
listener.o: In function `Listener_thread::run(void)':
/usr/home/mysqldev/valeriy/mysql-5.0.15/server-tools/instance-manager/listener.cc:206: undefined reference to `Thread_registry::is_shutdown(void)'
mysql_connection.o: In function `Mysql_connection_thread::run(void)':
/usr/home/mysqldev/valeriy/mysql-5.0.15/server-tools/instance-manager/mysql_conn
ection.cc:182: undefined reference to `Thread_registry::is_shutdown(void)'
mysql_connection.o: In function `Mysql_connection_thread::do_command(void)':
/usr/home/mysqldev/valeriy/mysql-5.0.15/server-tools/instance-manager/mysql_conn
ection.cc:303: undefined reference to `Thread_registry::is_shutdown(void)'
/usr/home/mysqldev/valeriy/mysql-5.0.15/server-tools/instance-manager/mysql_conn
ection.cc:311: undefined reference to `Thread_registry::is_shutdown(void)'
gmake[2]: *** [mysqlmanager] Error 1
gmake[2]: Leaving directory `/usr/home/mysqldev/valeriy/mysql-5.0.15/server-tool
s/instance-manager'
gmake[1]: *** [install-recursive] Error 1
gmake[1]: Leaving directory `/usr/home/mysqldev/valeriy/mysql-5.0.15/server-tools'
gmake: *** [install-recursive] Error 1

Have you got any errors like that?

Yes. I've got the same error.
Adding -O to CXXFLAGS seems to solve that problem.
I didn't have report that, because I was not sure
if it's a problem of MySQL or a problem of gcc.
Sorry, if I have confused you.

However, the --bootstrap problem isn't affected by -O flag.
It happens both with or without -O in my environment.

Thank you for your patience. Now I was able to verify it on our FreeBSD 4.7 server (cane) using the following sequence of actions:

./configure --prefix=/usr/home/mysqldev/valeriy/dbs/5.0 --with-debug=full --without-innodb --without-berkeley-db --without-ndbcluster

CXXFLAGS="-O" ./configure --prefix=/usr/home/mysqldev/valeriy/dbs/5.0 --with-debug=full --without-innodb --without-berkeley-db --without-ndbcluster

make install
./sql/mysqld --bootstrap --debug=t

The last command gave me:

...
| <hash_init
| >my_net_init
| | >_mymalloc
| | <_mymalloc
| <my_net_init
>handle_bootstrap
| >_mymalloc
| <_mymalloc
| >ha_enable_transaction
| | >end_trans
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=8388572
read_buffer_size=131072
max_used_connections=0
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 = 225788  K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

That is, crash. Same as you described. I hope, your suggested fix will help our developers.

Thanks for a clear bug report and suggested fix.

To summarize the information above:

1.  This problem occurrs because of uninitialized member transaction
    of the THD class.  The initialization normally takes place in the
    member function st_transactions(), which is #ifdef'd out if no
    transaction-based engine is included in the server.

2.  This bug exists on all platforms, but it seems only to cause
    problems in FreeBSD.  The inability to reproduce the problem
    suggests that it only happens under some circumstances.

3.  The bug report includes a suggested fix, which retains the member
    function st_transactions() and performs the initialization of the
    struct.

I don't have time to investigate the code in detail at the moment, but
it seems reasonable to assume that the suggested fix will solve the
immediate problem.  On the other hand, it's not clear that it's the
correct fix.  It doesn't seem to be reasonable to have a struct called
transaction if the server doesn't support transactions.  More
investigation is needed here.

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/2560

See bug #15047: sever crash when compiling without transaction support