> I've been encountering various failures leading to application crash. They
> all seem to be caused by some memory corruption bugs. I tried to figure
> out the fix, but I couldn't. I would really appreciate your help!
>
> I'm using the latest release psqlodbc-09.03.0400 on Windows. The
> application is multi-threaded 32-bit program. The threads are independent
> workers, each of which uses ADO to perform simple data access:
I've just been able to solve this issue. There were some bugs in psqlODBC and a communication library we are using.
Letme explain those.
> (6) Abrupt socket close
> Throughout the test, these messages are frequently output in the PostgreSQL
> server log file:
>
> LOG: could not receive data from client: No connection could be made
> because the target machine actively refused it.
> LOG: unexpected EOF on client connection
The communication library (not psqlODBC) mistakenly closed the same socket twice. Depending on the timing, that ended
upclosing a live socket which is being used for psqlODBC-postgres communication. This is the beginning of all
mysteriouscrashes.
The sudden socket closure causes send()/recv() in psqlODBC to fail, leading to QR_next_tuple() and CC_fetch_tuples()
failures. When CC_fetch_tuples() fails in CC_send_query_append(), the following code fragment sets cmdres to retres.
Here,cmdres is just initialized and so has no error information.
[connection.c]
if (!CC_fetch_tuples(res, self, cursor, &ReadyToReturn, &kill_conn))
{
if (QR_command_maybe_successful(res))
retres = NULL;
else
retres = cmdres;
aborted = TRUE;
}
Returning from CC_send_query_append(), SC_execute() treats the result as success. But the returned QResult has no
informationabout DECLARE+FETCH results. Finally, SC_execute() accesses the memory just freed by itself.
This problem does not occur with psqlodbc-09.05.0100. I confirmed it by reviewing the source code and actually running
thesame test.
> (5) NULL dereference
> The following line in SC_create_errorinfo() (statement.c) caused the crash.
> pgerror was NULL. That means that malloc() in ER_Constructor() failed.
> NULL check is necessary somewhere.
>
> strcpy(pgerror->sqlstate, EN_is_odbc3(env) ?
>
> Statement_sqlstate[errornum].ver3str :
>
> Statement_sqlstate[errornum].ver2str);
This bug still exists in the latest psqlodbc-09.05.0100. I'll submit the patch later.
Regards, Takayuki Tsunakawa
