| Bug #68998 | Call to SQLFreeEnv() causes crash in myodbc5w | ||
|---|---|---|---|
| Submitted: | 18 Apr 2013 13:50 | Modified: | 2 Jun 2013 7:29 |
| Reporter: | david grant | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | Connector / ODBC | Severity: | S3 (Non-critical) |
| Version: | 5.2.4 | OS: | Windows |
| Assigned to: | Bogdan Degtyariov | CPU Architecture: | Any |
| Tags: | crash, myodbc5w, ODBC, SQLFreeEnv, windows | ||
[18 Apr 2013 13:50]
david grant
[19 Apr 2013 8:08]
Bogdan Degtyariov
Hi David, Thank you for a very detailed description of the problem. One thing is not completely clear for me though: You application called SQLFreeEnv() function, but the call stack goes further to SQLForeignKeysW(). However, freeing the ENV handler means that all connections belonging to it are closed and DBC handlers are freed. Before the connection is closed and freed all STMT statements are to be closed and freed as well. In other words, SQLForeignKeysW() cannot be called because it works on the statement level. The question is how that could happen at all? The application can leak memory if ENV is freed without releasing memory used for STMT. There can be all sorts of side effects including crashes. Can you check your code to make sure the deinitialization goes in three stages: 1. All STMTs are closed and freed (SQLFreeStmt()). 2. Then DBCs are closed and freed (SQLFreeConnect()). 3. Only after step 1 and 2 are done it is safe to free ENV (SQLFreeEnv()). Thanks.
[1 May 2013 16:43]
Shailendra Singh
Results of WinDbg analysis
Attachment: WinDbgAnalysis.txt (text/plain), 54.33 KiB.
[1 May 2013 16:44]
Shailendra Singh
Hi Bogdan, I am a colleague of David, and I am working with him to determine the reason behind why our application crashes with MySQL Connector/ODBC driver. Our application does allocate and deallocate resources as you have suggested in your comment, so I suspect that there may be problem with the Connector/ODBC driver. I have another reason to suspect why there may be a problem with the Connector/ODBC driver. I re-ran the test, but I used the debug version of myodbc5w.dll file with all debug symbols and line numbers which you posted for Bug #68771. I could get our application to crash again, and this time I also used the myodbc5w.pdb you provided for WinDbg analysis. The WinDbg results are attached (WinDbgAnalysis.txt) . Could you please take a look, particularly at the call stack? Regards, Shailendra
[2 May 2013 7:29]
Bogdan Degtyariov
Hi Shailendra, Thanks for your comment. First, I would like to go back to the crash in SQLFreeEnv(). You confirmed that your application does as I suggested: ENV handler is freed after DBC and STMT. If STMT is freed there is no way SQLForeignKeysW() can work normally because of an invalid handle. Needless to say that it is not documented anywhere why ODBC Driver manager (odbc32) would want to call SQLForeignKeysW() from SQLFreeEnv(). So, I guess the crash might happen because of invalid STMT handle. Does the crash inside SQLFreeEnv() occur on a regular basis?
[14 May 2013 9:00]
Bogdan Degtyariov
One more question. We have analyzed the stack once more and came to the conclusion that simple safe-guarding HSTMT against NULL is not going to help because the first (HSTMT) parameter is a non-NULL one: 0e7ff740 77b59950 744b0000 00000000 00000000 myodbc5w!SQLForeignKeysW+0x99b3a Seemingly the stack leads us to using NO_I_S=1 parameter, but in order to investigate this assumption I need your confirmation. The question is: are you using the option "Don't use INFORMATION_SCHEMA for metadata"? Or NO_I_S=1 in the connection string? Please let us know, so we could proceed with the issue resolution. Thanks.
[3 Jun 2013 1: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".
