segfault on query errors

[matt knox]

Hi there,

I am encountering sporadic segfaults on process exit sometimes after a
call to "execute" with a query that generates an exception (eg. query
syntax error, primary key violation, anything really). The process
appears to exit normally and all code gets executed in any exception
handling logic I have, but when the process exits I get the segfault
crash dialog pop-up on windows for python. So it sounds like something
wierd going on in the garbage collection process after an exception is
generated, a reference count problem perhaps?

I can't seem to produce a compact stand alone example, it only ever
seems to happen during an exception in more involved processes where I
have called a bunch of queries. It is definitely in pyodbc because I
have recently switched from ceODBC and never experienced any segfaults
on the same code (although ceODBC had some other problems which caused
me to switch) and I have seen it happen enough that the cause has
become readily apparent. I am not a C / C++ coder so I can't offer
much insight beyond that unfortunately.

Has anyone else experienced this? Any ideas?

I am running the latest released version of pyodbc on python 2.6,
windows server 2003, sql server 2005.

Any insight would be greatly appreciated. Thanks.

- Matt

[matt knox]

I managed to come up with a very small self contained example that
demonstrates the segfault. It happens when trying to close a
connection after executing a query that raises an exception. Note that
it does not happen for ALL exceptions, only some (including the
example below)

=======================================

import pyodbc

dsn = \
'uid=myid;Database=mydb;Driver={SQL Native Client};'\
'Server=myserver;pwd=mypwd;'

conn = pyodbc.connect(dsn)

try:

crs = conn.cursor()
crs.execute("SELECT [fake_field], ?", "abc")

finally:
conn.close()

[matt knox]

> import pyodbc
>
> dsn = \
>     'uid=myid;Database=mydb;Driver={SQL Native Client};'\
>     'Server=myserver;pwd=mypwd;'
>
> conn = pyodbc.connect(dsn)
>
> try:
>
>     crs = conn.cursor()
>     crs.execute("SELECT [fake_field], ?", "abc")
>
> finally:
>     conn.close()

Not sure if anyone is reading this... but just to add as much info as
I have... I added some "printf" statements in the code to see where it
was segfaulting (that is about the extent of my debugging skills in C/C
++), and it looks like it is on line 28 in params.cpp:

SQLFreeStmt(cur->hstmt, SQL_RESET_PARAMS);

This happens during the garbage collection it looks like. So the
calling sequence is:

Cursor_dealloc -> closeimpl -> FreeParameterData -> SQLFreeStmt

And I don't think the "conn.close()" call in my example is actually
necessary to demonstrate the segfault. If anyone knowledgeable in C/C+
+ is reading this and has any ideas, would appreciate the info.
Otherwise, have a good day!

- Matt

[mkleehammer]

Wow - thanks for the detail.

I'll try to get on this as soon as I can. Perhaps tonight or this
weekend.