Re: Finally a core bt!

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@lists.php.net For help: php-dev-help@lists.php.net