ID: 45894
User updated by: ashoat at gmail dot com
Reported By: ashoat at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: ODBC related
Operating System: CentOS 5.2 x64_86
PHP Version: 5.2.6
New Comment:
Attached is the backtrace. Note that the segfault is not generated
unless a force-close the command-line php interpreter by hitting
Ctrl+C.
(gdb) bt
#0 0x000000308dab93d0 in ?? ()
#1 <signal handler called>
#2 0x0000003a2c80c898 in __lll_mutex_lock_wait () from
/lib64/libpthread.so.0
#3 0x0000003a2c80a315 in _L_mutex_lock_18 () from
/lib64/libpthread.so.0
#4 0x0000003a2c80a273 in pthread_cond_destroy@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
#5 0x0000003a340269fb in my_thread_global_end () at my_thr_init.c:216
#6 0x0000003a34022265 in my_end (infoflag=0) at my_init.c:205
#7 0x0000003a3402100f in mysql_server_end () at libmysql.c:197
#8 0x000000000061f546 in zm_shutdown_mysql (type=1, module_number=21,
tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/ext/mysql/php_mysql.c:426
#9 0x00000000008879fc in module_destructor (module=0x193015e0)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_API.c:1921
#10 0x000000000088df4b in zend_hash_apply_deleter (ht=0xf37700,
p=0x19301580)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_hash.c:611
#11 0x000000000088e0b7 in zend_hash_graceful_reverse_destroy
(ht=0xf37700)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_hash.c:646
#12 0x000000000087cea7 in zend_shutdown (tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend.c:733
#13 0x000000000080476f in php_module_shutdown (tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/main/main.c:1888
#14 0x000000000091a396 in main (argc=2, argv=0x7ffff8753f88)
Previous Comments:
------------------------------------------------------------------------
[2008-08-22 21:55:58] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
------------------------------------------------------------------------
[2008-08-22 20:09:46] ashoat at gmail dot com
Description:
------------
I have PHP 5.2.6 compiled as CGI wrapped with suPHP installed on a
CentOS 5.2 x64_86 box. I compiled PHP with --with-unixODBC, version
2.2.11.
After I open an ODBC connection and then close it, I am able to
continue executing PHP code. However, when it is time to cleanup and
exit the script, the parser stalls and does not close the stream.
This has been tested through the commandline and httpd. When I force
close the command-line executor after the cleanup stalls, I get
"Segmentation fault" appended to the end of the stream before it closes.
Reproduce code:
---------------
<?php
$connection = odbc_connect("DRIVER={MySQL ODBC 3.51
Driver};Server=localhost;Database=database;Option=3","username","password");
odbc_close($connection);
for($i=0;$i<25;$i++) echo "This is <b>after</b> the connection is
closed.<br/>";
echo "Something is clearly wrong with PHP's cleanup.";
?>
Expected result:
----------------
The expected result is that the code executes and the stream then
closes.
If the ODBC functions caused a block and did not close, a timeout would
be expected and the code towards the end of the file would not execute.
However, the code at the end does execute (see here:
http://www.heliohost.org/test.php).
Therefore, it seems that the issue here is with PHP's cleanup methods.
Actual result:
--------------
See here: http://www.heliohost.org/test.php
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=45894&edit=1
