search

WanderInCode / pyodbc

Automatically exported from code.google.com/p/pyodbc
MIT No Attribution
0 stars 0 forks source link

pyodbc.connect crashes in iODBC library on Mac OSX 10.8 #335

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
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/Co
ntents/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.

Original issue reported on code.google.com by rufustsp...@gmail.com on 29 Aug 2013 at 2:00

GoogleCodeExporter commented 8 years ago 
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/Co
ntents/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)

Original comment by rufustsp...@gmail.com on 29 Aug 2013 at 4:19

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
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/Co
ntents/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

Original comment by spenc...@bellsouth.net on 5 Sep 2013 at 10:24