FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Rich Young wrote:
> (gdb) bt
> #0  0x0000003f6fd71f07 in memcpy () from /lib64/tls/libc.so.6
> #1  0x00000000004f8030 in _estrndup ()
> #2  0x0000002a98a82b2b in zif_odbc_result () from
> /usr/lib64/php4/odbc.so
...
> Unfortunately, I'm enough of a newbie here that I still don't understand
> whether this is a PHP or FreeTDS bug.  Any insight?

Unfortunately, no.  It says odbc.so (which belongs the DM, not FreeTDS)
eventually asked memcpy(3) to copy something, probably a NULL pointer, but
maybe _estrndup expects a null-terminated input and wasn't given one. 
Either way, it's impossible without a lot more information to know whether
the bad pointer/data came from FreeTDS or not.  

Asked to guess, I always guess it's FreeTDS's fault because PHP is a much
bigger project with a much bigger user base.  Besides, it's humble.  The
theory is usually that some function is behaving in a way that is
surprising the client.  But unless we know which function under what
circumstances, we don't have much to go on. 

A TDSDUMP log would at least show the result set being processed.  I'm not
sure that would tell us much.  In theory, with that information and enough
source code you could walk the stack of your dump figure out who passed
what to whom.  I wouldn't do that unless lives were at stake.  

You appear to be using 64-bit ODBC, which has some known issues.  

On the whole I wish you were using the mssql extension instead.  It uses
db-lib and so avoids one layer.  That would make it easier, but still not
easy.  :-(

--jkl