| Issue 335: | pyodbc.connect crashes in iODBC library on Mac OSX 10.8 | |
| 2 people starred this issue and may be notified of changes. | Back to list |
What steps will reproduce the problem?
1. pyodbc.connect(dsn) (where dsn is a string that still works in iodbctest)
2. analyze the OSX crash dump
3. look at the odbc Trace log
What is the expected output? What do you see instead?
Expected: pyodbc.connect is successful in OSX 10.6. Virtuoso plug-in works too.
Instead: Segmentation fault: 11
Process: Python [24602]
Path: /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier: Python
Version: 2.7.2 (2.7.2)
Code Type: X86-64 (Native)
PlugIn Path: /Library/Python/2.7/site-packages/pyodbc.so
PlugIn Identifier: pyodbc.so
PlugIn Version: ??? (0)
Date/Time: 2013-08-29 09:26:21.339 -0400
OS Version: Mac OS X 10.8.4 (12E55)
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007f8700000000
VM Regions Near 0x7f8700000000:
SBRK (reserved) 000000010c221000-000000010c621000 [ 4096K] rw-/rwx SM=NUL reserved VM address space (unallocated)
-->
MALLOC_TINY 00007f87ea400000-00007f87ea500000 [ 1024K] rw-/rwx SM=COW
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libiodbc.2.dylib 0x000000010c017358 SQLFreeStmt + 76
1 pyodbc.so 0x000000010bfe6806 GetConnectionInfo(_object*, Connection*) + 668
2 pyodbc.so 0x000000010bfe6dbf Connection_New(_object*, bool, bool, bool, long) + 987
3 pyodbc.so 0x000000010bfed13b mod_connect(_object*, _object*, _object*) + 1536
4 org.python.python 0x000000010b3a45a9 PyEval_EvalFrameEx + 9244
odbc Trace logs:
I traced a working (10.6, or iodbctest) and nonworking (10.8) connect session and found that the SQLDriverConnectW entry does and does not print out the connect string, respectively. The python test code is the very same, and in OSX 10.8 pyodbc is not getting the connect string to iODBC. With iodbctest, the log is normal even on 10.8.
What version of the product are you using? On what operating system?
pyodbc 3.0.7 built per setup.py instructions (previously 2.1.9 patched for Virtuoso plug-in described below)
python 2.7.2 (2.6 fails too)
OSX 10.8.4 (two separate 10.8 machines same result, 10.6 machine is fine)
Xcode 4.6.3
iODBC 3.52.8 develop branch built with 10.8 GitHub instructions (previously native or 3.52.7 dmg for 10.5)
Note: The crash occurs at the same location with the new Framework library or the previous /usr/lib/libiodbc.dylib library. I pointed to the /usr/local/iODBC/lib libraries in the pyodbc setup.py, but the crash is from the framework.
Please provide any additional information below.
I have been running with the following:
OSX 10.6 with the iODBC 3.52.7 dmg build on the web site, pyodbc (sudo pip install http://river.styx.org/ww/2010/10/pyodbc-spasql/pyodbc-virtuoso-2.1.9-beta14.tar.gz), and the Virtuoso 0.12.6 plug-in (https://pypi.python.org/pypi/virtuoso) for Python.
The same setup on 10.8 crashes with these libraries or the latest iODBC and pyodbc built for OSX 10.8.
I have posted this error on GitHub, Sourceforge, and Apple forums. I am dependent on this library and need a fix or alternative python method to work with a Virtuoso RDF store. I like working with python objects via ODBC and don't want to go the http route. Thanks.
Sep 5, 2013
Debugging results: HSTMT is being partially cleared, causing the crash, or because of the crash?
Crash with debug:
Process: Python [42876]
Path: /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier: Python
Version: 2.7.2 (2.7.2)
Code Type: X86-64 (Native)
Parent Process: bash [41246]
User ID: 501
PlugIn Path: /Library/Frameworks/iODBC.framework/Versions/3.52/iODBC
PlugIn Identifier: org.iodbc.core
PlugIn Version: iODBC version 3.52.8 (3.52.8)
Date/Time: 2013-09-05 15:36:42.607 -0400
OS Version: Mac OS X 10.8.4 (12E55)
Report Version: 10
Sleep/Wake UUID: 96EAA5FF-2AF0-41B2-8E1E-666763EB78FE
Interval Since Last Report: 16466 sec
Crashes Since Last Report: 2
Per-App Crashes Since Last Report: 1
Anonymous UUID: 0962DF20-07FF-9AD6-5822-9830A1F295E9
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007fc300000000
VM Regions Near 0x7fc300000000:
SBRK (reserved) 000000010b259000-000000010b659000 [ 4096K] rw-/rwx SM=NUL reserved VM address space (unallocated)
-->
MALLOC_TINY 00007fc338c00000-00007fc338d00000 [ 1024K] rw-/rwx SM=COW
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 org.iodbc.core 0x000000010aa64676 SQLGetTypeInfo + 70
1 pyodbc.so 0x000000010aa3cda1 GetConnectionInfo(_object*, Connection*) + 719 (cnxninfo.cpp:131)
2 pyodbc.so 0x000000010aa3d2fa Connection_New(_object*, bool, bool, bool, long, bool) + 926 (wrapper.h:17)
3 pyodbc.so 0x000000010aa439a0 mod_connect(_object*, _object*, _object*) + 1745 (pyodbcmodule.cpp:371)
4 org.python.python 0x000000010a5d55a9 PyEval_EvalFrameEx + 9244
Source code:
HSTMT hstmt = 0;
if (SQL_SUCCEEDED(SQLAllocHandle(SQL_HANDLE_STMT, cnxn->hdbc, &hstmt)))
{
SQLINTEGER columnsize;
if (SQL_SUCCEEDED(SQLGetTypeInfo(hstmt, SQL_TYPE_TIMESTAMP)) && SQL_SUCCEEDED(SQLFetch(hstmt)))
if (SQL_SUCCEEDED(SQLGetData(hstmt, 3, SQL_INTEGER, &columnsize, sizeof(columnsize), 0)))
p->datetime_precision = (int)columnsize;
**LINE 131:** if (SQL_SUCCEEDED(SQLGetTypeInfo(hstmt, SQL_VARCHAR)) && SQL_SUCCEEDED(SQLFetch(hstmt)))
if (SQL_SUCCEEDED(SQLGetData(hstmt, 3, SQL_INTEGER, &columnsize, sizeof(columnsize), 0)))
p->varchar_maxlength = (int)columnsize;
iodbc trace log of that piece of code until crash:
python 7FFF758C0180 ENTER SQLAllocHandle
SQLSMALLINT 3 (SQL_HANDLE_STMT)
SQLHANDLE 0x7fe03a4e2c30
SQLHANDLE * 0x7fff5fbbf0e8
python 7FFF758C0180 EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS)
SQLSMALLINT 3 (SQL_HANDLE_STMT)
SQLHANDLE 0x7fe03a4e2c30
SQLHANDLE * 0x7fff5fbbf0e8 (0x7fe03a674230)
python 7FFF758C0180 ENTER SQLGetTypeInfo
SQLHSTMT 0x7fe03a674230
SQLSMALLINT 93 (SQL_TYPE_TIMESTAMP)
python 7FFF758C0180 EXIT SQLGetTypeInfo with return code 0 (SQL_SUCCESS)
SQLHSTMT 0x7fe03a674230
SQLSMALLINT 93 (SQL_TYPE_TIMESTAMP)
python 7FFF758C0180 ENTER SQLFetch
SQLHSTMT 0x7fe03a674230
python 7FFF758C0180 EXIT SQLFetch with return code 0 (SQL_SUCCESS)
SQLHSTMT 0x7fe03a674230
python 7FFF758C0180 ENTER SQLGetData
SQLHSTMT 0x7fe03a674230
SQLUSMALLINT 3
SQLSMALLINT 4 (SQL_C_LONG)
SQLPOINTER 0x7fff5fbbf0e4
SQLLEN 4
SQLLEN * 0x0
python 7FFF758C0180 EXIT SQLGetData with return code 0 (SQL_SUCCESS)
SQLHSTMT 0x7fe03a674230 ***Cleared below***
SQLUSMALLINT 3
SQLSMALLINT 4 (SQL_C_LONG)
SQLPOINTER 0x7fff5fbbf0e4
SQLLEN 4
SQLLEN * 0x0
python 7FFF758C0180 ENTER SQLGetTypeInfo
SQLHSTMT 0x7fe000000000 ***Note that HSTMT has been partially cleared***
SQLSMALLINT 12 (SQL_VARCHAR)
So, does the HSTMT being cleared cause the crash, or does the crash get caught in the trace log? Reminder, it crashes in a similar location in both 3.07 and 2.1.9 pyodbc, just after the allocation and a couple of calls.
Thanks
|
I see that my dump above is from my previous library, here is the one from the rebuilt frameworks. They both abort on the same call: Process: Python [33693] Path: /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: 2.7.2 (2.7.2) Code Type: X86-64 (Native) Parent Process: bash [30479] User ID: 501 PlugIn Path: /Library/Frameworks/iODBC.framework/Versions/3.52/iODBC PlugIn Identifier: org.iodbc.core PlugIn Version: iODBC version 3.52.8 (3.52.8) Date/Time: 2013-08-29 11:54:46.908 -0400 OS Version: Mac OS X 10.8.4 (12E55) Report Version: 10 Interval Since Last Report: 28580 sec Crashes Since Last Report: 20 Per-App Crashes Since Last Report: 13 Anonymous UUID: 0962DF20-07FF-9AD6-5822-9830A1F295E9 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00007fa000000000 VM Regions Near 0x7fa000000000: SBRK (reserved) 000000010fd7c000-000000011017c000 [ 4096K] rw-/rwx SM=NUL reserved VM address space (unallocated) --> MALLOC_TINY 00007fa0a9400000-00007fa0a9500000 [ 1024K] rw-/rwx SM=COW Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 org.iodbc.core 0x000000010fb5a73c SQLGetTypeInfo + 76 1 pyodbc.so 0x000000010fb33da1 GetConnectionInfo(_object*, Connection*) + 719 2 pyodbc.so 0x000000010fb342fa Connection_New(_object*, bool, bool, bool, long, bool) + 926 3 pyodbc.so 0x000000010fb3a9a0 mod_connect(_object*, _object*, _object*) + 1745 4 org.python.python 0x000000010eef45a9 PyEval_EvalFrameEx + 9244 Here are comparisons of the odbc.log. The connect string is not printed in the 10.8 log, so I don't know if iODBC did not receive it, or if the tracing omitted it. The 10.6 log continues, the 10.8 log aborts prematurely. 10.8 (connection string absent) python 7FFF758C0180 ENTER SQLDriverConnectW SQLHDBC 0x7fe32221b570 SQLPOINTER 0x0 SQLWCHAR * 0x7fe32219a1e0 SQLSMALLINT 29 SQLWCHAR * 0x0 SQLSMALLINT 0 SQLSMALLINT * 0x0 SQLUSMALLINT 0 (SQL_DRIVER_NOPROMPT) python 7FFF758C0180 EXIT SQLDriverConnectW with return code 0 (SQL_SUCCESS) SQLHDBC 0x7fe32221b570 SQLPOINTER 0x0 SQLWCHAR * 0x7fe32219a1e0 SQLSMALLINT 29 SQLWCHAR * 0x0 SQLSMALLINT 0 SQLSMALLINT * 0x0 SQLUSMALLINT 0 (SQL_DRIVER_NOPROMPT) 10.6: (connection string present) [000000.000406] python 7FFF70296CC0 ENTER SQLDriverConnectW SQLHDBC 0x100278390 SQLPOINTER 0x0 SQLWCHAR * 0x1010c94d0 | DSN=VTKB;UID=dba;PWD=************** | SQLSMALLINT 35 SQLWCHAR * 0x0 SQLSMALLINT 0 SQLSMALLINT * 0x0 SQLUSMALLINT 0 (SQL_DRIVER_NOPROMPT) [000000.080776] python 7FFF70296CC0 EXIT SQLDriverConnectW with return code 0 (SQL_SUCCESS) SQLHDBC 0x100278390 SQLPOINTER 0x0 SQLWCHAR * 0x1010c94d0 SQLSMALLINT 35 SQLWCHAR * 0x0 SQLSMALLINT 0 SQLSMALLINT * 0x0 SQLUSMALLINT 0 (SQL_DRIVER_NOPROMPT)