[DB-SIG] ctsybase module coredump
Fri, 10 Jul 1998 10:21:43 -0700 (PDT)
On Fri, 10 Jul 1998, Harri Pasanen wrote:
> It seems that if I don't read all the data from a cursor,
> but instead execute() another statement, the ctsybase module
> causes python to dump core.
> It does is at the point marked by <----, line 168 of ctsybase.c
> CS_RETCODE CS_PUBLIC
> PySybConnection_clientmsgcallback(CS_CONTEXT *context, CS_CONNECTION
> *connection, CS_CLIENTMSG *clientMsg)
> PyObject * argument, *result;
> if (currentConnection->clientMsgCallback == Py_None) <--- dumps
> return CS_SUCCEED;
> Looking with gdb looks like currentConnection is NULL.
> What I'm trying to do is:
> To get a description of a table I have to fetch atleast one row.
> Provided on the type of the columns in the table has I may
> either proceed to do other query, or read the rest of the rows.
> Problem is, that if I proceed to do the other query without
> reading in all the results of my first query,
> I get the above core dump.
> Any suggestions or patches to ctsybase.c ?
Here's a quick patch that I know will fix the immediate problem.
Unfortunately I don't have the means to test it (anyone have a copy of
Sybase 10 they'd like to donate?)
change the line to
if (!currentConnection || currentConnection->clientMsgCallback == Py_None)
However, the fact that the inline error handler is being called indicates
there's probably a client state error in the state machine, which means
after you fix this, the command will return with an error (probably)
(either that or an informational message).
The problem immediately is that currentConnection is a static used for the
sake of switching the sybase async error handler point to the right
handler for the current connection at all times. Currently, I think we're
at a point in the state machine where there is no connection. This is
probably indicative of a serious problem. I'll be interested to see what
happens when you make this change.
> DB-SIG maillist - DB-SIG@python.org