[unixODBC-support] Another segfault in libodbccr.so on x86_64
unixodbc.org at zetafleet.com
Sun Dec 23 02:25:53 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 :-)
Unfortunately with the PDO ODBC extension, switching from
SQL_CUR_USE_IF_NEEDED to SQL_CUR_USE_DRIVER causes some really strange
and broken behaviour in PHP (things I've never seen, like a single
variable containing 2 PDOStatement objects and a boolean FALSE).
Actually, the extension itself doesn't expose these options for change
from within PHP (though it does set some constants for them, which is a
little odd), so I suppose it makes sense that simply trying to change it
in the extension source would cause problems.
Believe me, I would be happy to not work with MSSQL at all in this
manner, but it's a requirement from a client. :( I tried using the PDO
DBLIB extension instead, but it has the same problem of not supporting
NTEXT columns, and also it sounds like they're going to want to deploy
this on the same Windows server that's running the database (and the
Windows DBLIB is unmaintained and considered obsolete).
Anyway, please let me know once you get a chance to take a look at this.
Obviously I'd like to get this addressed as soon as possible since it's
preventing me from doing my own work, but I don't want to encroach on
your weekend nor your holiday, so take your time.
More information about the unixODBC-support