Bug #30060 SQLFreeHandle error, the program die
Submitted: 26 Jul 2007 4:00 Modified: 30 May 2013 6:48
Reporter: ming lu Email Updates:
Status: Closed Impact on me:
Category:Connector / ODBC Severity:S2 (Serious)
Version:3.51.17 OS:Windows (Windows 2000, Windows XP)
Assigned to: CPU Architecture:Any

[26 Jul 2007 4:00] ming lu
I have an odbc test program against to mysql odbc v3.51.17. It run properly on some windows system, but it occur a error when execute SQLFreeHandle(SQL_HANDLE_ENV, henv) on the other windows system, this statement will cause the program die. 


How to repeat:
This problem couldn't recur on every windows system, it seemed to happened on some complex environment windows system that installed many software.
[31 Jul 2007 19:42] Tonci Grgin
Hi Lu and thanks for your report. I think you are aware that it's impossible to work on it with so little data provided... Please attach more info (MDAC, server logs, ODBC trace ...).

I will take a wild guess now, do you by any chance use FireBird ODBC driver on failing machines?
[1 Aug 2007 11:13] ming lu
I debug the odbc driver by myself. I find the problem maybe caused by the function "my_end()" provided by libmysql. 

The function my_end() is called by the function myodbc_end() in the file "mysql-connector-odbc-3.51.17\driver\dll.c".  In some machines, this function can work normally, but in the others the function can not return for ever, it cause the application die.  But i don't find the rule of this phenomena, so i can not make sure that what environment will cause the error.

I am not familiar with the mysql server code, so i can't find the problem of the "my_end()" function until now. I guess it maybe caused by some thread that cann't be exit normally.
[1 Aug 2007 11:21] ming lu
I think the problem should by classified to Server bugs, isn't it?
I compiled the mysql odbc 3.51.17 by mysql server 5.0.19 and mysql server 5.1.19, the problem exists in the two versions.
[6 Aug 2007 7:13] Tonci Grgin
Lu, I can agree this looks like server bug but I checked the functions involved and I see no apparent problem there. Can you please attach my.ini file and output of "netstat /a" (from cmd prompt) & "show processlist" (from mysql command line client) at the time error occurs?
[6 Aug 2007 10:03] ming lu
I run the "netstat /a" command three times on the windows command line, and the relative output results:

 The 1st time: before the test program run
  Proto  Local Address          Foreign Address        State
  TCP    luming:3306            luming:0               LISTENING

 The 2nd time: at the time error occurs
  Proto  Local Address          Foreign Address        State
  TCP    luming:3306            luming:0    	       LISTENING
  TCP    luming:2415            luming:3306            ESTABLISHED
  TCP    luming:3306            luming:2415            ESTABLISHED
  TCP    luming:3306            luming:2418            TIME_WAIT
(note: the connection of "luming:2415" should be mysql command line client's connect)

 The 3rd time: after a while
  Proto  Local Address          Foreign Address        State
  TCP    luming:3306            luming:0               LISTENING

"show processlist" command returns the same result at the all times.

mysql> show processlist;
| Id | User | Host           | db   | Command | Time | State | Info
|  1 | root | localhost:2415 | NULL | Query   |    0 | NULL  | show processlist
1 row in set (0.00 sec)
[6 Aug 2007 10:05] ming lu

Attachment: my.ini (application/octet-stream, text), 8.93 KiB.

[6 Aug 2007 10:08] ming lu
the screen copy picture when i run the  test program

Attachment: mysql_odbc_test.jpg (image/pjpeg, text), 90.36 KiB.

[6 Aug 2007 12:08] Tonci Grgin
Hi Lu. I don't see test case source attached... Still there is a high possibility that this is duplicate of Bug#25621 which has been fixed lately (see the post [7 Jul 15:41] Radek Tetík). If you provide me with test case I can check this report. Otherwise, I'll have to mark it as duplicate.
[7 Aug 2007 3:45] ming lu
The test case i used is the regressive testsuite provided by mysql odbc 3.51.17. Look at the /mysql-connector-odbc-3.51.17/test/*.c
[7 Aug 2007 9:32] ming lu
I think that the problem I reported is not same as the Bug#25621, that bug can be reproduced on any machines, isn't it? But this problem i reported doesn't occur on every machines, I cann't find the rule until now.

I debug it myself, I find that the error occurs on the following code:

#ifdef __WIN__
  if (have_tcpip)
#endif /* __WIN__ */
(note: in the function my_end() of libmysql)

The WSACleanup() function will not return for ever when error occur. But it works normally in other machines. Does this WindowsAPI works rely on some dlls or libs? 

Btw, I compiled the mysql odbc using the libmysql provided by mysql server 5.1.20 (the Bug#25621 should be fixed), but this problem still exists.
[7 Aug 2007 10:26] Tonci Grgin
Hi Lu and thanks for additional info provided! This truly seems like interesting problem (and with regards to Bug#28775 showing that debug output in case of such error is useless) so I'm consulting server devs right now.
[7 Aug 2007 10:48] Tonci Grgin
Lu, can you please check description / version of file windir\system32\ws2_32.dll on machines that block and post that info?

Ie., on my machine: c:\windows\system32\ws2_32.dll - Description: Windows Socket 2.0. 32-Bit DLL Company: MS corp. File Version: 5.1.2006.2180
[8 Aug 2007 1:50] ming lu
On the error machine:  C:\WINNT\system32\ws2_32.dll 
Description: Windows Socket 2.0 32-Bit DLL
Company: Copyright (C) Microsoft Corp. 1981-1999 
File Version: 5.0.2195.6601

But the machines that mysql odbc works normally have a same file.
The ws2_32.dll are the same on all of the test machines.

Btw, can you reproduce the error on your test machines?  On our machines, this error can repeat easily, about half of our machines have this problem. The only rule I can find is that all the machines installed OS freshly can works normally, some machines who's OS had been installed for a long time will occur this error. It seemd to be relative with some OS environments or system libraries.
[14 Aug 2007 6:24] Tonci Grgin
No Lu, I can't repeat (so far) but I think this needs some more attention.
[19 Aug 2007 14:12] Tonci Grgin
Ming, I really don't know what's wrong... We reviewed MS specs and your suspicious part of code should work normally with Windows Socket 2.0. (and you say all the machines have the same and appropriate version). Can you try with 3.51.19 and 5.1.22 and inform me of result? I have confirmed that bug#25621 *is fixed* there.
[22 Aug 2007 3:06] ming lu
Ok, I will try it again.
[22 Aug 2007 9:42] Tonci Grgin
Lu, please do. Waiting on your results.
[28 Aug 2007 6:31] ming lu
Sorry, I have some very important things to deal with recently, so the test for odbc v3.51.19 and server v5.1.22 delayed.

I compiled the odbc v3.51.19 with server v5.1.22 yesterday, but the problem still exists. It cann't work normally on some machines yet.
[28 Aug 2007 9:20] Tonci Grgin
Ming, until you narrow the problem down (ie. find out why do some machines exhibit this behavior) I really don't think there's anything more I can do. Waiting on your results.
[28 Sep 2007 23:00] Bugs System
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".
[30 May 2013 6:48] Bogdan Degtyariov
I'm closing this bug because I can not continue without feedback from the reporter. If you have new info, please reopen the report.