[unixODBC-support] Another segfault in libodbccr.so on x86_64 [Partial resolution]
unixodbc.org at zetafleet.com
Wed Dec 26 20:18:20 GMT 2007
Nick Gorham wrote:
> Colin Snover wrote:
>> Hello again. (What, so soon?)
>> After resolving the first segfault that was occurring by using the CVS
>> source, now that I have configured the proper TDS version I've stumbled
>> upon another crash.
>> I've had this crash occur in different places (as you can see below) but
>> always within the same function. I've attached two backtraces. The first
>> backtrace is conducted against a query that had been working when the
>> TDS Version was at its default (4.2); the second backtrace is conducted
>> against a query that would fail (SQLError 4004) when TDS Version was 4.2
>> because of an NTEXT column.
>> Currently, neither execution gets far enough to actually make it to the
>> data query (the thing that used to fail with TDS Version 4.2) -- only
>> the metadata stored procedure is called before unixODBC dies. Normally,
>> there would be a second query to "SELECT TOP 1 * FROM <table>".
>> I've also attached two gzipped Trace logs corresponding to each
>> backtrace; hopefully they help shed more light on this.
> I will take a look later.
> Does it work when you don't use the cursor lib? or is that essential
> to what you are doing?
> I could suggest trying another driver, but that is a bit biased of me :-)
Hi again Nick,
I ended up managing to isolate this problem to (I think) be caused by
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.
More information about the unixODBC-support