MySQL Bugs: #1997: LOAD DATA LOCAL is suspected to not be thread-safe

Bug #1997	LOAD DATA LOCAL is suspected to not be thread-safe
Submitted:	2 Dec 2003 15:38	Modified:	3 Dec 2003 13:06
Reporter:	Dossy Shiobara	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	3.23.57	OS:	Solaris (Solaris 2.8)
Assigned to:	Dean Ellis	CPU Architecture:	Any

Description:
I'm not 100% sure yet, but it seems that LOAD DATA LOCAL is not thread-safe.  Using libmysqlclient_r and normal queries (DML, DDL) work fine, but once a thread issues a LOAD DATA LOCAL, upon thread cleanup it seems to be corrupting some state.  After the thread is cleaned up, if a new thread is spawned and another LOAD DATA LOCAL is issued, it causes the program to segfault.

I haven't tried with the MySQL 4.x client libraries yet, and I don't really have the time at the moment to create a minimal multi-threaded test case that demonstrates this problem, but it is wholly reproducible using AOLserver 4.0 and the nsmysql driver.  This is a repeatable segfault.

Has anyone successfully used LOAD DATA LOCAL within a multi-threaded app. that uses libmysqlclient_r where one thread issues the LOAD DATA LOCAL, then the thread terminates, then a second thread is created and attempts to do a LOAD DATA LOCAL?  That's the reproducible test case in a nutshell.

-- Dossy

How to repeat:
In a multi-threaded application dynamically linking against libmysqlclient_r:

Create a thread.  Issue a LOAD DATA LOCAL.  Terminate the thread.

Create a second thread.  Issue a LOAD DATA LOCAL.  Watch the application segfault.

I am unable to duplicate this using 3.23.58 or 4.0.17; so long as the program is written correctly LOAD DATA LOCAL does not appear to corrupt anything (whether the threads share a connection or create their own).

If you do find the time to submit a minimal test case we could try, I would be happy to test this again.

Thank you

Is there any chance you could test using 3.23.57?  I'll try to test with 3.23.58 if I can.  Doubt this was a bug that was silently fixed between those releases, though.

I'm kind of irked by your comment regarding "if it's written correctly" -- the code works 100% fine for production query traffic where the DB connections are pooled in the multi-threaded app. for "normal" SQL DML/DDL (SELECT, INSERT, UPDATE, DELETE, CREATE TABLE, CREATE INDEX).  I'm going to test with a plain "LOAD DATA" with the file on the server and see if it crashes, but it *definitely* crashes when doing a "LOAD DATA LOCAL".

I'll try to come up with a minimal reproducible test case, but I was hoping this would be enough information for the multi-threaded gurus to go "oh yeah, LOAD DATA LOCAL reads data from a file on the client host into memory in a non-threadsafe way before it pushes the data up to the server ... oops."

-- Dossy

My "if it's written correctly" comment meant only that unless I did something (intentionally) wrong, my test had no problems with LOAD DATA LOCAL.

I can test against 3.23.57, yes, but having a test case which absolutely crashes for you would help tremendously, as there may be a simple matter of something you are doing which I was not testing.

Thank you