#50382 [Fbk->Opn]: garbage collection crashes
ID: 50382 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3, 6 Assigned To: dmitry New Comment: The fix only works when compiled with --enable-debug (see your comment below). I'm happy to wait for the next 5.3.* RC of final... I'll test it when it is available and will reopen this call when the problem still exists. Previous Comments: [2010-01-13 12:38:24] j...@php.net Well, maybe you should try it and if it works, close this report? :) [2010-01-12 15:59:57] dirk at bean-it dot nl No crashes with version php5.3-200912310930 and --enable-debug in ./config, but I didn't get the crashes with 5.3 and --enable-debug. The reproduce code from bug #50519 works fine now. Still inconclusive until I can try it without --enable-debug, I guess. [2010-01-11 10:08:56] dmi...@php.net Please, check once again. [2009-12-31 18:24:01] j...@php.net You could try with --enable-debug in your configure line, Dmitry's fix was only for debug builds. [2009-12-31 10:58:49] dirk at bean-it dot nl Tried php5.3-200912310930 but no luck. My PHP also still segfaults with the reproduce code from bug #50519. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50382 -- Edit this bug report at http://bugs.php.net/?id=50382&edit=1
#50382 [Fbk->Opn]: garbage collection crashes
ID: 50382 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3, 6 Assigned To: dmitry New Comment: No crashes with version php5.3-200912310930 and --enable-debug in ./config, but I didn't get the crashes with 5.3 and --enable-debug. The reproduce code from bug #50519 works fine now. Still inconclusive until I can try it without --enable-debug, I guess. Previous Comments: [2010-01-11 10:08:56] dmi...@php.net Please, check once again. [2009-12-31 18:24:01] j...@php.net You could try with --enable-debug in your configure line, Dmitry's fix was only for debug builds. [2009-12-31 10:58:49] dirk at bean-it dot nl Tried php5.3-200912310930 but no luck. My PHP also still segfaults with the reproduce code from bug #50519. [2009-12-25 13:14:32] dmi...@php.net The bug #50519 is fixed, however, I can't be sure that this crash is caused by the same bug. Please check SVN snapshot. [2009-12-18 18:47:16] j...@php.net See bug #50519 which has identical backtrace with short reproducing script. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50382 -- Edit this bug report at http://bugs.php.net/?id=50382&edit=1
#50382 [Fbk->Opn]: garbage collection crashes
ID: 50382 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3, 6 Assigned To: dmitry New Comment: Tried php5.3-200912310930 but no luck. My PHP also still segfaults with the reproduce code from bug #50519. Previous Comments: [2009-12-25 13:14:32] dmi...@php.net The bug #50519 is fixed, however, I can't be sure that this crash is caused by the same bug. Please check SVN snapshot. [2009-12-18 18:47:16] j...@php.net See bug #50519 which has identical backtrace with short reproducing script. [2009-12-09 12:35:43] dirk at bean-it dot nl I'm going to prepare a server with the software. Please allow me a few days to arrange this. I'll email the details when things are ready. [2009-12-08 08:30:06] dmi...@php.net In case you can provide a long script with instruction it's an option too. It's not easy to identify the reason of crash caused by garbage collector and provide a short script. SSH access to a server where I can play with bug is also an option. ---- [2009-12-07 08:43:02] dirk at bean-it dot nl I can confirm that setting: zend.enable_gc=Off makes the crash go away. I'm still looking to pinpoint the problem. I hope I can provide a short script which crashes php. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50382 -- Edit this bug report at http://bugs.php.net/?id=50382&edit=1
#50382 [Asn]: garbage collection crashes
ID: 50382 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl Status: Assigned Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3.1 Assigned To: dmitry New Comment: I'm going to prepare a server with the software. Please allow me a few days to arrange this. I'll email the details when things are ready. Previous Comments: [2009-12-08 08:30:06] dmi...@php.net In case you can provide a long script with instruction it's an option too. It's not easy to identify the reason of crash caused by garbage collector and provide a short script. SSH access to a server where I can play with bug is also an option. [2009-12-07 08:43:02] dirk at bean-it dot nl I can confirm that setting: zend.enable_gc=Off makes the crash go away. I'm still looking to pinpoint the problem. I hope I can provide a short script which crashes php. [2009-12-06 15:23:28] srina...@php.net alternatively, you can also set "zend.enable_gc=Off" within your php.ini and this should make the crash go away as well. [2009-12-05 16:14:38] srina...@php.net from the bt, I guess, there is memory corruption within Zend engine. if you are able to reproduce this crash by running a modified version of your script from the command line, then , to help us more understand the problem, will it be possible for you to run it with valgrind --num- callers=15 --error-limit=no ./sapi/cli/php alternatively, if you export USE_ZEND_ALLOC=0 in your apachectl script, your server might run successfully albeit at decreased performance. thanks for your help -------- [2009-12-04 12:56:47] dirk at bean-it dot nl Up till now, I haven't been able to exactly pinpoint the problem. As mentioned below, our application works as expected, it looks likes Apache crashes -after- php has compiled the page. Very strange. The application is quite large, a lot of code. Tried to debug with Zend Debugger, but than things work as expected, no segfault. As much as I would like to give some example code, I cannot at this moment, since I have no clue where things go wrong (the app works fine!). Any suggestions on how to proceed are highly appreciated. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50382 -- Edit this bug report at http://bugs.php.net/?id=50382&edit=1
#50382 [Fbk->Opn]: Upgrading to php 5.3 > Application works but apache segfaults
ID: 50382 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3.1 New Comment: I can confirm that setting: zend.enable_gc=Off makes the crash go away. I'm still looking to pinpoint the problem. I hope I can provide a short script which crashes php. Previous Comments: [2009-12-06 15:23:28] srina...@php.net alternatively, you can also set "zend.enable_gc=Off" within your php.ini and this should make the crash go away as well. [2009-12-05 16:14:38] srina...@php.net from the bt, I guess, there is memory corruption within Zend engine. if you are able to reproduce this crash by running a modified version of your script from the command line, then , to help us more understand the problem, will it be possible for you to run it with valgrind --num- callers=15 --error-limit=no ./sapi/cli/php alternatively, if you export USE_ZEND_ALLOC=0 in your apachectl script, your server might run successfully albeit at decreased performance. thanks for your help [2009-12-04 12:56:47] dirk at bean-it dot nl Up till now, I haven't been able to exactly pinpoint the problem. As mentioned below, our application works as expected, it looks likes Apache crashes -after- php has compiled the page. Very strange. The application is quite large, a lot of code. Tried to debug with Zend Debugger, but than things work as expected, no segfault. As much as I would like to give some example code, I cannot at this moment, since I have no clue where things go wrong (the app works fine!). Any suggestions on how to proceed are highly appreciated. [2009-12-04 12:39:33] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2009-12-04 12:25:42] dirk at bean-it dot nl I've compiled the snapshot, gives the same segfaults. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50382 -- Edit this bug report at http://bugs.php.net/?id=50382&edit=1
#50382 [Fbk->Opn]: Upgrading to php 5.3 > Application works but apache segfaults
ID: 50382 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3.1 New Comment: Up till now, I haven't been able to exactly pinpoint the problem. As mentioned below, our application works as expected, it looks likes Apache crashes -after- php has compiled the page. Very strange. The application is quite large, a lot of code. Tried to debug with Zend Debugger, but than things work as expected, no segfault. As much as I would like to give some example code, I cannot at this moment, since I have no clue where things go wrong (the app works fine!). Any suggestions on how to proceed are highly appreciated. Previous Comments: [2009-12-04 12:39:33] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2009-12-04 12:25:42] dirk at bean-it dot nl I've compiled the snapshot, gives the same segfaults. [2009-12-04 12:11:54] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-12-04 11:08:43] dirk at bean-it dot nl Description: Upgrading to php 5.3 > Application works but apache segfaults I've upgraded from 5.2.11 to 5.3.1. Our application works fine when accessed from a browser, however the apache error log fills with messages like: [Fri Dec 04 11:24:59 2009] [notice] child pid 28025 exit signal Segmentation fault (11) Each request causes a message like this. This is not happening when using 5.2.11. I've tried to locate the problem by stepping through the code with the Zend debugger. Unfortunately, the problem does not occur when doing this. I've followed the instructions and created a backtrace (see below). The weird thing is, PHP compiled with --enable-debug, does not crash. I does give tons of "Memory leak" messages in the apache error.log. I'm not very in to this, so I hope this information gives somebody a clue. I've also tried a snapshot (5.3-200912040930), this doesn't work either, same segfaults. I'm more than happy to provide more info, test things, change things... Just let me know. ./configure options (I cannot reduce this set, the application will stop working) './configure' \ '--with-config-file-path=/etc' \ '--with-apxs2=/usr/bin/apxs2' \ '--with-gettext' \ '--with-libxml-dir=/usr/local' \ '--with-mysqli=/usr/bin/mysql_config' \ '--with-mcrypt' \ '--with-iconv' \ '--enable-mbstring' \ '--with-zlib=/usr' \ '--with-xsl' \ '--with-curl' \ '--with-gd' \ '--with-jpeg-dir=/usr/include' \ '--with-png-dir=/usr/include' \ '--with-openssl' \ '--with-freetype-dir' \ '--enable-gd-native-ttf' \ "$@" Actual result: -- Backtrace (created running the snapshot, without debug): (gdb) bt #0 0xb6e63777 in zval_mark_grey (pz=0x9fd0cf8) at /root/php5.3-200912040930/Zend/zend_gc.c:360 #1 0xb6e63d35 in gc_collect_cycles () at /root/php5.3-200912040930/Zend/zend_gc.c:417 #2 0xb6e48285 in zend_deactivate () at /root/php5.3-200912040930/Zend/zend.c:900 #3 0xb6df767f in php_request_shutdown (dummy=0x0) at /root/php5.3-200912040930/main/main.c:1606 #4 0xb6ec8aa9 in php_handler (r=0x9bc31d0) at /root/php5.3-200912040930/sapi/apache2handler/sapi_apache2.c:493 #5 0x0807a1c9 in ap_run_handler () #6 0x0807d5e1 in ap_invoke_handler () #7 0x0808af00 in ap_internal_redirect () #8 0xb73356c3 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #9 0x09bc31a0 in ?? () #10 0x09bb8d38 in ?? () #11 0xb7339bb7 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #12 0x09bc3138 in ?? () #13 0x in ?? () -- Edit this bug report at http://bugs.php.net/?id=50382&edit=1
#50382 [Fbk->Opn]: Upgrading to php 5.3 > Application works but apache segfaults
ID: 50382 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3.1 New Comment: I've compiled the snapshot, gives the same segfaults. Previous Comments: [2009-12-04 12:11:54] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-12-04 11:08:43] dirk at bean-it dot nl Description: Upgrading to php 5.3 > Application works but apache segfaults I've upgraded from 5.2.11 to 5.3.1. Our application works fine when accessed from a browser, however the apache error log fills with messages like: [Fri Dec 04 11:24:59 2009] [notice] child pid 28025 exit signal Segmentation fault (11) Each request causes a message like this. This is not happening when using 5.2.11. I've tried to locate the problem by stepping through the code with the Zend debugger. Unfortunately, the problem does not occur when doing this. I've followed the instructions and created a backtrace (see below). The weird thing is, PHP compiled with --enable-debug, does not crash. I does give tons of "Memory leak" messages in the apache error.log. I'm not very in to this, so I hope this information gives somebody a clue. I've also tried a snapshot (5.3-200912040930), this doesn't work either, same segfaults. I'm more than happy to provide more info, test things, change things... Just let me know. ./configure options (I cannot reduce this set, the application will stop working) './configure' \ '--with-config-file-path=/etc' \ '--with-apxs2=/usr/bin/apxs2' \ '--with-gettext' \ '--with-libxml-dir=/usr/local' \ '--with-mysqli=/usr/bin/mysql_config' \ '--with-mcrypt' \ '--with-iconv' \ '--enable-mbstring' \ '--with-zlib=/usr' \ '--with-xsl' \ '--with-curl' \ '--with-gd' \ '--with-jpeg-dir=/usr/include' \ '--with-png-dir=/usr/include' \ '--with-openssl' \ '--with-freetype-dir' \ '--enable-gd-native-ttf' \ "$@" Actual result: -- Backtrace (created running the snapshot, without debug): (gdb) bt #0 0xb6e63777 in zval_mark_grey (pz=0x9fd0cf8) at /root/php5.3-200912040930/Zend/zend_gc.c:360 #1 0xb6e63d35 in gc_collect_cycles () at /root/php5.3-200912040930/Zend/zend_gc.c:417 #2 0xb6e48285 in zend_deactivate () at /root/php5.3-200912040930/Zend/zend.c:900 #3 0xb6df767f in php_request_shutdown (dummy=0x0) at /root/php5.3-200912040930/main/main.c:1606 #4 0xb6ec8aa9 in php_handler (r=0x9bc31d0) at /root/php5.3-200912040930/sapi/apache2handler/sapi_apache2.c:493 #5 0x0807a1c9 in ap_run_handler () #6 0x0807d5e1 in ap_invoke_handler () #7 0x0808af00 in ap_internal_redirect () #8 0xb73356c3 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #9 0x09bc31a0 in ?? () #10 0x09bb8d38 in ?? () #11 0xb7339bb7 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #12 0x09bc3138 in ?? () #13 0x in ?? () -- Edit this bug report at http://bugs.php.net/?id=50382&edit=1
#50382 [NEW]: Upgrading to php 5.3 > Application works but apache segfaults
From: dirk at bean-it dot nl Operating system: Debian 5.0 PHP version: 5.3.1 PHP Bug Type: Reproducible crash Bug description: Upgrading to php 5.3 > Application works but apache segfaults Description: Upgrading to php 5.3 > Application works but apache segfaults I've upgraded from 5.2.11 to 5.3.1. Our application works fine when accessed from a browser, however the apache error log fills with messages like: [Fri Dec 04 11:24:59 2009] [notice] child pid 28025 exit signal Segmentation fault (11) Each request causes a message like this. This is not happening when using 5.2.11. I've tried to locate the problem by stepping through the code with the Zend debugger. Unfortunately, the problem does not occur when doing this. I've followed the instructions and created a backtrace (see below). The weird thing is, PHP compiled with --enable-debug, does not crash. I does give tons of "Memory leak" messages in the apache error.log. I'm not very in to this, so I hope this information gives somebody a clue. I've also tried a snapshot (5.3-200912040930), this doesn't work either, same segfaults. I'm more than happy to provide more info, test things, change things... Just let me know. ./configure options (I cannot reduce this set, the application will stop working) './configure' \ '--with-config-file-path=/etc' \ '--with-apxs2=/usr/bin/apxs2' \ '--with-gettext' \ '--with-libxml-dir=/usr/local' \ '--with-mysqli=/usr/bin/mysql_config' \ '--with-mcrypt' \ '--with-iconv' \ '--enable-mbstring' \ '--with-zlib=/usr' \ '--with-xsl' \ '--with-curl' \ '--with-gd' \ '--with-jpeg-dir=/usr/include' \ '--with-png-dir=/usr/include' \ '--with-openssl' \ '--with-freetype-dir' \ '--enable-gd-native-ttf' \ "$@" Actual result: -- Backtrace (created running the snapshot, without debug): (gdb) bt #0 0xb6e63777 in zval_mark_grey (pz=0x9fd0cf8) at /root/php5.3-200912040930/Zend/zend_gc.c:360 #1 0xb6e63d35 in gc_collect_cycles () at /root/php5.3-200912040930/Zend/zend_gc.c:417 #2 0xb6e48285 in zend_deactivate () at /root/php5.3-200912040930/Zend/zend.c:900 #3 0xb6df767f in php_request_shutdown (dummy=0x0) at /root/php5.3-200912040930/main/main.c:1606 #4 0xb6ec8aa9 in php_handler (r=0x9bc31d0) at /root/php5.3-200912040930/sapi/apache2handler/sapi_apache2.c:493 #5 0x0807a1c9 in ap_run_handler () #6 0x0807d5e1 in ap_invoke_handler () #7 0x0808af00 in ap_internal_redirect () #8 0xb73356c3 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #9 0x09bc31a0 in ?? () #10 0x09bb8d38 in ?? () #11 0xb7339bb7 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #12 0x09bc3138 in ?? () #13 0x in ?? () -- Edit bug report at http://bugs.php.net/?id=50382&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50382&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50382&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50382&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50382&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50382&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50382&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50382&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50382&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50382&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50382&r=support Expected behavior: http://bugs.php.net/fix.php?id=50382&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50382&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50382&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50382&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50382&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50382&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50382&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50382&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50382&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50382&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50382&r=mysqlcfg
#45066 [Opn]: Cannot compile a working php with mysql and mysqli
ID: 45066 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl Status: Open Bug Type: MySQL related Operating System: Debian 4.0 / x86_64 PHP Version: 5.2.6 New Comment: mysqlnd is yet to be released for production use... So for now, that seems not to be the way. I'll upgrade the mysql libs on a test machine after my vacation (after august 5th, that is). I'll post my findings here. Thanks for looking in to this! Cheers, Dirk Previous Comments: [2008-07-21 18:16:20] [EMAIL PROTECTED] Which means that one will be better served with mysqlnd? [2008-07-17 23:09:21] [EMAIL PROTECTED] By the looks of the valgrind output, IMO, this is some bug in the mysql lib. Try google for __lll_mutex_lock_wait and you get plenty of hits pointing to discussion forums. Corrupted heap, -lpthread vs -pthread, etc. among the possible problems.. [2008-07-17 08:55:48] dirk at bean-it dot nl Yes, and I was wrong... :) In my opinion, bug#42625 went the wrong way (specially the last few comments), so it would be clearer to start a new bugreport... [2008-07-17 08:50:57] [EMAIL PROTECTED] Ooops, it was you :) [2008-07-17 08:49:40] [EMAIL PROTECTED] Dirk, I decided to look with Google for something similar and Bug#42625 appeared. The same problem, the same distro (Debian), the same version of MySQL (5.0.32). The reported said he updated to some higher version and the problem disappeared. Could this be the cause? Best, Andrey The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45066 -- Edit this bug report at http://bugs.php.net/?id=45066&edit=1
#45066 [Opn]: Cannot compile a working php with mysql and mysqli
ID: 45066 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl Status: Open Bug Type: MySQL related Operating System: Debian 4.0 / x86_64 PHP Version: 5.2.6 New Comment: Yes, and I was wrong... :) In my opinion, bug#42625 went the wrong way (specially the last few comments), so it would be clearer to start a new bugreport... Previous Comments: [2008-07-17 08:50:57] [EMAIL PROTECTED] Ooops, it was you :) [2008-07-17 08:49:40] [EMAIL PROTECTED] Dirk, I decided to look with Google for something similar and Bug#42625 appeared. The same problem, the same distro (Debian), the same version of MySQL (5.0.32). The reported said he updated to some higher version and the problem disappeared. Could this be the cause? Best, Andrey [2008-07-17 08:10:14] dirk at bean-it dot nl Mailed the output! [2008-07-17 07:37:39] [EMAIL PROTECTED] Can you provide us with full strace output? Probably will be too long for the report, so you can send it to [EMAIL PROTECTED] . If Jani also needs it I will forward it to him. Thanks for helping nail down the issue! Andrey [2008-07-17 06:36:13] dirk at bean-it dot nl Hi, Yes, I can reproduce this on serveral machines. All of my Debian amd64 machines (8 of them) and some of the i686 machines. Cheers, Dirk The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45066 -- Edit this bug report at http://bugs.php.net/?id=45066&edit=1
#45066 [Opn]: Cannot compile a working php with mysql and mysqli
ID: 45066 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl Status: Open Bug Type: MySQL related Operating System: Debian 4.0 / x86_64 PHP Version: 5.2.6 New Comment: Mailed the output! Previous Comments: [2008-07-17 07:37:39] [EMAIL PROTECTED] Can you provide us with full strace output? Probably will be too long for the report, so you can send it to [EMAIL PROTECTED] . If Jani also needs it I will forward it to him. Thanks for helping nail down the issue! Andrey [2008-07-17 06:36:13] dirk at bean-it dot nl Hi, Yes, I can reproduce this on serveral machines. All of my Debian amd64 machines (8 of them) and some of the i686 machines. Cheers, Dirk [2008-07-17 00:53:29] [EMAIL PROTECTED] One last question: Are you able to reproduce this problem on any other machine? [2008-07-16 06:33:56] dirk at bean-it dot nl OK, here is the full valgrind output, minus the php output, to shorten things a little. Cheers, Dirk ==29926== Memcheck, a memory error detector. ==29926== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==29926== Using LibVEX rev 1658, a library for dynamic binary translation. ==29926== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==29926== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==29926== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==29926== For more details, rerun with: -v ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010AB3: (within /lib/ld-2.3.6.so) ==29926==by 0x4006CB6: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010AC2: (within /lib/ld-2.3.6.so) ==29926==by 0x4006CB6: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010AD1: (within /lib/ld-2.3.6.so) ==29926==by 0x4006CB6: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010C47: (within /lib/ld-2.3.6.so) ==29926==by 0x4006E47: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or
#45066 [Fbk->Opn]: Cannot compile a working php with mysql and mysqli
ID: 45066 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Debian 4.0 / x86_64 PHP Version: 5.2.6 New Comment: Hi, Yes, I can reproduce this on serveral machines. All of my Debian amd64 machines (8 of them) and some of the i686 machines. Cheers, Dirk Previous Comments: [2008-07-17 00:53:29] [EMAIL PROTECTED] One last question: Are you able to reproduce this problem on any other machine? [2008-07-16 06:33:56] dirk at bean-it dot nl OK, here is the full valgrind output, minus the php output, to shorten things a little. Cheers, Dirk ==29926== Memcheck, a memory error detector. ==29926== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==29926== Using LibVEX rev 1658, a library for dynamic binary translation. ==29926== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==29926== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==29926== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==29926== For more details, rerun with: -v ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010AB3: (within /lib/ld-2.3.6.so) ==29926==by 0x4006CB6: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010AC2: (within /lib/ld-2.3.6.so) ==29926==by 0x4006CB6: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010AD1: (within /lib/ld-2.3.6.so) ==29926==by 0x4006CB6: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010C47: (within /lib/ld-2.3.6.so) ==29926==by 0x4006E47: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010C47: (within /lib/ld-2.3.6.so) ==29926==by 0x400B8A2: (within /lib/ld-2.3.6.so) ==29926==by 0x400733A: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /
#45066 [Fbk->Opn]: Cannot compile a working php with mysql and mysqli
ID: 45066 User updated by: dirk at bean-it dot nl Reported By: dirk at bean-it dot nl -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Debian 4.0 / x86_64 PHP Version: 5.2.6 New Comment: OK, here is the full valgrind output, minus the php output, to shorten things a little. Cheers, Dirk ==29926== Memcheck, a memory error detector. ==29926== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==29926== Using LibVEX rev 1658, a library for dynamic binary translation. ==29926== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==29926== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==29926== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==29926== For more details, rerun with: -v ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010AB3: (within /lib/ld-2.3.6.so) ==29926==by 0x4006CB6: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010AC2: (within /lib/ld-2.3.6.so) ==29926==by 0x4006CB6: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010AD1: (within /lib/ld-2.3.6.so) ==29926==by 0x4006CB6: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010C47: (within /lib/ld-2.3.6.so) ==29926==by 0x4006E47: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926==by 0x5710C43: getservbyname (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010C47: (within /lib/ld-2.3.6.so) ==29926==by 0x400B8A2: (within /lib/ld-2.3.6.so) ==29926==by 0x400733A: (within /lib/ld-2.3.6.so) ==29926==by 0x572D230: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572CCC7: _dl_open (in /lib/libc-2.3.6.so) ==29926==by 0x572F467: (within /lib/libc-2.3.6.so) ==29926==by 0x400B7D0: (within /lib/ld-2.3.6.so) ==29926==by 0x572F4B1: __libc_dlopen_mode (in /lib/libc-2.3.6.so) ==29926==by 0x570A426: __nss_lookup_function (in /lib/libc-2.3.6.so) ==29926==by 0x570A4D4: (within /lib/libc-2.3.6.so) ==29926==by 0x5710E82: getservbyname_r (in /lib/libc-2.3.6.so) ==29926== ==29926== Conditional jump or move depends on uninitialised value(s) ==29926==at 0x4010C47: (within /lib/ld-2.3.6.so) ==29926==by 0x400B8A2: (within /lib/ld-2.3.6.so) ==29926==
#45066 [Opn]: Cannot compile a working php with mysql and mysqli
ID: 45066
User updated by: dirk at bean-it dot nl
Reported By: dirk at bean-it dot nl
Status: Open
Bug Type: MySQL related
Operating System: Linux x86
PHP Version: 5.2.6
New Comment:
Just out of curiosity, I've tried to compile the 5.2 and 5.3 snapshots
using:
./configure --disable-all --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
They both hang like 5.2.6.
Cheers,
Dirk
Previous Comments:
[2008-07-15 14:58:42] dirk at bean-it dot nl
Hi,
Thank you for your replies. First off all, some answers:
OS: Debian 4.0 (etch)
Kernel: Linux 2.6.18-6-amd64 #1 SMP 2008 x86_64 GNU/Linux (Stock Debian
kernel)
CPU: 2 x Intel(R) Xeon(R) CPU 5130 @ 2.00GHz
Mysql version:
mysql Ver 14.12 Distrib 5.0.32, for pc-linux-gnu (x86_64) (Stock
Debian Mysql 5.0)
Apache version: apache2-mpm-prefork 2.2.3-4+etch4
Running:
# rm config.cache
# ./configure --disable-all --with-apxs2=/usr/bin/apxs2 && make clean
&& make
# sapi/cli/php -v
Gives me a working php, no problem.
Running:
# rm config.cache
# ./configure --disable-all --with-apxs2=/usr/bin/apxs2 --with-mysqli
--enable-mysqlnd && make clean && make
# sapi/cli/php -v
Gives me a working php, no problem. Used php-mysqlnd-5.0.1-beta.
Running:
# rm config.cache
# ./configure --disable-all --with-apxs2=/usr/bin/apxs2 --with-mysqli
--enable-mysqlnd --with-mysql=/usr && make clean && make
# sapi/cli/php -v
Gives me a working php, no problem.
Just to be very sure, I've tried to build php again, using a fresh
source tree and this cmd line:
./configure --disable-all --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
Which still gives me the non-responsive PHP.
Kind regards,
Dirk
[2008-07-14 21:04:18] [EMAIL PROTECTED]
Also it might be good to know if you can reproduce this without
enabling any mysql stuff at all. Try this configure line:
# rm config.cache
# ./configure --disable-all --with-apxs2 && make clean && make
# sapi/cli/php -v
That should work? What Apache MPM have you enabled btw?
Note: Please give us also the basic info Uwe asked above..
[2008-07-14 19:42:55] [EMAIL PROTECTED]
No idea, but I'd like to know what "Linux x86" means. What's the OS,
what's the CPU, what MySQL version. Does the problem exist with mysqlnd?
----------------
[2008-07-07 08:49:43] dirk at bean-it dot nl
Ok, i've tried to make a backtrace. Since the program just hangs and
doesn't crash, I've did it this way:
cd php-5.2.6/
gdb sapi/cli/php
(gdb) run -i
(gdb) bt
Output
Program received signal SIGINT, Interrupt.
[Switching to Thread 47510530549152 (LWP 2089)]
0x2b35e7b87eeb in __lll_mutex_lock_wait () from
/lib/libpthread.so.0
(gdb) backtrace
#0 0x2b35e7b87eeb in __lll_mutex_lock_wait () from
/lib/libpthread.so.0
#1 0x0016 in ?? ()
#2 0x4871d7d2 in ?? ()
#3 0x2b35e7b8598c in pthread_cond_destroy@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#4 0x in ?? ()
Hope this gives a clou... If I should do something else, please let me
know!
----
[2008-06-10 14:54:27] dirk at bean-it dot nl
Just had the same problem on an 686... really puzzling, because the
machine is virtually the same as a machine without the problem. Same
distro, same mysql libs...?
This is the last past of a strace output of sapi/cli/php -i. It hangs
forever after this.
munmap(0x2b233bd99000, 266240) = 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b233bd99000
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) =
0
futex(0x2b233c5ef5e0, FUTEX_WAIT, 2, NULL
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/45066
--
Edit this bug report at http://bugs.php.net/?id=45066&edit=1
#45066 [Fbk->Opn]: Cannot compile a working php with mysql and mysqli
ID: 45066
User updated by: dirk at bean-it dot nl
Reported By: dirk at bean-it dot nl
-Status: Feedback
+Status: Open
Bug Type: MySQL related
Operating System: Linux x86
PHP Version: 5.2.6
New Comment:
Hi,
Thank you for your replies. First off all, some answers:
OS: Debian 4.0 (etch)
Kernel: Linux 2.6.18-6-amd64 #1 SMP 2008 x86_64 GNU/Linux (Stock Debian
kernel)
CPU: 2 x Intel(R) Xeon(R) CPU 5130 @ 2.00GHz
Mysql version:
mysql Ver 14.12 Distrib 5.0.32, for pc-linux-gnu (x86_64) (Stock
Debian Mysql 5.0)
Apache version: apache2-mpm-prefork 2.2.3-4+etch4
Running:
# rm config.cache
# ./configure --disable-all --with-apxs2=/usr/bin/apxs2 && make clean
&& make
# sapi/cli/php -v
Gives me a working php, no problem.
Running:
# rm config.cache
# ./configure --disable-all --with-apxs2=/usr/bin/apxs2 --with-mysqli
--enable-mysqlnd && make clean && make
# sapi/cli/php -v
Gives me a working php, no problem. Used php-mysqlnd-5.0.1-beta.
Running:
# rm config.cache
# ./configure --disable-all --with-apxs2=/usr/bin/apxs2 --with-mysqli
--enable-mysqlnd --with-mysql=/usr && make clean && make
# sapi/cli/php -v
Gives me a working php, no problem.
Just to be very sure, I've tried to build php again, using a fresh
source tree and this cmd line:
./configure --disable-all --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
Which still gives me the non-responsive PHP.
Kind regards,
Dirk
Previous Comments:
[2008-07-14 21:04:18] [EMAIL PROTECTED]
Also it might be good to know if you can reproduce this without
enabling any mysql stuff at all. Try this configure line:
# rm config.cache
# ./configure --disable-all --with-apxs2 && make clean && make
# sapi/cli/php -v
That should work? What Apache MPM have you enabled btw?
Note: Please give us also the basic info Uwe asked above..
[2008-07-14 19:42:55] [EMAIL PROTECTED]
No idea, but I'd like to know what "Linux x86" means. What's the OS,
what's the CPU, what MySQL version. Does the problem exist with mysqlnd?
----------------
[2008-07-07 08:49:43] dirk at bean-it dot nl
Ok, i've tried to make a backtrace. Since the program just hangs and
doesn't crash, I've did it this way:
cd php-5.2.6/
gdb sapi/cli/php
(gdb) run -i
(gdb) bt
Output
Program received signal SIGINT, Interrupt.
[Switching to Thread 47510530549152 (LWP 2089)]
0x2b35e7b87eeb in __lll_mutex_lock_wait () from
/lib/libpthread.so.0
(gdb) backtrace
#0 0x2b35e7b87eeb in __lll_mutex_lock_wait () from
/lib/libpthread.so.0
#1 0x0016 in ?? ()
#2 0x4871d7d2 in ?? ()
#3 0x2b35e7b8598c in pthread_cond_destroy@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#4 0x in ?? ()
Hope this gives a clou... If I should do something else, please let me
know!
------------
[2008-06-10 14:54:27] dirk at bean-it dot nl
Just had the same problem on an 686... really puzzling, because the
machine is virtually the same as a machine without the problem. Same
distro, same mysql libs...?
This is the last past of a strace output of sapi/cli/php -i. It hangs
forever after this.
munmap(0x2b233bd99000, 266240) = 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b233bd99000
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) =
0
futex(0x2b233c5ef5e0, FUTEX_WAIT, 2, NULL
------------
[2008-05-22 15:05:55] dirk at bean-it dot nl
Description:
When I try to compile PHP 5.2.6 with the following options:
--with-apxs2=/usr/bin/apxs2
--with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
On a x86 machine, I get a not working php. Make test doesn't return
anything, make install will work, but just typing php -v at the command
line hangs forever.
On a i386 machine, same OS (debian etch), same mysql libs, same all, no
problem.
This problem started in php-5.2.4, 5.2.3 is the last php that will
result in a succesfull working php after compilation on x86. The problem
does not exist when not using --with-apxs2
Reproduce code:
---
./configure --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
Expected result:
A working php...
Actual result:
--
A non-responsive php :-(
--
Edit this bug report at http://bugs.php.net/?id=45066&edit=1
#45066 [Fbk->Opn]: Cannot compile a working php with mysql and mysqli
ID: 45066
User updated by: dirk at bean-it dot nl
Reported By: dirk at bean-it dot nl
-Status: Feedback
+Status: Open
Bug Type: MySQL related
Operating System: Linux x86
PHP Version: 5.2.6
New Comment:
Ok, i've tried to make a backtrace. Since the program just hangs and
doesn't crash, I've did it this way:
cd php-5.2.6/
gdb sapi/cli/php
(gdb) run -i
(gdb) bt
Output
Program received signal SIGINT, Interrupt.
[Switching to Thread 47510530549152 (LWP 2089)]
0x2b35e7b87eeb in __lll_mutex_lock_wait () from
/lib/libpthread.so.0
(gdb) backtrace
#0 0x2b35e7b87eeb in __lll_mutex_lock_wait () from
/lib/libpthread.so.0
#1 0x0016 in ?? ()
#2 0x4871d7d2 in ?? ()
#3 0x2b35e7b8598c in pthread_cond_destroy@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#4 0x in ?? ()
Hope this gives a clou... If I should do something else, please let me
know!
Previous Comments:
[2008-07-06 11:47:53] [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-06-10 14:54:27] dirk at bean-it dot nl
Just had the same problem on an 686... really puzzling, because the
machine is virtually the same as a machine without the problem. Same
distro, same mysql libs...?
This is the last past of a strace output of sapi/cli/php -i. It hangs
forever after this.
munmap(0x2b233bd99000, 266240) = 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b233bd99000
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) =
0
futex(0x2b233c5ef5e0, FUTEX_WAIT, 2, NULL
----
[2008-05-22 15:05:55] dirk at bean-it dot nl
Description:
When I try to compile PHP 5.2.6 with the following options:
--with-apxs2=/usr/bin/apxs2
--with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
On a x86 machine, I get a not working php. Make test doesn't return
anything, make install will work, but just typing php -v at the command
line hangs forever.
On a i386 machine, same OS (debian etch), same mysql libs, same all, no
problem.
This problem started in php-5.2.4, 5.2.3 is the last php that will
result in a succesfull working php after compilation on x86. The problem
does not exist when not using --with-apxs2
Reproduce code:
---
./configure --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
Expected result:
A working php...
Actual result:
--
A non-responsive php :-(
--
Edit this bug report at http://bugs.php.net/?id=45066&edit=1
#45066 [Opn]: Cannot compile a working php with mysql and mysqli
ID: 45066
User updated by: dirk at bean-it dot nl
Reported By: dirk at bean-it dot nl
Status: Open
Bug Type: MySQL related
Operating System: Linux x86
PHP Version: 5.2.6
New Comment:
Just had the same problem on an 686... really puzzling, because the
machine is virtually the same as a machine without the problem. Same
distro, same mysql libs...?
This is the last past of a strace output of sapi/cli/php -i. It hangs
forever after this.
munmap(0x2b233bd99000, 266240) = 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b233bd99000
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) =
0
futex(0x2b233c5ef5e0, FUTEX_WAIT, 2, NULL
Previous Comments:
[2008-05-22 15:05:55] dirk at bean-it dot nl
Description:
When I try to compile PHP 5.2.6 with the following options:
--with-apxs2=/usr/bin/apxs2
--with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
On a x86 machine, I get a not working php. Make test doesn't return
anything, make install will work, but just typing php -v at the command
line hangs forever.
On a i386 machine, same OS (debian etch), same mysql libs, same all, no
problem.
This problem started in php-5.2.4, 5.2.3 is the last php that will
result in a succesfull working php after compilation on x86. The problem
does not exist when not using --with-apxs2
Reproduce code:
---
./configure --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
Expected result:
A working php...
Actual result:
--
A non-responsive php :-(
--
Edit this bug report at http://bugs.php.net/?id=45066&edit=1
#45066 [NEW]: Cannot compile a working php with mysql and mysqli
From: dirk at bean-it dot nl Operating system: Linux x86 PHP version: 5.2.6 PHP Bug Type: MySQL related Bug description: Cannot compile a working php with mysql and mysqli Description: When I try to compile PHP 5.2.6 with the following options: --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config On a x86 machine, I get a not working php. Make test doesn't return anything, make install will work, but just typing php -v at the command line hangs forever. On a i386 machine, same OS (debian etch), same mysql libs, same all, no problem. This problem started in php-5.2.4, 5.2.3 is the last php that will result in a succesfull working php after compilation on x86. The problem does not exist when not using --with-apxs2 Reproduce code: --- ./configure --with-apxs2=/usr/bin/apxs2 --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config Expected result: A working php... Actual result: -- A non-responsive php :-( -- Edit bug report at http://bugs.php.net/?id=45066&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45066&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45066&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45066&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45066&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45066&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45066&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45066&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45066&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45066&r=support Expected behavior:http://bugs.php.net/fix.php?id=45066&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45066&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45066&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45066&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45066&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45066&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45066&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45066&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45066&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45066&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45066&r=mysqlcfg
#42625 [Com]: When mysql and mysqli enabled both together, php CLI hangs when ZTS is enabled
ID: 42625 Comment by: dirk at bean-it dot nl Reported By: jama at mk dot cvut dot cz Status: Assigned Bug Type: MySQL related Operating System: Gentoo/Linux PHP Version: 5.2.4 Assigned To: andrey New Comment: Here I am again... :-) Debian posted updated for mysql-5 and it libs today. Installing this resolves my issue, I have a working php 5.2.5 now. Non working debian mysql-5 version: ii libmysqlclient15-dev 5.0.32-7etch1 ii libmysqlclient15off 5.0.32-7etch1 Working: ii libmysqlclient15-dev5.0.32-7etch3 ii libmysqlclient15off 5.0.32-7etch3 Cheers, Dirk Previous Comments: [2007-11-26 15:53:00] dirk at bean-it dot nl I'll have to get back on my previous post, it also happens on i686 :-( So, when I enable mysql & mysqli, this results in a non working php. (./configure --with-mysqli=/usr/bin/mysql_config --with-mysql=/usr) Just enabling mysql or mysqli works fine. (./configure --with-mysqli=/usr/bin/mysql_config) or (./configure --with-mysql=/usr) I've compared the mysql libs version on the i686 machines (one does compile a good php, one doesn't) and they are the same. [2007-11-21 19:47:12] dirk at bean-it dot nl I'm experiencing the same problem, but my 2 cents tell me this is only happening on amd64 + mysql + mysqli. My various i386 systems, build with the same configure options have no problems at all. Leaving mysql or mysqli option out results in a fine working php. Enabling them both results in a broken php (ie, no prompt is returned in the cli, and the apache modules works extremely crappy, since tons of new apaches are started and they all hang). The problem still exists in 5.2.5 and was not in there 5.2.3. I run Debian 4.0 (x86_64 GNU/Linux) on all systems, with stock kernels (2.6.18) I'm happy to provide more info, if necessary. Or to post a new bug, if you think this is more appropriate... [2007-10-05 12:22:29] jama at mk dot cvut dot cz I have updated mysql to: mysql_config --version 5.1.22-rc Downloaded new snapshots and new report seems OK for php.. ./test.report.sh php-5.2.4.log OK php-5.2.4-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config OK php-5.2.4-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config php5.2-200710051030.log OK php5.2-200710051030-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config OK php5.2-200710051030-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config php6.0-200710051030.log OK php6.0-200710051030-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config OK php6.0-200710051030-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config OK php6.0-200710051030-mysqli-mysqlng ./configure --disable-all --enable-maintainer-zts --with-mysql=mysql --with-mysqli=mysqlnd [2007-09-24 09:39:40] jama at mk dot cvut dot cz tested on php6.0-200709240630 mysqli OK mysql+mysqli BAD mysql+mysqlng OK I created simple bash script for building and testing php snapshots for this bug. It's on http://pastebin.com/m68372238 Runned in this case as ". ./test.sh php6.0-200709240630.tar.bz2 php6.0-200709240630 php6.0-200709240630" Manualy killed when php -i was hanging on second test and result looks like this: # cat php6.0-200709240630.log OK php6.0-200709240630-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config BAD php6.0-200709240630-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config OK php6.0-200709240630-mysqli-mysqlng ./configure --disable-all --enable-maintainer-zts --with-mysql=mysql --with-mysqli=mysqlnd [2007-09-22 08:47:41] [EMAIL PROTECTED] Hi, - can you try building PHP6? - if still han gs, can you try building with mysqlnd (PHP6, --with-mysqli=mysqlnd --with-mysql=mysql) and see if there is still a problem Andrey The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/42625 -- Edit this bug report at http://bugs.php.net/?id=42625&edit=1
#42625 [Com]: When mysql and mysqli enabled both together, php CLI hangs when ZTS is enabled
ID: 42625 Comment by: dirk at bean-it dot nl Reported By: jama at mk dot cvut dot cz Status: Assigned Bug Type: MySQL related Operating System: Gentoo/Linux PHP Version: 5.2.4 Assigned To: andrey New Comment: I'll have to get back on my previous post, it also happens on i686 :-( So, when I enable mysql & mysqli, this results in a non working php. (./configure --with-mysqli=/usr/bin/mysql_config --with-mysql=/usr) Just enabling mysql or mysqli works fine. (./configure --with-mysqli=/usr/bin/mysql_config) or (./configure --with-mysql=/usr) I've compared the mysql libs version on the i686 machines (one does compile a good php, one doesn't) and they are the same. Previous Comments: [2007-11-21 19:47:12] dirk at bean-it dot nl I'm experiencing the same problem, but my 2 cents tell me this is only happening on amd64 + mysql + mysqli. My various i386 systems, build with the same configure options have no problems at all. Leaving mysql or mysqli option out results in a fine working php. Enabling them both results in a broken php (ie, no prompt is returned in the cli, and the apache modules works extremely crappy, since tons of new apaches are started and they all hang). The problem still exists in 5.2.5 and was not in there 5.2.3. I run Debian 4.0 (x86_64 GNU/Linux) on all systems, with stock kernels (2.6.18) I'm happy to provide more info, if necessary. Or to post a new bug, if you think this is more appropriate... [2007-10-05 12:22:29] jama at mk dot cvut dot cz I have updated mysql to: mysql_config --version 5.1.22-rc Downloaded new snapshots and new report seems OK for php.. ./test.report.sh php-5.2.4.log OK php-5.2.4-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config OK php-5.2.4-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config php5.2-200710051030.log OK php5.2-200710051030-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config OK php5.2-200710051030-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config php6.0-200710051030.log OK php6.0-200710051030-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config OK php6.0-200710051030-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config OK php6.0-200710051030-mysqli-mysqlng ./configure --disable-all --enable-maintainer-zts --with-mysql=mysql --with-mysqli=mysqlnd [2007-09-24 09:39:40] jama at mk dot cvut dot cz tested on php6.0-200709240630 mysqli OK mysql+mysqli BAD mysql+mysqlng OK I created simple bash script for building and testing php snapshots for this bug. It's on http://pastebin.com/m68372238 Runned in this case as ". ./test.sh php6.0-200709240630.tar.bz2 php6.0-200709240630 php6.0-200709240630" Manualy killed when php -i was hanging on second test and result looks like this: # cat php6.0-200709240630.log OK php6.0-200709240630-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config BAD php6.0-200709240630-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config OK php6.0-200709240630-mysqli-mysqlng ./configure --disable-all --enable-maintainer-zts --with-mysql=mysql --with-mysqli=mysqlnd [2007-09-22 08:47:41] [EMAIL PROTECTED] Hi, - can you try building PHP6? - if still han gs, can you try building with mysqlnd (PHP6, --with-mysqli=mysqlnd --with-mysql=mysql) and see if there is still a problem Andrey [2007-09-19 14:08:19] [EMAIL PROTECTED] I can't reproduce with MySQL 5.1.22 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/42625 -- Edit this bug report at http://bugs.php.net/?id=42625&edit=1
#42625 [Com]: When mysql and mysqli enabled both together, php CLI hangs when ZTS is enabled
ID: 42625 Comment by: dirk at bean-it dot nl Reported By: jama at mk dot cvut dot cz Status: Assigned Bug Type: MySQL related Operating System: Gentoo/Linux PHP Version: 5.2.4 Assigned To: andrey New Comment: I'm experiencing the same problem, but my 2 cents tell me this is only happening on amd64 + mysql + mysqli. My various i386 systems, build with the same configure options have no problems at all. Leaving mysql or mysqli option out results in a fine working php. Enabling them both results in a broken php (ie, no prompt is returned in the cli, and the apache modules works extremely crappy, since tons of new apaches are started and they all hang). The problem still exists in 5.2.5 and was not in there 5.2.3. I run Debian 4.0 (x86_64 GNU/Linux) on all systems, with stock kernels (2.6.18) I'm happy to provide more info, if necessary. Or to post a new bug, if you think this is more appropriate... Previous Comments: [2007-10-05 12:22:29] jama at mk dot cvut dot cz I have updated mysql to: mysql_config --version 5.1.22-rc Downloaded new snapshots and new report seems OK for php.. ./test.report.sh php-5.2.4.log OK php-5.2.4-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config OK php-5.2.4-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config php5.2-200710051030.log OK php5.2-200710051030-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config OK php5.2-200710051030-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config php6.0-200710051030.log OK php6.0-200710051030-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config OK php6.0-200710051030-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config OK php6.0-200710051030-mysqli-mysqlng ./configure --disable-all --enable-maintainer-zts --with-mysql=mysql --with-mysqli=mysqlnd [2007-09-24 09:39:40] jama at mk dot cvut dot cz tested on php6.0-200709240630 mysqli OK mysql+mysqli BAD mysql+mysqlng OK I created simple bash script for building and testing php snapshots for this bug. It's on http://pastebin.com/m68372238 Runned in this case as ". ./test.sh php6.0-200709240630.tar.bz2 php6.0-200709240630 php6.0-200709240630" Manualy killed when php -i was hanging on second test and result looks like this: # cat php6.0-200709240630.log OK php6.0-200709240630-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config BAD php6.0-200709240630-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config OK php6.0-200709240630-mysqli-mysqlng ./configure --disable-all --enable-maintainer-zts --with-mysql=mysql --with-mysqli=mysqlnd [2007-09-22 08:47:41] [EMAIL PROTECTED] Hi, - can you try building PHP6? - if still han gs, can you try building with mysqlnd (PHP6, --with-mysqli=mysqlnd --with-mysql=mysql) and see if there is still a problem Andrey [2007-09-19 14:08:19] [EMAIL PROTECTED] I can't reproduce with MySQL 5.1.22 [2007-09-19 13:40:39] [EMAIL PROTECTED] Propably some issue with the BETA mysql version used. Assigned to the mysql maintainer. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/42625 -- Edit this bug report at http://bugs.php.net/?id=42625&edit=1
