[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.
-- 
Nick




More information about the unixODBC-support mailing list