Re: [PHP-DEV] Finally a core bt! From: Andreas Karajannis (Andreas.Karajannis <email protected>)
Date: 01/20/99

Michael Brennen wrote:
>
> I've periodically pulled the latest cvs tree and have still had
> trouble with the ODBC/Solid drivers occasionally faulting. I was
> poking around /etc/profile on this machine today for other reasons and
> happened to notice a 'ulimit -c 0' statement in there (this is the
> latest Suse Linux, less familiar to me than RH). I pulled that line
> out and *finally* have a core backtrace to send. It is below.
>
> -- Michael
>
> (gdb) bt
> #0 0x4002dfd7 in SQLTransact ()
> #1 0x808c7a5 in _free_result (res=0x8286100) at functions/unified_odbc.c:189
> #2 0x8064b1a in list_entry_destructor (ptr=0x8286d50) at list.c:99
> #3 0x805f7a4 in _php3_hash_del_key_or_index (ht=0x823385c, arKey=0x0,
> nKeyLength=0, h=6, flag=1) at php3_hash.c:608
> #4 0x8064aa8 in php3_list_do_delete (list=0x823385c, id=6) at list.c:75
> #5 0x808cb53 in php3i_odbc_del_result (list=0x823385c, ap_ind=6)
> at functions/unified_odbc.c:463
> #6 0x808e23a in php3_odbc_free_result (ht=0x82afd70, return_value=0x821e01c,
> list=0x823385c, plist=0x8233830) at functions/unified_odbc.c:1655

The coredump happens in SQLTransact, which is in the solid client
libs. SQLTransact gets called on freeing a statement only for
Solid and was introduced due to some Solid specific behaviour.

So in short: To me, it seems to be a bug in the Solid libraries.

Did you perform a rollback or commit in your script before calling
odbc_free_result()?
Maybe Solid doesn't like doing things twice ;-)

-Andreas 

-- 
Andreas Karajannis
GMD National Research Center for Information Technology
Schloss Birlinghoven, D-53754 Sankt Augustin
Phone +49 2241 142948

--
PHP Development Mailing List   http://www.php.net/
To unsubscribe send an empty message to php-dev-unsubscribe <email protected>
For help: php-dev-help <email protected>