MySQL Bugs: #33844: Server crashes when client dies during LOAD DATA INFILE

Bug #33844	Server crashes when client dies during LOAD DATA INFILE
Submitted:	13 Jan 2008 13:26	Modified:	8 Aug 2010 9:28
Reporter:	Hartmut Holzgraefe	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: DML	Severity:	S3 (Non-critical)
Version:	5.1.23, 5.1.48	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
When a client is interrupted during an ongoing LOAD DATA INFILE the server crashes.

How to repeat:
See the attached source project. It registers a custom client side LOAD DATA LOCAL INFILE handler using the C API mysql_set_local_infile_handler() function to force the situation by calling exit() within the read handler. As this API call changes the client behavior only though and not how the sever processes the LOAD DATA command i think it is a general LOAD DATA LOCAL problem.

Compile the source, create a table "t1", then run the test program and see the server crash.

Suggested fix:
Have the server handle an interrupted LOAD DATA LOCAL INFILE gracefully instead of crashing

Server crash backtrace:

#0  0xffffe410 in __kernel_vsyscall ()
#1  0x4003b8b8 in pthread_kill () from /lib/tls/libpthread.so.0
#2  0x0841437e in write_core (sig=6) at stacktrace.c:240
#3  0x0827fb7a in handle_segfault (sig=6) at mysqld.cc:2309
#4  <signal handler called>
#5  0xffffe410 in __kernel_vsyscall ()
#6  0x400f3541 in raise () from /lib/tls/libc.so.6
#7  0x400f4dbb in abort () from /lib/tls/libc.so.6
#8  0x400ec925 in __assert_fail () from /lib/tls/libc.so.6
#9  0x08266f65 in Diagnostics_area::set_ok_status (this=0x8fd2720, thd=0x8fd1a88, affected_rows_arg=0, last_insert_id_arg=0, 
    message_arg=0x4177f048 "Records: 0  Deleted: 0  Skipped: 0  Warnings: 0") at sql_class.cc:389
#10 0x081b097f in send_ok (thd=0x8fd1a88, affected_rows=0, id=0, message=0x4177f048 "Records: 0  Deleted: 0  Skipped: 0  Warnings: 0")
    at sql_class.h:2105
#11 0x083ce5cb in mysql_load (thd=0x8fd1a88, ex=0x90226e8, table_list=0x9022738, fields_vars=@0x8fd2f88, set_fields=@0x8fd2fa0, 
    set_values=@0x8fd2f94, handle_duplicates=DUP_ERROR, ignore=true, read_file_from_client=true) at sql_load.cc:517
#12 0x08297937 in mysql_execute_command (thd=0x8fd1a88) at sql_parse.cc:3160
#13 0x0829cdfe in mysql_parse (thd=0x8fd1a88, inBuf=0x9022638 "LOAD DATA LOCAL INFILE 'dummy' INTO TABLE t1", length=44, 
    found_semicolon=0x4178030c) at sql_parse.cc:5565
#14 0x0829d990 in dispatch_command (command=COM_QUERY, thd=0x8fd1a88, packet=0x9017751 "", packet_length=44) at sql_parse.cc:1090
#15 0x0829eb62 in do_command (thd=0x8fd1a88) at sql_parse.cc:764
#16 0x0828c706 in handle_one_connection (arg=0x8fd1a88) at sql_connect.cc:1120
#17 0x40038297 in start_thread () from /lib/tls/libpthread.so.0
#18 0x4018a37e in clone () from /lib/tls/libc.so.6
#19 0x41780bb0 in ?? ()

As it crashes on a failed assert() this might only affect debug builds, no idea yet whether it does any harm to non-debug servers ...

Hartmut,

please can you add a more specific test file here.

test case project

Attachment: bug33844-0.1.tar.gz (application/x-gzip, text), 293.21 KiB.

Corrected the version number, bug only appeared in 5.1.23, the function it crashes in doesn't even exist in 5.1.22 yet. Bug still repeatable for me on a 5.1bk build from yesterday ...

Clarification on how to reproduce:

- download test source, unpack it, change to unpacked directory bug33844-0.1
- ./configure --with-mysql=/mysql/install/prefix
- make
- mysql -e "CREATE TABLE IF NOT EXISTS test.t1(id int)" 
   /* table structure doesn't matter, test.t1 just needs to exist */
- ./bug33844
- Check server logs to verify that the server crashed on this.

Tested on SuSE 10.0 (x86 32bit) and Ubuntu 7.10 (x86 64bit), both crash

Verified as described with newest bk tree of 5.1.

For verification I took the test from Hartmut and changed connection informations at bug33844.c.
I created a table t1 with one integer row.
$ ./configure --with-mysql=/PATH
$ make

The same happens with gmake on FreeBSD.

I tested with Ubuntu and FreeBSD both AMD 64.

I forgot:

here is the crash output:

Assertion failed: (! is_set()), function set_ok_status, file sql_class.cc, line 396.
080326 15:32:19 - mysqld got signal 6 ;

I was not able to repeat the bug using the attached test case and MySQL server version 5.1.48 compiled with debug. Since the bug was reported more than 2 years ago, it's likely it was fixed by some other patch. Please re-verify or close as "Can't repeat".

Dmitry,

i can still reproduce this just fine with 5.1.48,
did you follow the full procedure described above:

* run a server compiled with --with-debug
* create a table test.t1
* run the test binary

?

I was rather lazy when writing the test program,
so the t1 table needs to be created manually,
and there is no error handling in the test program
either, but when following these steps i can still
crash the server at will with 5.1.48

Hartmut,

I built mysql server with option '--with-debug=full' (actually I ran server building over script BUILD/compile-pentium-debug-max; this script runs configure with option '--with-debug=full')

I checked that server was built with debug:
$ sql/mysqld --version
sql/mysqld  Ver 5.1.48-debug for apple-darwin10.4.0 on x86_64 (Source distribution)

I created table t1 manually and insert one row into it.

$ mysql -u root -e 'select * from t1;' test
+-----+
| id  |
+-----+
| 100 | 
+-----+

I created empty file with name 'dummy'.

I compiled test, ran mysqld.

Last I ran test 
$ ./bug33844
$ echo $?
3

Program exited with status= 3 but mysql server still work

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".