MySQL Bugs: #31111: --read-only crashes MySQL (events fail to load)

Bug #31111	--read-only crashes MySQL (events fail to load)
Submitted:	20 Sep 2007 14:16	Modified:	9 Nov 2007 17:26
Reporter:	Domas Mituzas	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Stored Routines	Severity:	S1 (Critical)
Version:	5.1-bk	OS:	Any
Assigned to:	Alexander Nozdrin	CPU Architecture:	Any
Tags:	bfsm_2007_10_18

Description:
MySQL 5.1 will crash if --read-only is specified:

flute:/tmp midom$ mysql_install_db --datadir=$PWD/readonly
Installing MySQL system tables...
070920 17:13:11 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=/tmp/readonly/flute-bin' to avoid this problem.
OK
Filling help tables...
070920 17:13:11 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=/tmp/readonly/flute-bin' to avoid this problem.
OK

To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system

PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/local/mysql/bin/mysqladmin -u root password 'new-password'
/usr/local/mysql/bin/mysqladmin -u root -h flute.local password 'new-password'
See the manual for more instructions.
You can start the MySQL daemon with:
cd /usr/local/mysql ; /usr/local/mysql/bin/mysqld_safe &

You can test the MySQL daemon with mysql-test-run.pl
cd mysql-test ; perl mysql-test-run.pl

Please report any problems with the /usr/local/mysql/bin/mysqlbug script!

The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at http://shop.mysql.com
flute:/tmp midom$ /usr/local/mysql/libexec/mysqld --read-only --datadir=$PWD/readonly/ --skip-networking --socket=/tmp/rotest
070920 17:13:16 [Warning] Setting lower_case_table_names=2 because file system for /tmp/readonly/ is case insensitive
070920 17:13:16 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=/tmp/readonly/flute-bin' to avoid this problem.
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
070920 17:13:16  InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
070920 17:13:16  InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
070920 17:13:16  InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
070920 17:13:17  InnoDB: Started; log sequence number 0 0
070920 17:13:17 [ERROR] Event Scheduler: Failed to open table mysql.event
070920 17:13:17 [ERROR] Event Scheduler: Error while loading from disk.
070920 17:13:17 [Note] Event Scheduler: Purging the queue. 0 events
070920 17:13:17 [ERROR] Aborting

table.cc:399: failed assertion `share->ref_count == 0'
070920 17:13:17 - mysqld got signal 6;
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=8388600
read_buffer_size=131072
max_used_connections=0
max_threads=151
threads_connected=0
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337613 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

How to repeat:
#0  0x9003d66c in kill ()
#1  0x9010e8cf in raise ()
#2  0x9010d422 in abort ()
#3  0x0040138f in __eprintf () at ha_myisammrg.cc:38
#4  0x00103ac1 in free_table_share (share=0x5072210) at table.cc:399
#5  0x000f3c47 in table_def_free_entry (share=0x5072210) at sql_base.cc:271
#6  0x003c655c in hash_free (hash=0x683da0) at hash.c:92
#7  0x000f3da3 in table_def_free () at sql_base.cc:296
#8  0x000a9387 in clean_up (print_message=true) at mysqld.cc:1191
#9  0x000ac9b2 in unireg_abort (exit_code=1) at mysqld.cc:1151
#10 0x000b194a in main (argc=5, argv=0xbffff9f4) at mysqld.cc:3933

Suggested fix:
-

Thank you. It seems, the bug depends on the configuration flags.
It does not appear if configured by the standard BUILD/compiled-xxx
scripts.

BUG#30173 has been marked as a duplicate of this bug.

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

ChangeSet@1.2600, 2007-10-16 14:41:47+04:00, anozdrin@station. +7 -0
  Patch for BUG#31111: --read-only crashes MySQL (events fail to load).
  
  There actually were several problems here:
    - wrong lock type was acquired before reading mysql.event table;
    - Security_context::master_access attribute was not properly
      initialized in Security_context::init(), which led to differences
      in behavior with and without debug configure options.
    - if the server failed to load events from mysql.event, it:
      - forgot to close the mysql.event table, that led to the coredump,
        described in the bug report;
      - did not deinitialize the replication module, that lead to
        memory-lost warning on exit. 
  
  The patch is to fix all these problems:
    - Use READ-lock when loading events from the mysql.event table;
    - Initialize Security_context::master_access;
    - Close the mysql.event table in case something went wrong;
    - Deinitialize the replication module on exit.

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

ChangeSet@1.2600, 2007-10-17 10:05:50+04:00, anozdrin@station. +7 -0
  Patch for BUG#31111: --read-only crashes MySQL (events fail to load).
  
  There actually were several problems here:
    - WRITE-lock is required to load events from the mysql.event table,
      but in the read-only mode an ordinary user can not acquire it;
    - Security_context::master_access attribute was not properly
      initialized in Security_context::init(), which led to differences
      in behavior with and without debug configure options.
    - if the server failed to load events from mysql.event, it:
      - forgot to close the mysql.event table, that led to the coredump,
        described in the bug report;
      - did not deinitialize the replication module, that lead to
        memory-lost warning on exit. 
  
  The patch is to fix all these problems:
    - Use the super-user to acquire WRITE-lock on the mysql.even table;
    - The WRITE-lock is acquired by the event scheduler in two cases:
      - on initial loading of events from the database;
      - when an event has been executed, so its attributes should
        be updated.
      Other cases when WRITE-lock is needed for the mysql.event table
      happen under the user account. So, nothing should be changed there:
      The user is able to create/update/drop an event only if he is
      a super-user.
    - Initialize Security_context::master_access;
    - Close the mysql.event table in case something went wrong;
    - Deinitialize the replication module on exit.

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

ChangeSet@1.2600, 2007-10-19 15:28:42+04:00, anozdrin@station. +7 -0
  Patch for BUG#31111: --read-only crashes MySQL (events fail to load).
  
  There actually were several problems here:
    - WRITE-lock is required to load events from the mysql.event table,
      but in the read-only mode an ordinary user can not acquire it;
    - Security_context::master_access attribute was not properly
      initialized in Security_context::init(), which led to differences
      in behavior with and without debug configure options.
    - if the server failed to load events from mysql.event, it forgot to
      close the mysql.event table, that led to the coredump, described
      in the bug report.
  
  The patch is to fix all these problems:
    - Use the super-user to acquire WRITE-lock on the mysql.even table;
    - The WRITE-lock is acquired by the event scheduler in two cases:
      - on initial loading of events from the database;
      - when an event has been executed, so its attributes should
        be updated.
      Other cases when WRITE-lock is needed for the mysql.event table
      happen under the user account. So, nothing should be changed there:
      The user is able to create/update/drop an event only if he is
      a super-user.
    - Initialize Security_context::master_access;
    - Close the mysql.event table in case something went wrong.

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

ChangeSet@1.2593, 2007-10-19 19:57:08+04:00, anozdrin@station. +7 -0
  Patch for BUG#31111: --read-only crashes MySQL (events fail to load).
  
  There actually were several problems here:
    - WRITE-lock is required to load events from the mysql.event table,
      but in the read-only mode an ordinary user can not acquire it;
    - Security_context::master_access attribute was not properly
      initialized in Security_context::init(), which led to differences
      in behavior with and without debug configure options.
    - if the server failed to load events from mysql.event, it forgot to
      close the mysql.event table, that led to the coredump, described
      in the bug report.
  
  The patch is to fix all these problems:
    - Use the super-user to acquire WRITE-lock on the mysql.even table;
    - The WRITE-lock is acquired by the event scheduler in two cases:
      - on initial loading of events from the database;
      - when an event has been executed, so its attributes should
        be updated.
      Other cases when WRITE-lock is needed for the mysql.event table
      happen under the user account. So, nothing should be changed there
      for the read-only mode. The user is able to create/update/drop
      an event only if he is a super-user.
    - Initialize Security_context::master_access;
    - Close the mysql.event table in case something went wrong.

Pushed into 5.1-runtime.

Bug #31660 was marked as duplicate of this one.

Pushed into 6.0.4-alpha

Pushed into 5.1.23-rc

Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.

If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at

    http://dev.mysql.com/doc/en/installing-source.html

Documented in 5.1.23 and 6.0.4 changelogs as follows:

     Starting the server using <option>--read-only</option> and with the Event 
     Scheduler enabled caused it to crash.

[end]

Note that the Event Scheduler is OFF but not DISABLED by default. This means that, by default, the event scheduler thread runs even though no events are executed.

Bug #33234 was marked as duplicate of this one.