| Bug #42861 | Assigning invalid directories to --slave-load-tmpdir crashes the slave | ||
|---|---|---|---|
| Submitted: | 14 Feb 20:30 | Modified: | 15 Apr 12:29 |
| Reporter: | Alfranio Correia | ||
| Status: | Closed | ||
| Category: | Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 5.1 | OS: | Any |
| Assigned to: | Alfranio Correia | Target Version: | 5.1+ |
| Triage: | Triaged: D2 (Serious) | ||
[14 Feb 22:26]
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/66358 2798 Alfranio Correia 2009-02-14 BUG#42861 Assigning invalid directories to --slave-load-tmpdir crashes the slave Compiling with debug and assinging an invalid directory to --slave-load-tmpdir was crashing the slave due to the following assertion DBUG_ASSERT(! is_set() || can_overwrite_status). This assertion assumes that a thread can throw one error before stoping its execution unless the overwrite flag (i.e. can_overwrite_status) is true. The cleanup function however was failing and an error was being thrown by my_dir and the replication thread was not aborting the execution. To fix the problem we propagate the error from the cleanup function until it reaches a point in which the replication code can report the error and stop the execution.
[13 Mar 12:03]
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/69130 2832 Alfranio Correia 2009-03-13 BUG#42861 Assigning invalid directories to --slave-load-tmpdir crashes the slave Compiling with debug and assigning an invalid directory to --slave-load-tmpdir was crashing the slave due to the following assertion DBUG_ASSERT(! is_set() || can_overwrite_status). This assertion assumes that a thread can changing its state once (i.e. ok, error, etc) before aborting, cleaning/resuming or completing its execution unless the overwrite flag (i.e. can_overwrite_status) is true. The cleanup function however was being failing and an error thrown by my_dir and the replication SQL thread was not aborting its execution. To fix the problem we check the directory before starting the replication.
[16 Mar 17:56]
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/69323 2832 Alfranio Correia 2009-03-16 BUG#42861 Assigning invalid directories to --slave-load-tmpdir crashes the slave Compiling with debug and assigning an invalid directory to --slave-load-tmpdir was crashing the slave due to the following assertion DBUG_ASSERT(! is_set() || can_overwrite_status). This assertion assumes that a thread can changing its state once (i.e. ok, error, etc) before aborting, cleaning/resuming or completing its execution unless the overwrite flag (i.e. can_overwrite_status) is true. The cleanup function however was being failing and an error thrown by my_dir and the replication SQL thread was not aborting its execution. Furthermore, the Append_block_log_event::do_apply_event was not reseting internal states before starting processing. To fix the problem we check the directory before starting the replication and reset internal states before starting processing.
[18 Mar 11:32]
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/69565 2832 Alfranio Correia 2009-03-18 Bug #42861 Assigning invalid directories to --slave-load-tmpdir crashes the slave Compiling with debug and assigning an invalid directory to --slave-load-tmpdir was crashing the slave due to the following assertion DBUG_ASSERT(! is_set() || can_overwrite_status). This assertion assumes that a thread can change its state once (i.e. ok,error, etc) before aborting, cleaning/resuming or completing its execution unless the overwrite flag (i.e. can_overwrite_status) is true. The Append_block_log_event::do_apply_event which is responsible for creating temporary file(s) was not cleaning the thread state. Thus a failure while trying to create a file in an invalid temporary directory was causing the crash. To fix the problem we check if the temporary directory is valid before starting the SQL Thread and reset the thread state before creating a file in Append_block_log_event::do_apply_event.
[23 Mar 2:07]
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/69995 2825 Alfranio Correia 2009-03-23 Post-fix BUG#42861.
[23 Mar 17:22]
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/70087 3154 Alfranio Correia 2009-03-23 Post-fix BUG#42861.
[27 Mar 15:57]
Bugs System
Pushed into 5.1.34 (revid:joro@sun.com-20090327143448-wuuuycetc562ty6o) (version source revid:azundris@mysql.com-20090323042102-hcciofk3ixld76r8) (merge vers: 5.1.34) (pib:6)
[30 Mar 14:17]
Jon Stephens
Documented bugfix in the 5.1.34 changelog as follows:
Assigning an invalid directory as --slave-load-tmpdir caused the
replication slave to crash.
Set NDI status pending merge to 6.0 tree.
[13 Apr 11:22]
Bugs System
Pushed into 6.0.11-alpha (revid:alik@sun.com-20090413084402-snnrocwzktcl88ny) (version source revid:alfranio.correia@sun.com-20090323162203-4a9zgk1gdgz8yibg) (merge vers: 6.0.11-alpha) (pib:6)
[15 Apr 12:23]
Jon Stephens
Fix also documented in 6.0.11 changelog; closed.
[15 Apr 12:29]
Jon Stephens
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
[9 May 18:47]
Bugs System
Pushed into 5.1.34-ndb-6.2.18 (revid:jonas@mysql.com-20090508185236-p9b3as7qyauybefl) (version source revid:jonas@mysql.com-20090508185236-p9b3as7qyauybefl) (merge vers: 5.1.34-ndb-6.2.18) (pib:6)
[9 May 19:43]
Bugs System
Pushed into 5.1.34-ndb-6.3.25 (revid:jonas@mysql.com-20090509063138-1u3q3v09wnn2txyt) (version source revid:jonas@mysql.com-20090509063138-1u3q3v09wnn2txyt) (merge vers: 5.1.34-ndb-6.3.25) (pib:6)
[9 May 20:41]
Bugs System
Pushed into 5.1.34-ndb-7.0.6 (revid:jonas@mysql.com-20090509154927-im9a7g846c6u1hzc) (version source revid:jonas@mysql.com-20090509154927-im9a7g846c6u1hzc) (merge vers: 5.1.34-ndb-7.0.6) (pib:6)
Description: This assertion fails when the --slave-load-tmpdir is not properly defined (e.g. permission problems, nonexistent directory, etc): #0 0xb8040430 in __kernel_vsyscall () #0 0xb8040430 in __kernel_vsyscall () #1 0xb8003158 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0871a949 in my_write_core (sig=6) at stacktrace.c:310 #3 0x082bdde8 in handle_segfault (sig=6) at mysqld.cc:2505 #4 <signal handler called> #5 0xb8040430 in __kernel_vsyscall () #6 0xb7e398a0 in raise () from /lib/tls/i686/cmov/libc.so.6 #7 0xb7e3b268 in abort () from /lib/tls/i686/cmov/libc.so.6 #8 0xb7e3272e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #9 0x082a5983 in Diagnostics_area::set_error_status (this=0x9bbf88c, thd=0x9bbeae0, sql_errno_arg=1, message_arg=0xb7453d40 "Can't create/write to file '/root/SQL_LOAD-2-1-1.data' (Errcode: 13)") at sql_class.cc:502 #10 0x082bcadb in my_message_sql (error=1, str=0xb7453d40 "Can't create/write to file '/root/SQL_LOAD-2-1-1.data' (Errcode: 13)", MyFlags=36) at mysqld.cc:2849 #11 0x08700f34 in my_error (nr=1, MyFlags=36) at my_error.c:97 #12 0x086f00c2 in my_register_filename (fd=-1, FileName=0xb7453f46 "/root/SQL_LOAD-2-1-1.data", type_of_file=FILE_BY_CREATE, error_message_number=1, MyFlags=16) at my_open.c:184 #13 0x086f02a2 in my_create (FileName=0xb7453f46 "/root/SQL_LOAD-2-1-1.data", CreateFlags=0, access_flags=131201, MyFlags=16) at my_create.c:63 #14 0x083c3d04 in Append_block_log_event::do_apply_event (this=0x9ba01b0, rli=0x9b563c0) at log_event.cc:6182 #15 0x0846736f in Log_event::apply_event (this=0x9ba01b0, rli=0x9b563c0) at log_event.h:1058 #16 0x0845d762 in apply_event_and_update_pos (ev=0x9ba01b0, thd=0x9bbeae0, rli=0x9b563c0, skip=true) at slave.cc:1987 #17 0x084603d9 in exec_relay_log_event (thd=0x9bbeae0, rli=0x9b563c0) at slave.cc:2130 #18 0x08461255 in handle_slave_sql (arg=0x9b55138) at slave.cc:2801 #19 0xb7ffe50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #20 0xb7eefa0e in clone () from /lib/tls/i686/cmov/libc.so.6 How to repeat: cat rpl_slave_load_in.test: --------------------------- connection master; create table t1(a int not null auto_increment, b int, primary key(a)); load data infile '../../std_data/rpl_loaddata.dat' into table t1; run: ---- ./mtr --slave-load-tmpdir=/root rpl_slave_load_in Suggested fix: Check the return of function cleanup_load_tmpdir() in log_event.cc.