MySQL Bugs: #2566: SIGPIPE on reconnect from MyODBC needs mutex

Bug #2566	SIGPIPE on reconnect from MyODBC needs mutex
Submitted:	29 Jan 2004 18:18	Modified:	9 Nov 2007 15:33
Reporter:	Boyd Gerber	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	3.51.07	OS:	Any (All)
Assigned to:		CPU Architecture:	Any

Description:
Set server timeout to 5-6 seconds

INSTRUCTIONS FOR USING
======================
Before compiling, make sure that you run setup33.sol to source the environment.

1. To compile to the program say "sh compile.sh"

2. To run the program "./db_test"

3. This program will be keep on running till you press ctrl+c

4. Only when started, it will insert 1000 records into the database after emptyi
ng the table.

5. The moment you press ctrl+c, it will execute "SELECT" and show you the table
contents.

6. ALWAYS MAKE SURE THAT you use _r libraries of mysql to link in compile.sh scr
ipt.

7. To start the mysql server say "sh start.sh"

8. To stop the mysql server say "sh stop.sh"

9. If you get new set libraries or include files, replace them under include and
 lib directories inside 4.0.16 directory.

How to repeat:
see above

Suggested fix:
Add mutex to wrap MyODBC

gzip tar files for this problem

Attachment: dbtest.tar.gz (application/x-gunzip, text), 13.29 KiB.

http://www.bitmechanic.com/mail-archives/modperl/Mar1999/0320.html

Hi Boyd,

I tried a lot to reproduce the scenario. By using MySQL 5.1.21, libiodbc 3.52.5 and MyODBC 3.51.21 and I can't reproduce it.

Also I am not really understand, what should happened after 10 hours waiting and what the specific error should be?

Unfortunately the given mail archive link don't exist anymore and it seems, that there were more information written, that could be helpful.

Do you have a newer link for me or can you try this again with the newer versions of MySQL and MyODBC and give us the feedback?

Kind Regards,

Susanne

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".

I can reproduce this by using MyODBC v5.1, MySQL server 5.1.22 on FreeBSD.

I'll attach my C test programm and the trace from last night. I started round about at 19:15 in the evening and stopped it at 8:30 in the morning.

It fails during SQLPrepare (line 402 at the C programm).

[08S01][[MySQL][ODBC 5.1 Driver][mysqld-5.1.22-rc]MySQL server has gone away]

For comparing, I'll also add a trace file, that I got today morning, after a second run of the programm and stopping this after round about 1 minute (runs successfully).

The differences at the trace files start at line 1105.

I'll make more tests, to make sure, that this is really a MyODBC problem and not something else. 

Also I'll make a test with the newest v3.51 version but I expect the same behaviour there.

this is the C test programm. Compiled with gcc -g -Wall -I /usr/local/include/ -o bug2566 bug2566.c -L /usr/local/lib -liodbc

Attachment: bug2566.c (text/x-csrc), 14.73 KiB.

this is the trace file after stopping the programm after more then 10 hours (occurs error)

Attachment: bugs.odbc5.mysql.20071107-192552.trace (application/octet-stream, text), 34.33 KiB.

Trace after stopping after round about one minute. The differences of both trace files start at line 1105 at the files

Attachment: bugs.odbc5.mysql.20071108-104136.trace (application/octet-stream, text), 36.29 KiB.

This is not a bug.
MySQL don't have unlimited connections.
The connection got terminated after wait_timeout seconds.
The default for wait_timeout is 8 hours.
MyODBC doesn't support an automatic re-connect.

After testing under HP-UX, I really can't reproduce a SIGPIPE. The only error I get, is a typical error, that occurs after wait_timeout.

It seems, this bug has been fixed by accident during the last time.