[unixODBC-support] Another segfault in libodbccr.so on x86_64 [Partial resolution]

Nick Gorham nick.gorham at easysoft.com
Wed Dec 26 20:34:07 GMT 2007

Colin Snover wrote:

>I ended up managing to isolate this problem to (I think) be caused by
>pdo_odbc. :(
>odbc_stmt.c:422 branches depending upon whether or not the column is
>"long" data ("long" columns being those that hold > 256 bytes), but
>doesn't call SQLBindCol in the case that it is "long" data, resulting in
>cases when not all bound_columns are set correctly. SQLGetData still
>expects all the columns to be bound though, resulting in a crash (due to
>a NULL pointer). I'm not sure what the best way to fix this is, but I'm
>reporting it as a bug to PHP. Hopefully someone there knows; for right
>now I've just commented out the branch in their code, but this will be a
>problem because then it will allocate potentially a lot of memory.
>It seems that it might be a good idea to add to unixODBC a check around
>SQLGetData.c:472 to ensure that bound_columns -> next is not a NULL
>pointer before trying to use it and throw an error if it is.
Thanks for that, I will add that check.

The MS (and Easysoft) SQLServer driver does some refetching for long 
columns in scrollable cursors, avoiding the need for the cursor lib.

More information about the unixODBC-support mailing list