#33770 [Opn]: https:// or ftps:// do not work when --with-curlwrappers is used
ID: 33770 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net Status: Open Bug Type: cURL related -Operating System: Linux SuSE 10.0 +Operating System: Linux OpenSUSE 10.1 -PHP Version: 5CVS-2006-01-13 (snap) +PHP Version: 5CVS-2006-06-26 (snap) New Comment: New hardware, new OS (OpenSUSE 10.1 x64) Tried the 200606261030 snapshot. OpenSSL libs: 0.9.8a Curl libs: 7.15.1 Same result: --with-curlwrappers breaks HTTPS. Previous Comments: [2006-04-10 12:00:22] [EMAIL PROTECTED] See also bug #36882 [2006-01-13 18:32:20] subscription at nazarenko dot net Tried the 200601131530 snapshot. OpenSSL libs: 0.9.7g Curl libs: 7.14.0 Same result. HTTPS works only when --with-curlwrappers is not used. [2005-11-10 00:15:48] subscription at nazarenko dot net Here is the result after compiling with --with-curlwrappers: /install/php5-200511091730/sapi/cli/php -i | grep Registered Registered PHP Streams = php, file, ftp, gopher, telnet, dict, ldap, http, https, ftps Registered Stream Socket Transports = tcp, udp, unix, udg, ssl, sslv3, sslv2, tls Registered Stream Filters = string.rot13, string.toupper, string.tolower, string.strip_tags, convert.* /install/php5-200511091730/sapi/cli/php -i | grep fopen allow_url_fopen = On = On [2005-11-09 23:59:32] subscription at nazarenko dot net If you mean 'you do have the 64bit versions of those installed?' question, the answer is: Yes, I do. Here is the output of rpm commands: rpm -q --provides openssl-0.9.7g-2.2 ssl libcrypto.so.0.9.7()(64bit) libssl.so.0.9.7()(64bit) openssl = 0.9.7g-2.2 rpm -q --provides curl-7.14.0-2.2 curl_ssl libcurl.so.3()(64bit) curl = 7.14.0-2.2 Also, my 'allow_url_fopen' is On (otherwise no test case would work) I have to stress this fact: absolutely nothing has been changed between the two tests, no php.ini settings, no libraries installed, no system variables, etc. except the --with-curlwrappers directive. In once case https works in the other one it does not. [2005-08-06 20:06:39] [EMAIL PROTECTED] Make sure you have allow_url_fopen turned on in your php.ini file and that you can see https listed on your phpinfo() output. 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/33770 -- Edit this bug report at http://bugs.php.net/?id=33770edit=1
#37463 [Bgs]: Segmenation fault when both MySQLi and SNMP are enabled
ID: 37463 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net Status: Bogus Bug Type: MySQLi related Operating System: Linux SuSE 10.1 PHP Version: 5CVS-2006-05-16 (snap) New Comment: Recompiled MySQL from source today. PHP works fine now (together with SNMP). My experience with MyQSL supplied RPMs have been less than satisfactory lately. I had to recompile it also on my 64bit Linux system because PHP was refusing to use the supplied libmysql from the RPM (fPIC flag / relocation problem): http://bugs.mysql.com/bug.php?id=18091 Thanks for your support. Previous Comments: [2006-05-16 20:01:32] subscription at nazarenko dot net I will try to recompile MySQL and Net-Snmp from source and see if that helps. [2006-05-16 19:28:46] [EMAIL PROTECTED] It's good that you believe your system is ok. But I can hardly imagine someone else able to reproduce it. Since your backtrace contains absolutely minimal information too, I can only say that you'll have to debug it yourself. But as I've said, it looks like symbols clash between snmp and MySQL and it has nothing to do with PHP. Please reopen the report as soon as you have more information to provide. Until then - bogus. [2006-05-16 19:18:57] subscription at nazarenko dot net Thank you for addressing this issue. However, I find it hard to believe that my system is a mess, as you put it, since it is an aboslutely fresh install of newly released SuSE disribution with an *absolutely minimal* packages selection, no GUI and only the c++ compiler and tools. The output of the find and rpm command reveals that I have no different OpenSSL libraries installed: find / -type f -name libcrypto* /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.a find / -type f -name libcrypto* /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.a rpm -qa | grep ssl openssl-devel-0.9.8a-17 openssl-0.9.8a-17 There is no way some other OpenSSL libraries exist on this system. The only thing I can think of is that I did not compile openssl or net-snmp on this system, I installed the binaries from the distribution RPMs but that never created a problem before. [2006-05-16 18:27:30] [EMAIL PROTECTED] Yes. Looks like snmp and mysql were compiled with two different openssl libraries. Anyway this is not PHP problem, it's caused by a mess in your system. [2006-05-16 18:08:26] subscription at nazarenko dot net Is this of any help? #0 0x6568746f in ?? () #1 0xb7d0ebec in EVP_DigestInit_ex () from /usr/lib/libcrypto.so.0.9.8 #2 0xbfcd3204 in ?? () #3 0xb7d7bb4c in CAST_S_table7 () from /usr/lib/libcrypto.so.0.9.8 #4 0x00ca in ?? () #5 0x0001 in ?? () #6 0x in ?? () 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/37463 -- Edit this bug report at http://bugs.php.net/?id=37463edit=1
#37463 [Bgs-Opn]: Segmenation fault when both MySQLi and SNMP are enabled
ID: 37463 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Bogus +Status: Open Bug Type: MySQLi related Operating System: Linux SuSE 10.1 PHP Version: 5CVS-2006-05-16 (snap) New Comment: Opened the bug again because was not sure if you get to see the comments automatically when the status is bogus. Previous Comments: [2006-05-17 15:23:23] subscription at nazarenko dot net Recompiled MySQL from source today. PHP works fine now (together with SNMP). My experience with MyQSL supplied RPMs have been less than satisfactory lately. I had to recompile it also on my 64bit Linux system because PHP was refusing to use the supplied libmysql from the RPM (fPIC flag / relocation problem): http://bugs.mysql.com/bug.php?id=18091 Thanks for your support. [2006-05-16 20:01:32] subscription at nazarenko dot net I will try to recompile MySQL and Net-Snmp from source and see if that helps. [2006-05-16 19:28:46] [EMAIL PROTECTED] It's good that you believe your system is ok. But I can hardly imagine someone else able to reproduce it. Since your backtrace contains absolutely minimal information too, I can only say that you'll have to debug it yourself. But as I've said, it looks like symbols clash between snmp and MySQL and it has nothing to do with PHP. Please reopen the report as soon as you have more information to provide. Until then - bogus. [2006-05-16 19:18:57] subscription at nazarenko dot net Thank you for addressing this issue. However, I find it hard to believe that my system is a mess, as you put it, since it is an aboslutely fresh install of newly released SuSE disribution with an *absolutely minimal* packages selection, no GUI and only the c++ compiler and tools. The output of the find and rpm command reveals that I have no different OpenSSL libraries installed: find / -type f -name libcrypto* /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.a find / -type f -name libcrypto* /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.a rpm -qa | grep ssl openssl-devel-0.9.8a-17 openssl-0.9.8a-17 There is no way some other OpenSSL libraries exist on this system. The only thing I can think of is that I did not compile openssl or net-snmp on this system, I installed the binaries from the distribution RPMs but that never created a problem before. [2006-05-16 18:27:30] [EMAIL PROTECTED] Yes. Looks like snmp and mysql were compiled with two different openssl libraries. Anyway this is not PHP problem, it's caused by a mess in your system. 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/37463 -- Edit this bug report at http://bugs.php.net/?id=37463edit=1
#37463 [NEW]: Segmenation fault when both MySQLi and SNMP are enabled
From: subscription at nazarenko dot net Operating system: Linux SuSE 10.1 PHP version: 5CVS-2006-05-16 (snap) PHP Bug Type: MySQLi related Bug description: Segmenation fault when both MySQLi and SNMP are enabled Description: Trying to compile PHP CLI module with MySQL and SNMP support. When both are enabled php CLI SAPI gives segfault. When only one of them is enabled then everything looks normal. The libraries versions are as follows: MySQL 5.0.21 Net-SNMP 5.3.0.1 zlib 1.2.3 Reproduce code: --- ./configure --disable-all --with-mysqli --with-zlib sapi/cli/php -i produces normal output: MysqlI Support = enabled Client API library version = 5.0.21 Client API header version = 5.0.21 ./configure --disable-all --with-snmp sapi/cli/php -i produces normal output: NET-SNMP Support = enabled NET-SNMP Version = 5.3.0.1 Actual result: -- ./configure --disable-all --with-snmp --with-mysqli --with-zlib sapi/cli/php produces *Segfault* -- Edit bug report at http://bugs.php.net/?id=37463edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37463r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37463r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37463r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37463r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37463r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37463r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37463r=needscript Try newer version:http://bugs.php.net/fix.php?id=37463r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37463r=support Expected behavior:http://bugs.php.net/fix.php?id=37463r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37463r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37463r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37463r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37463r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37463r=dst IIS Stability:http://bugs.php.net/fix.php?id=37463r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37463r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37463r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37463r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37463r=mysqlcfg
#37463 [Fbk-Opn]: Segmenation fault when both MySQLi and SNMP are enabled
ID: 37463 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: MySQLi related Operating System: Linux SuSE 10.1 PHP Version: 5CVS-2006-05-16 (snap) New Comment: Is this of any help? #0 0x6568746f in ?? () #1 0xb7d0ebec in EVP_DigestInit_ex () from /usr/lib/libcrypto.so.0.9.8 #2 0xbfcd3204 in ?? () #3 0xb7d7bb4c in CAST_S_table7 () from /usr/lib/libcrypto.so.0.9.8 #4 0x00ca in ?? () #5 0x0001 in ?? () #6 0x in ?? () Previous Comments: [2006-05-16 17:58:25] [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. [2006-05-16 17:55:26] subscription at nazarenko dot net Description: Trying to compile PHP CLI module with MySQL and SNMP support. When both are enabled php CLI SAPI gives segfault. When only one of them is enabled then everything looks normal. The libraries versions are as follows: MySQL 5.0.21 Net-SNMP 5.3.0.1 zlib 1.2.3 Reproduce code: --- ./configure --disable-all --with-mysqli --with-zlib sapi/cli/php -i produces normal output: MysqlI Support = enabled Client API library version = 5.0.21 Client API header version = 5.0.21 ./configure --disable-all --with-snmp sapi/cli/php -i produces normal output: NET-SNMP Support = enabled NET-SNMP Version = 5.3.0.1 Actual result: -- ./configure --disable-all --with-snmp --with-mysqli --with-zlib sapi/cli/php produces *Segfault* -- Edit this bug report at http://bugs.php.net/?id=37463edit=1
#37463 [Bgs-Opn]: Segmenation fault when both MySQLi and SNMP are enabled
ID: 37463 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Bogus +Status: Open Bug Type: MySQLi related Operating System: Linux SuSE 10.1 PHP Version: 5CVS-2006-05-16 (snap) New Comment: Thank you for addressing this issue. However, I find it hard to believe that my system is a mess, as you put it, since it is an aboslutely fresh install of newly released SuSE disribution with an *absolutely minimal* packages selection, no GUI and only the c++ compiler and tools. The output of the find and rpm command reveals that I have no different OpenSSL libraries installed: find / -type f -name libcrypto* /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.a find / -type f -name libcrypto* /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.a rpm -qa | grep ssl openssl-devel-0.9.8a-17 openssl-0.9.8a-17 There is no way some other OpenSSL libraries exist on this system. The only thing I can think of is that I did not compile openssl or net-snmp on this system, I installed the binaries from the distribution RPMs but that never created a problem before. Previous Comments: [2006-05-16 18:27:30] [EMAIL PROTECTED] Yes. Looks like snmp and mysql were compiled with two different openssl libraries. Anyway this is not PHP problem, it's caused by a mess in your system. [2006-05-16 18:08:26] subscription at nazarenko dot net Is this of any help? #0 0x6568746f in ?? () #1 0xb7d0ebec in EVP_DigestInit_ex () from /usr/lib/libcrypto.so.0.9.8 #2 0xbfcd3204 in ?? () #3 0xb7d7bb4c in CAST_S_table7 () from /usr/lib/libcrypto.so.0.9.8 #4 0x00ca in ?? () #5 0x0001 in ?? () #6 0x in ?? () [2006-05-16 17:58:25] [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. [2006-05-16 17:55:26] subscription at nazarenko dot net Description: Trying to compile PHP CLI module with MySQL and SNMP support. When both are enabled php CLI SAPI gives segfault. When only one of them is enabled then everything looks normal. The libraries versions are as follows: MySQL 5.0.21 Net-SNMP 5.3.0.1 zlib 1.2.3 Reproduce code: --- ./configure --disable-all --with-mysqli --with-zlib sapi/cli/php -i produces normal output: MysqlI Support = enabled Client API library version = 5.0.21 Client API header version = 5.0.21 ./configure --disable-all --with-snmp sapi/cli/php -i produces normal output: NET-SNMP Support = enabled NET-SNMP Version = 5.3.0.1 Actual result: -- ./configure --disable-all --with-snmp --with-mysqli --with-zlib sapi/cli/php produces *Segfault* -- Edit this bug report at http://bugs.php.net/?id=37463edit=1
#37463 [Bgs]: Segmenation fault when both MySQLi and SNMP are enabled
ID: 37463 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net Status: Bogus Bug Type: MySQLi related Operating System: Linux SuSE 10.1 PHP Version: 5CVS-2006-05-16 (snap) New Comment: I will try to recompile MySQL and Net-Snmp from source and see if that helps. Previous Comments: [2006-05-16 19:28:46] [EMAIL PROTECTED] It's good that you believe your system is ok. But I can hardly imagine someone else able to reproduce it. Since your backtrace contains absolutely minimal information too, I can only say that you'll have to debug it yourself. But as I've said, it looks like symbols clash between snmp and MySQL and it has nothing to do with PHP. Please reopen the report as soon as you have more information to provide. Until then - bogus. [2006-05-16 19:18:57] subscription at nazarenko dot net Thank you for addressing this issue. However, I find it hard to believe that my system is a mess, as you put it, since it is an aboslutely fresh install of newly released SuSE disribution with an *absolutely minimal* packages selection, no GUI and only the c++ compiler and tools. The output of the find and rpm command reveals that I have no different OpenSSL libraries installed: find / -type f -name libcrypto* /usr/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.a find / -type f -name libcrypto* /usr/lib/libssl.so.0.9.8 /usr/lib/libssl.a rpm -qa | grep ssl openssl-devel-0.9.8a-17 openssl-0.9.8a-17 There is no way some other OpenSSL libraries exist on this system. The only thing I can think of is that I did not compile openssl or net-snmp on this system, I installed the binaries from the distribution RPMs but that never created a problem before. [2006-05-16 18:27:30] [EMAIL PROTECTED] Yes. Looks like snmp and mysql were compiled with two different openssl libraries. Anyway this is not PHP problem, it's caused by a mess in your system. [2006-05-16 18:08:26] subscription at nazarenko dot net Is this of any help? #0 0x6568746f in ?? () #1 0xb7d0ebec in EVP_DigestInit_ex () from /usr/lib/libcrypto.so.0.9.8 #2 0xbfcd3204 in ?? () #3 0xb7d7bb4c in CAST_S_table7 () from /usr/lib/libcrypto.so.0.9.8 #4 0x00ca in ?? () #5 0x0001 in ?? () #6 0x in ?? () [2006-05-16 17:58:25] [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. 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/37463 -- Edit this bug report at http://bugs.php.net/?id=37463edit=1
#37306 [Com]: max_execution_time = max_input_time
ID: 37306
Comment by: subscription at nazarenko dot net
Reported By: php at placebo dot demon dot nl
Status: Open
Bug Type: PHP options/info functions
Operating System: Windows 2000
PHP Version: 5CVS-2006-05-04 (snap)
New Comment:
I have a similar problem too.
However, what I've found is not *exactly* the case described here.
I have many CLI scripts which I use with the PHP-CLI (Linux).
Most of them work fine, however one script that does the indexing of
lots of documents fails after a few *minutes* with the error message:
Maximum execution time of 30 seconds exceeded.
My php-cli.ini settings are as follows:
max_execution_time = 0 = 60
max_input_time = 30 = 30
Since only one of my scripts fails with that message afer running for
*MORE* than 30 or 60 seconds and other scripts (PHP-CLI based daemons)
run fine 24/7, I can see three issues here:
1) It is very likely to do with the *max input time*, not max execution
time.
2) The error message is wrong. I believe it should be Maximum input
time of 30 seconds exceeded
3) Even if input time is more than the limit, it should not break a
script run under PHP-CLI.
Previous Comments:
[2006-05-04 13:32:12] n dot escuder at intra-links dot com
The same problems can be reproduced on linux platform with php 5.1.3
CLI and this break all scripts who work with the CLI version that have
a main loop.
[2006-05-04 12:42:26] php at placebo dot demon dot nl
Description:
PHP 5.1.3 and up uses the max_input_time php.ini setting for the
maximum execution time of a script. It should you the
max_execution_time setting.
correct 5.1.2
wrong 5.1.3
wrong 5.1.5-dev Built On: May 04, 2006 06:30 GMT
Reproduce code:
---
php.ini setting:
max_execution_time = 1
max_input_time = 5
code:
$time_end = time() + 10;
while (time() = $time_end) {
}
Expected result:
Fatal error: Maximum execution time of 1 seconds exceeded in
c:\Apache\htdocs\site\test.php on line 23
Actual result:
--
Fatal error: Maximum execution time of 5 seconds exceeded in
c:\Apache\htdocs\site\test.php on line 23
--
Edit this bug report at http://bugs.php.net/?id=37306edit=1
#37306 [Com]: max_execution_time = max_input_time
ID: 37306
Comment by: subscription at nazarenko dot net
Reported By: php at placebo dot demon dot nl
Status: Open
Bug Type: PHP options/info functions
Operating System: Windows 2000
PHP Version: 5CVS-2006-05-04 (snap)
New Comment:
OK. After additional testing I must take back some of my comments
above. It looks like the original poster was correct :)
1) max_input_time value becomes max_execution_time
2) CLI SAPI which normally should ignore max_execution_time breaks
scripts with the error messages about execution time.
NOTE: setting max_input_time and max_execution_time to 0 in
php-cli.ini fixes the problem but I still believe this is a bug which
must be fixed ASAP.
Previous Comments:
[2006-05-04 19:37:27] subscription at nazarenko dot net
I have a similar problem too.
However, what I've found is not *exactly* the case described here.
I have many CLI scripts which I use with the PHP-CLI (Linux).
Most of them work fine, however one script that does the indexing of
lots of documents fails after a few *minutes* with the error message:
Maximum execution time of 30 seconds exceeded.
My php-cli.ini settings are as follows:
max_execution_time = 0 = 60
max_input_time = 30 = 30
Since only one of my scripts fails with that message afer running for
*MORE* than 30 or 60 seconds and other scripts (PHP-CLI based daemons)
run fine 24/7, I can see three issues here:
1) It is very likely to do with the *max input time*, not max execution
time.
2) The error message is wrong. I believe it should be Maximum input
time of 30 seconds exceeded
3) Even if input time is more than the limit, it should not break a
script run under PHP-CLI.
[2006-05-04 13:32:12] n dot escuder at intra-links dot com
The same problems can be reproduced on linux platform with php 5.1.3
CLI and this break all scripts who work with the CLI version that have
a main loop.
[2006-05-04 12:42:26] php at placebo dot demon dot nl
Description:
PHP 5.1.3 and up uses the max_input_time php.ini setting for the
maximum execution time of a script. It should you the
max_execution_time setting.
correct 5.1.2
wrong 5.1.3
wrong 5.1.5-dev Built On: May 04, 2006 06:30 GMT
Reproduce code:
---
php.ini setting:
max_execution_time = 1
max_input_time = 5
code:
$time_end = time() + 10;
while (time() = $time_end) {
}
Expected result:
Fatal error: Maximum execution time of 1 seconds exceeded in
c:\Apache\htdocs\site\test.php on line 23
Actual result:
--
Fatal error: Maximum execution time of 5 seconds exceeded in
c:\Apache\htdocs\site\test.php on line 23
--
Edit this bug report at http://bugs.php.net/?id=37306edit=1
#33770 [NoF-Opn]: https:// or ftps:// do not work when --with-curlwrappers is used
ID: 33770 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: No Feedback +Status: Open Bug Type: cURL related -Operating System: Linux SuSE 9.3 10.0 +Operating System: Linux SuSE 10.0 -PHP Version: 5CVS-2005-11-09 (snap) +PHP Version: 5CVS-2006-01-13 (snap) New Comment: Tried the 200601131530 snapshot. OpenSSL libs: 0.9.7g Curl libs: 7.14.0 Same result. HTTPS works only when --with-curlwrappers is not used. Previous Comments: [2006-01-01 01:00:06] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-12-24 02:36:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-11-10 00:15:48] subscription at nazarenko dot net Here is the result after compiling with --with-curlwrappers: /install/php5-200511091730/sapi/cli/php -i | grep Registered Registered PHP Streams = php, file, ftp, gopher, telnet, dict, ldap, http, https, ftps Registered Stream Socket Transports = tcp, udp, unix, udg, ssl, sslv3, sslv2, tls Registered Stream Filters = string.rot13, string.toupper, string.tolower, string.strip_tags, convert.* /install/php5-200511091730/sapi/cli/php -i | grep fopen allow_url_fopen = On = On [2005-11-09 23:59:32] subscription at nazarenko dot net If you mean 'you do have the 64bit versions of those installed?' question, the answer is: Yes, I do. Here is the output of rpm commands: rpm -q --provides openssl-0.9.7g-2.2 ssl libcrypto.so.0.9.7()(64bit) libssl.so.0.9.7()(64bit) openssl = 0.9.7g-2.2 rpm -q --provides curl-7.14.0-2.2 curl_ssl libcurl.so.3()(64bit) curl = 7.14.0-2.2 Also, my 'allow_url_fopen' is On (otherwise no test case would work) I have to stress this fact: absolutely nothing has been changed between the two tests, no php.ini settings, no libraries installed, no system variables, etc. except the --with-curlwrappers directive. In once case https works in the other one it does not. [2005-08-06 20:06:39] [EMAIL PROTECTED] Make sure you have allow_url_fopen turned on in your php.ini file and that you can see https listed on your phpinfo() output. 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/33770 -- Edit this bug report at http://bugs.php.net/?id=33770edit=1
#35175 [NEW]: Not all function names are changed to documentation links in error messages
From: subscription at nazarenko dot net
Operating system: SuSE Linux 10.0
PHP version: 5CVS-2005-11-09 (snap)
PHP Bug Type: PHP options/info functions
Bug description: Not all function names are changed to documentation links in
error messages
Description:
When 'html_errors=On' and 'docref_root' and 'docref_ext' are set, not all
warnings/errors become html links to the documentation.
It seems that the warnings about wrong function arguments do not generate
html links, whereas failed function calls with the properly given
arguments do so.
Reproduce code:
---
A fragment of php.ini:
error_reporting = E_ALL|E_STRICT
display_errors = On
html_errors = On
docref_root = http://de.php.net/manual/en/;
docref_ext = .php
And then the test script:
?php
str_replace('one','two');
mysqli_connect('fake');
?
Produces this html:
br /
bWarning/b: Wrong parameter count for str_replace() in bx.php/b
on line b3/bbr /
br /
bWarning/b: mysqli_connect() [a
href='http://de.php.net/manual/en/function.mysqli-connect.php'function.mysqli-connect.php/a]:
(HY000/2005): Unknown MySQL server host 'fake' (1) in bx.php/b on line
b4/bbr /
Expected result:
I think it would be MUCH more useful for a developer to get links to the
documentation when there are inconsistencies in a function arguments (and
such), rather than when the function call actually failed with the
properly specified arguments.
When the function returns an error or warning it is often 'too late' to
look into the documentation. On the other hand, very often an error is
made in a number/order/type of function arguments, i.e. before the
function is called, which is when the documentation is very handy.
--
Edit bug report at http://bugs.php.net/?id=35175edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35175r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35175r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35175r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35175r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35175r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35175r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35175r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35175r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35175r=support
Expected behavior: http://bugs.php.net/fix.php?id=35175r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35175r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35175r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35175r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35175r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35175r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35175r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35175r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35175r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35175r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35175r=mysqlcfg
#35176 [NEW]: include()/require()/*_once() produce wrong error messages about main()
From: subscription at nazarenko dot net Operating system: SuSE Linux 10.0 PHP version: 5CVS-2005-11-09 (CVS) PHP Bug Type: PHP options/info functions Bug description: include()/require()/*_once() produce wrong error messages about main() Description: According to this page: http://www.php.net/manual/en/function.main.php the misbehaviour was stopped in PHP 4.3.2, however it is still present in the latest 5.1.x snapshot. In addition when require_once() or include_once() call fails and html_errors is On the error message HTML link points to the same function require() or include(), without the _once() part in it. -- Edit bug report at http://bugs.php.net/?id=35176edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35176r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35176r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35176r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35176r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35176r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35176r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35176r=needscript Try newer version: http://bugs.php.net/fix.php?id=35176r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35176r=support Expected behavior: http://bugs.php.net/fix.php?id=35176r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35176r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35176r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35176r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35176r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35176r=dst IIS Stability: http://bugs.php.net/fix.php?id=35176r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35176r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35176r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35176r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35176r=mysqlcfg
#35176 [Opn]: include()/require()/*_once() produce wrong error messages about main()
ID: 35176
User updated by: subscription at nazarenko dot net
Reported By: subscription at nazarenko dot net
Status: Open
Bug Type: PHP options/info functions
Operating System: SuSE Linux 10.0
PHP Version: 5CVS-2005-11-09 (CVS)
New Comment:
Sorry, the script above should have
require_once('fake');
Previous Comments:
[2005-11-09 22:06:47] subscription at nazarenko dot net
A sample script:
?php
require_once('nonexisting');
?
Produces this HTML (html_errors=on):
bWarning/b: main(fake) [a
href='http://www.php.net/manual/en/function.main.php'function.main.php/a]:
failed to open stream: No such file or directory in bx.php/b on line
b2/bbr /
/span
bFatal error/b: main() [a
href='http://www.php.net/manual/en/function.require.php'function.require.php/a]:
Failed opening required 'fake' (include_path='.:/usr/lib/php') in
bx.php/b on line b2/bbr /
This illustrates both points: the erroneous main() function as well as
the wrong html link (should be funtion.require-once.php)
[2005-11-09 21:56:51] [EMAIL PROTECTED]
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 ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-11-09 21:50:35] subscription at nazarenko dot net
Description:
According to this page:
http://www.php.net/manual/en/function.main.php
the misbehaviour was stopped in PHP 4.3.2, however it is still present
in the latest 5.1.x snapshot.
In addition when require_once() or include_once() call fails and
html_errors is On the error message HTML link points to the same
function require() or include(), without the _once() part in it.
--
Edit this bug report at http://bugs.php.net/?id=35176edit=1
#33770 [NoF-Opn]: https:// or ftps:// do not work with both --with-openssl and --with-curlwrappers
ID: 33770 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: No Feedback +Status: Open Bug Type: OpenSSL related -Operating System: Linux SuSE 9.3 +Operating System: Linux SuSE 9.3 10.0 -PHP Version: 5CVS-2005-07-19 +PHP Version: 5CVS-2005-11-09 New Comment: Just to confirm that I am still having this problem. Tried under new SuSE 10.0-OSS, as well as under SuSE 9.3 (both running on Intel Xeon x86_64smp ). Used newer OpenSSL and CURL libs: curl-7.14.0 openssl-0.9.7g Still the same problem: https works: ./configure --disable-all --disable-cgi --with-openssl \ --with-curl https does not work: ./configure --disable-all --disable-cgi --with-openssl \ --with-curl --with-curlwrappers Previous Comments: [2005-08-14 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-08-06 20:06:39] [EMAIL PROTECTED] Make sure you have allow_url_fopen turned on in your php.ini file and that you can see https listed on your phpinfo() output. [2005-08-06 03:00:32] [EMAIL PROTECTED] I'm using these libs: openssl 0.9.7f curl 7.13.1 So try upgrade those. (you do have the 64bit versions of those installed?) [2005-08-02 19:33:15] subscription at nazarenko dot net Tried php5-200508021630 CVS snapshot. https works: ./configure --disable-all --disable-cgi --with-openssl --with-curl https does not work: ./configure --disable-all --disable-cgi --with-openssl --with-curl --with-curlwrappers My machine is x64 Linux (SuSE 9.3) OpenSSL libraries: openssl-devel-0.9.7e-3 CURL libraries: curl-devel-7.13.0-5 [2005-08-02 07:57:46] [EMAIL PROTECTED] I can't reproduce this, with having both of those configure options enabled the same time. Please try latest CVS snapshot. 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/33770 -- Edit this bug report at http://bugs.php.net/?id=33770edit=1
#33770 [Fbk-Opn]: https:// or ftps:// do not work with both --with-openssl and --with-curlwrappers
ID: 33770 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 10.0 PHP Version: 5CVS-2005-11-09 New Comment: If you mean 'you do have the 64bit versions of those installed?' question, the answer is: Yes, I do. Here is the output of rpm commands: rpm -q --provides openssl-0.9.7g-2.2 ssl libcrypto.so.0.9.7()(64bit) libssl.so.0.9.7()(64bit) openssl = 0.9.7g-2.2 rpm -q --provides curl-7.14.0-2.2 curl_ssl libcurl.so.3()(64bit) curl = 7.14.0-2.2 Also, my 'allow_url_fopen' is On (otherwise no test case would work) I have to stress this fact: absolutely nothing has been changed between the two tests, no php.ini settings, no libraries installed, no system variables, etc. except the --with-curlwrappers directive. In once case https works in the other one it does not. Previous Comments: [2005-11-09 23:41:40] [EMAIL PROTECTED] Please provide the information you were asked for. [2005-11-09 23:31:47] subscription at nazarenko dot net Just to confirm that I am still having this problem. Tried under new SuSE 10.0-OSS, as well as under SuSE 9.3 (both running on Intel Xeon x86_64smp ). Used newer OpenSSL and CURL libs: curl-7.14.0 openssl-0.9.7g Still the same problem: https works: ./configure --disable-all --disable-cgi --with-openssl \ --with-curl https does not work: ./configure --disable-all --disable-cgi --with-openssl \ --with-curl --with-curlwrappers [2005-08-14 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-08-06 20:06:39] [EMAIL PROTECTED] Make sure you have allow_url_fopen turned on in your php.ini file and that you can see https listed on your phpinfo() output. [2005-08-06 03:00:32] [EMAIL PROTECTED] I'm using these libs: openssl 0.9.7f curl 7.13.1 So try upgrade those. (you do have the 64bit versions of those installed?) 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/33770 -- Edit this bug report at http://bugs.php.net/?id=33770edit=1
#33770 [Fbk-Opn]: https:// or ftps:// do not work with both --with-openssl and --with-curlwrappers
ID: 33770 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 10.0 PHP Version: 5CVS-2005-11-09 New Comment: Here is the result after compiling with --with-curlwrappers: /install/php5-200511091730/sapi/cli/php -i | grep Registered Registered PHP Streams = php, file, ftp, gopher, telnet, dict, ldap, http, https, ftps Registered Stream Socket Transports = tcp, udp, unix, udg, ssl, sslv3, sslv2, tls Registered Stream Filters = string.rot13, string.toupper, string.tolower, string.strip_tags, convert.* /install/php5-200511091730/sapi/cli/php -i | grep fopen allow_url_fopen = On = On Previous Comments: [2005-11-10 00:01:34] [EMAIL PROTECTED] No, I mean this: [6 Aug 8:06pm CEST] [EMAIL PROTECTED] Make sure you have allow_url_fopen turned on in your php.ini file and that you can see https listed on your phpinfo() output. [2005-11-09 23:59:32] subscription at nazarenko dot net If you mean 'you do have the 64bit versions of those installed?' question, the answer is: Yes, I do. Here is the output of rpm commands: rpm -q --provides openssl-0.9.7g-2.2 ssl libcrypto.so.0.9.7()(64bit) libssl.so.0.9.7()(64bit) openssl = 0.9.7g-2.2 rpm -q --provides curl-7.14.0-2.2 curl_ssl libcurl.so.3()(64bit) curl = 7.14.0-2.2 Also, my 'allow_url_fopen' is On (otherwise no test case would work) I have to stress this fact: absolutely nothing has been changed between the two tests, no php.ini settings, no libraries installed, no system variables, etc. except the --with-curlwrappers directive. In once case https works in the other one it does not. [2005-11-09 23:41:40] [EMAIL PROTECTED] Please provide the information you were asked for. [2005-11-09 23:31:47] subscription at nazarenko dot net Just to confirm that I am still having this problem. Tried under new SuSE 10.0-OSS, as well as under SuSE 9.3 (both running on Intel Xeon x86_64smp ). Used newer OpenSSL and CURL libs: curl-7.14.0 openssl-0.9.7g Still the same problem: https works: ./configure --disable-all --disable-cgi --with-openssl \ --with-curl https does not work: ./configure --disable-all --disable-cgi --with-openssl \ --with-curl --with-curlwrappers [2005-08-14 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. 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/33770 -- Edit this bug report at http://bugs.php.net/?id=33770edit=1
#32081 [Fbk-Opn]: mysqli_real_connect(): mysqli.default_socket in php.ini has no effect
ID: 32081
User updated by: subscription at nazarenko dot net
Reported By: subscription at nazarenko dot net
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: *
PHP Version: 5CVS-2005-09-08
New Comment:
As I specified it in my last comment, safe mode was off.
What I am trying to say is that in all the testing scenarios the socket
was never speified in a function call and the behaviour of
mysqli_connect() and mysqli_real_connect() is not the same.
mysql_connect() does use the mysqli.default_socket value and it does
not matter if I specify user/password in a function call or not.
mysqli_real_connect() never uses the mysqli.default_socket value,
whether user/password are given in a function call or not.
Previous Comments:
[2005-09-08 07:39:19] [EMAIL PROTECTED]
And you do not have safe_mode on??
[2005-09-08 00:40:50] subscription at nazarenko dot net
Sorry, you comment is not true.
Both mysql*_connect functions, if called this way:
mysql_connect('','user','password')
mysqli_connect('','user','password')
do use mysql*.default_host/mysql*.default_socket from the php.ini. See
my example with mysqli_connect() above.
It is ONLY mysqli_real_connect() called this way:
mysqli_real_connect($db_obj, '', 'user', 'password')
that does not use the values from php.ini.
Just to dismiss the argument completely I have tried setting all
mysqli.default_* parameters in the php.ini to proper values (safe mode
off) and then calling mysqli_real_connect() this way:
$db=mysqli_init();
mysqli_real_connect($db);
I am still connection error and see that the mysqli_real_connect() is
trying to use the hard-coded socket value, which is different from the
php.ini
[2005-09-07 13:48:21] [EMAIL PROTECTED]
The defaults are only used if you don't pass any parameters to these
connect functions.
[2005-09-07 11:40:00] subscription at nazarenko dot net
Tried the php5-200509070630 snapshot.
The settings in the php.ini file are:
error_reporting = E_ALL
display_errors = On
mysqli.default_socket = /srv/mysql/mysql.sock
mysqli.default_host = localhost
Used this code for testing:
?
$db = mysqli_connect('','user','password');
var_dump($db);
close ($db);
echo ---\n;
$dbr = mysqli_init();
var_dump (mysqli_real_connect ($dbr, '', 'user', 'password'));
mysqli_close($dbr);
?
This produces the following ouput:
object(mysqli)#1 (0)
---
Warning: mysqli_real_connect(): (HY000/2002): Can't connect to local
MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
bool(false)
So it confirms that mysqli_real_connect() is still ignoring the php.ini
setting.
[2005-09-05 15:36:55] subscription at nazarenko dot net
I have to reopen this bug.
mysqli_connect() treats the mysqli.default_socket OK.
mysqli_real_connect() still takes the hardcoded value and ignores the
php.ini setting
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/32081
--
Edit this bug report at http://bugs.php.net/?id=32081edit=1
#32081 [Fbk-Opn]: mysqli_real_connect(): mysqli.default_socket in php.ini has no effect
ID: 32081
User updated by: subscription at nazarenko dot net
Reported By: subscription at nazarenko dot net
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Linux SuSE 9.3 (64bit)
PHP Version: 5.0.4
New Comment:
Tried the php5-200509070630 snapshot.
The settings in the php.ini file are:
error_reporting = E_ALL
display_errors = On
mysqli.default_socket = /srv/mysql/mysql.sock
mysqli.default_host = localhost
Used this code for testing:
?
$db = mysqli_connect('','user','password');
var_dump($db);
close ($db);
echo ---\n;
$dbr = mysqli_init();
var_dump (mysqli_real_connect ($dbr, '', 'user', 'password'));
mysqli_close($dbr);
?
This produces the following ouput:
object(mysqli)#1 (0)
---
Warning: mysqli_real_connect(): (HY000/2002): Can't connect to local
MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
bool(false)
So it confirms that mysqli_real_connect() is still ignoring the php.ini
setting.
Previous Comments:
[2005-09-05 23:38:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-09-05 15:36:55] subscription at nazarenko dot net
I have to reopen this bug.
mysqli_connect() treats the mysqli.default_socket OK.
mysqli_real_connect() still takes the hardcoded value and ignores the
php.ini setting
[2005-02-25 01:00:01] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2005-02-23 15:53:33] subscription at nazarenko dot net
Description:
I am running MySQL 4.1.10 and PHP 5.0.3.
By default, on SuSE MySQL uses /var/lib/mysql/mysql.sock.
I changed the location of the MySQL socket to /srv/mysql/mysql.sock
in /etc/my.cnf and MySQL is fine with it.
In my php.ini I have set mysqli.default_socket to the new socket
/srv/mysql/mysql.sock.
Reproduce code:
---
The code:
$mysqli = mysqli_init();
$mysqli-real_connect('localhost', SQL_LOGIN, SQL_PASSWD);
produces the following warning:
mysqli::real_connect(): Can't connect to local MySQL server through
socket '/var/lib/mysql/mysql.sock' (2) in /srv/www/htdocs/index.php on
line 10
Expected result:
Since the socket value was omitted, it is expected that PHP uses the
default sockeet value from the php.ini file.
The error shows that the default socket value for MySQLi is ignored by
PHP.
Actual result:
--
When I first run phpinfo() I got the following output:
Client API version 4.1.10
MYSQLI_SOCKET/var/lib/mysql/mysql.sock
mysqli.default_socket/srv/mysql/mysql.sock
This made 3 things clear:
1) mysqli.default_socket variable *IS* correctly read from php.ini
2) mysqli.default_socket variable is *IGNORED* by the PHP interpreter
3) there is some variable called MYSQLI_SOCKET which is still set to
the old-default socket
I searched in the header files of MySQL and found a file called
/usr/include/mysql/mysql_version.h, which contained a line:
#define MYSQL_UNIX_ADDR /var/lib/mysql/mysql.sock
I changed it to /srv/mysql/mysql.sock and recompiled PHP again.
This time phpinfo() gave the following output:
Client API version 4.1.10
MYSQLI_SOCKET/srv/mysql/mysql.sock
mysqli.default_socket/srv/mysql/mysql.sock
However, the problem was not gone!
mysqli_real_connect() was still trying to use the hard-coded (?)
value from MySQL server /var/lib/mysql/mysql.sock.
Adding --with-mysql-sock=/srv/mysql/mysql.sock to the configure options
list did not help either. I guess this is by design as --with-mysql-sock
is not a MySQLi related option anyway.
--
Edit this bug report at http://bugs.php.net/?id=32081edit=1
#32081 [Csd-Opn]: mysqli_real_connect(): mysqli.default_socket in php.ini has no effect
ID: 32081
User updated by: subscription at nazarenko dot net
Reported By: subscription at nazarenko dot net
-Status: Closed
+Status: Open
Bug Type: MySQLi related
Operating System: Linux SuSE 9.3 (64bit)
-PHP Version: 5.0.4
+PHP Version: 5.0.5 and 5.1 CVS
New Comment:
Sorry, you comment is not true.
Both mysql*_connect functions, if called this way:
mysql_connect('','user','password')
mysqli_connect('','user','password')
do use mysql*.default_host/mysql*.default_socket from the php.ini. See
my example with mysqli_connect() above.
It is ONLY mysqli_real_connect() called this way:
mysqli_real_connect($db_obj, '', 'user', 'password')
that does not use the values from php.ini.
Just to dismiss the argument completely I have tried setting all
mysqli.default_* parameters in the php.ini to proper values (safe mode
off) and then calling mysqli_real_connect() this way:
$db=mysqli_init();
mysqli_real_connect($db);
I am still connection error and see that the mysqli_real_connect() is
trying to use the hard-coded socket value, which is different from the
php.ini
Previous Comments:
[2005-09-07 13:48:21] [EMAIL PROTECTED]
The defaults are only used if you don't pass any parameters to these
connect functions.
[2005-09-07 11:40:00] subscription at nazarenko dot net
Tried the php5-200509070630 snapshot.
The settings in the php.ini file are:
error_reporting = E_ALL
display_errors = On
mysqli.default_socket = /srv/mysql/mysql.sock
mysqli.default_host = localhost
Used this code for testing:
?
$db = mysqli_connect('','user','password');
var_dump($db);
close ($db);
echo ---\n;
$dbr = mysqli_init();
var_dump (mysqli_real_connect ($dbr, '', 'user', 'password'));
mysqli_close($dbr);
?
This produces the following ouput:
object(mysqli)#1 (0)
---
Warning: mysqli_real_connect(): (HY000/2002): Can't connect to local
MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
bool(false)
So it confirms that mysqli_real_connect() is still ignoring the php.ini
setting.
[2005-09-05 23:38:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-09-05 15:36:55] subscription at nazarenko dot net
I have to reopen this bug.
mysqli_connect() treats the mysqli.default_socket OK.
mysqli_real_connect() still takes the hardcoded value and ignores the
php.ini setting
[2005-02-25 01:00:01] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
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/32081
--
Edit this bug report at http://bugs.php.net/?id=32081edit=1
#32081 [Csd-Opn]: mysqli_real_connect(): mysqli.default_socket in php.ini has no effect
ID: 32081
User updated by: subscription at nazarenko dot net
-Summary: Setting mysqli.default_socket in php.ini has no effect
Reported By: subscription at nazarenko dot net
-Status: Closed
+Status: Open
Bug Type: MySQLi related
-Operating System: Linux SuSE 8.2
+Operating System: Linux SuSE 9.3 (64bit)
-PHP Version: 5.0.3
+PHP Version: 5.0.4
New Comment:
I have to reopen this bug.
mysqli_connect() treats the mysqli.default_socket OK.
mysqli_real_connect() still takes the hardcoded value and ignores the
php.ini setting
Previous Comments:
[2005-02-25 01:00:01] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2005-02-23 15:53:33] subscription at nazarenko dot net
Description:
I am running MySQL 4.1.10 and PHP 5.0.3.
By default, on SuSE MySQL uses /var/lib/mysql/mysql.sock.
I changed the location of the MySQL socket to /srv/mysql/mysql.sock
in /etc/my.cnf and MySQL is fine with it.
In my php.ini I have set mysqli.default_socket to the new socket
/srv/mysql/mysql.sock.
Reproduce code:
---
The code:
$mysqli = mysqli_init();
$mysqli-real_connect('localhost', SQL_LOGIN, SQL_PASSWD);
produces the following warning:
mysqli::real_connect(): Can't connect to local MySQL server through
socket '/var/lib/mysql/mysql.sock' (2) in /srv/www/htdocs/index.php on
line 10
Expected result:
Since the socket value was omitted, it is expected that PHP uses the
default sockeet value from the php.ini file.
The error shows that the default socket value for MySQLi is ignored by
PHP.
Actual result:
--
When I first run phpinfo() I got the following output:
Client API version 4.1.10
MYSQLI_SOCKET/var/lib/mysql/mysql.sock
mysqli.default_socket/srv/mysql/mysql.sock
This made 3 things clear:
1) mysqli.default_socket variable *IS* correctly read from php.ini
2) mysqli.default_socket variable is *IGNORED* by the PHP interpreter
3) there is some variable called MYSQLI_SOCKET which is still set to
the old-default socket
I searched in the header files of MySQL and found a file called
/usr/include/mysql/mysql_version.h, which contained a line:
#define MYSQL_UNIX_ADDR /var/lib/mysql/mysql.sock
I changed it to /srv/mysql/mysql.sock and recompiled PHP again.
This time phpinfo() gave the following output:
Client API version 4.1.10
MYSQLI_SOCKET/srv/mysql/mysql.sock
mysqli.default_socket/srv/mysql/mysql.sock
However, the problem was not gone!
mysqli_real_connect() was still trying to use the hard-coded (?)
value from MySQL server /var/lib/mysql/mysql.sock.
Adding --with-mysql-sock=/srv/mysql/mysql.sock to the configure options
list did not help either. I guess this is by design as --with-mysql-sock
is not a MySQLi related option anyway.
--
Edit this bug report at http://bugs.php.net/?id=32081edit=1
#33770 [Fbk-Opn]: https:// or ftps:// do not work with both --with-openssl and --with-curlwrappers
ID: 33770 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 PHP Version: 5CVS-2005-07-19 New Comment: Tried php5-200508021630 CVS snapshot. https works: ./configure --disable-all --disable-cgi --with-openssl --with-curl https does not work: ./configure --disable-all --disable-cgi --with-openssl --with-curl --with-curlwrappers My machine is x64 Linux (SuSE 9.3) OpenSSL libraries: openssl-devel-0.9.7e-3 CURL libraries: curl-devel-7.13.0-5 Previous Comments: [2005-08-02 07:57:46] [EMAIL PROTECTED] I can't reproduce this, with having both of those configure options enabled the same time. Please try latest CVS snapshot. [2005-07-20 12:59:32] subscription at nazarenko dot net Since the issue of OpenSSL/https is being looked now, I want to mention something about working with https:// (when it works). Feel free to delete this if you think it is irrelevant to the case and I will try to open a new report then. The PHP file() function manual states: Warning: When using SSL, Microsoft IIS will violate the protocol by closing the connection without sending a close_notify indicator. PHP will report this as SSL: Fatal Protocol Error when you reach the end of the data. To workaround this, you should lower your error_reporting level not to include warnings. PHP 4.3.7 and higher can detect buggy IIS server software when you open the stream using the https:// wrapper and will suppress the warning for you. This is not the case with 5.x.x, in other words, I understand I should not be getting this warning, however I do get it. [2005-07-20 00:48:35] subscription at nazarenko dot net Thank you for a speedy response. Indeed, with the minimal configure, it started working again. After 1 hour of mixing and matching the modules I found the culprit. It is: curl-7.13.0 libraries compiled in with the following parameters: --with-curl --with-curlwrappers Actually, without --with-curlwrappers it works fine. Tested both for 5.0.4 and 5CVS [2005-07-19 21:32:47] [EMAIL PROTECTED] Works fine for me under FC4 x86_64smp. Try with this configure line: ./configure --disable-all --disable-cgi --with-openssl And use sapi/cli/php to run your script. [2005-07-19 21:23:47] [EMAIL PROTECTED] subscription at nazarenko dot net: Tried the latest snapshot as advised. Same effect as before, the problem persists. Test script: ?php var_dump(file(https://host2/;)); ? Both host1 and host2 are on the same subnet. (do NOT add any huge outputs of anything unless asked for!) 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/33770 -- Edit this bug report at http://bugs.php.net/?id=33770edit=1
#33770 [Opn]: https:// or ftps:// do not work with --with-openssl and --with-curlwrappers
ID: 33770 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net Status: Open Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 PHP Version: 5CVS-2005-07-19 New Comment: Since the issue of OpenSSL/https is being looked now, I want to mention something about working with https:// (when it works). Feel free to delete this if you think it is irrelevant to the case and I will try to open a new report then. The PHP file() function manual states: Warning: When using SSL, Microsoft IIS will violate the protocol by closing the connection without sending a close_notify indicator. PHP will report this as SSL: Fatal Protocol Error when you reach the end of the data. To workaround this, you should lower your error_reporting level not to include warnings. PHP 4.3.7 and higher can detect buggy IIS server software when you open the stream using the https:// wrapper and will suppress the warning for you. This is not the case with 5.x.x, in other words, I understand I should not be getting this warning, however I do get it. Previous Comments: [2005-07-20 00:48:35] subscription at nazarenko dot net Thank you for a speedy response. Indeed, with the minimal configure, it started working again. After 1 hour of mixing and matching the modules I found the culprit. It is: curl-7.13.0 libraries compiled in with the following parameters: --with-curl --with-curlwrappers Actually, without --with-curlwrappers it works fine. Tested both for 5.0.4 and 5CVS [2005-07-19 21:32:47] [EMAIL PROTECTED] Works fine for me under FC4 x86_64smp. Try with this configure line: ./configure --disable-all --disable-cgi --with-openssl And use sapi/cli/php to run your script. [2005-07-19 21:23:47] [EMAIL PROTECTED] subscription at nazarenko dot net: Tried the latest snapshot as advised. Same effect as before, the problem persists. Test script: ?php var_dump(file(https://host2/;)); ? Both host1 and host2 are on the same subnet. (do NOT add any huge outputs of anything unless asked for!) [2005-07-19 14:38:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-19 14:35:37] subscription at nazarenko dot net Description: I have 64bit SuSE 9.3 and try to use file() function to read a webpage via http/https. The http protocol is ok, however https returns empty result without any errors/notices (E_ALL is on). I have compiled in OpenSSL support (OpenSSL is v0.9.7e). I have another machine with 32bit Linux on it in the same network, I have compiled PHP with similar settings and https works fine on it. Reproduce code: --- Using the following configure: ./configure --with-snmp --enable-cli --with-curl \ -disable-dom --prefix=/usr --disable-cgi \ --disable-spl --disable-xml --without-pear \ --disable-ipv6 --enable-shmop --enable-pcntl \ --without-iconv --disable-ctype --disable-libxml \ --enable-sysvsem --enable-sysvshm --enable-sockets \ --without-sqlite --disable-session --enable-sigchild \ --disable-simplexml --disable-tokenizer \ --with-curlwrappers --enable-memory-limit \ --enable-discard-path --program-suffix=-net \ --enable-ucd-snmp-hack --with-config-file-path=/etc \ --with-mysqli=/usr/bin/mysql_config -- Edit this bug report at http://bugs.php.net/?id=33770edit=1
#33770 [NEW]: file() does not work with https on 64-bit Linux
From: subscription at nazarenko dot net Operating system: Linux SuSE 9.3 PHP version: 5.0.4 PHP Bug Type: OpenSSL related Bug description: file() does not work with https on 64-bit Linux Description: I have 64bit SuSE 9.3 and try to use file() function to read a webpage via http/https. The http protocol is ok, however https returns empty result without any errors/notices (E_ALL is on). I have compiled in OpenSSL support (OpenSSL is v0.9.7e). I have another machine with 32bit Linux on it in the same network, I have compiled PHP with similar settings and https works fine on it. Reproduce code: --- Using the following configure: ./configure --with-snmp --enable-cli --with-curl \ -disable-dom --prefix=/usr --disable-cgi \ --disable-spl --disable-xml --without-pear \ --disable-ipv6 --enable-shmop --enable-pcntl \ --without-iconv --disable-ctype --disable-libxml \ --enable-sysvsem --enable-sysvshm --enable-sockets \ --without-sqlite --disable-session --enable-sigchild \ --disable-simplexml --disable-tokenizer \ --with-curlwrappers --enable-memory-limit \ --enable-discard-path --program-suffix=-net \ --enable-ucd-snmp-hack --with-config-file-path=/etc \ --with-mysqli=/usr/bin/mysql_config -- Edit bug report at http://bugs.php.net/?id=33770edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33770r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33770r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33770r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33770r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33770r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33770r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33770r=needscript Try newer version: http://bugs.php.net/fix.php?id=33770r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33770r=support Expected behavior: http://bugs.php.net/fix.php?id=33770r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33770r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33770r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33770r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33770r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33770r=dst IIS Stability: http://bugs.php.net/fix.php?id=33770r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33770r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33770r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33770r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33770r=mysqlcfg
#33770 [Fbk-Opn]: file() does not work with https on 64-bit Linux
ID: 33770 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 -PHP Version: 5.0.4 +PHP Version: 5.0.4 5.1.x-devel New Comment: Tried the latest snapshot as advised. Same effect as before, the problem persists. The configure line was given wrong. The actual is: ./configure \ --with-snmp \ --enable-cli \ --with-curl \ --disable-dom \ --prefix=/usr \ --disable-cgi \ --disable-spl \ --disable-xml \ --without-pear \ --disable-ipv6 \ --enable-shmop \ --enable-pcntl \ --without-iconv \ --disable-ctype \ --disable-libxml \ --enable-sysvsem \ --enable-sysvshm \ --enable-sockets \ --without-sqlite \ --disable-session \ --enable-sigchild \ --with-openssl=/usr \ --disable-simplexml \ --disable-tokenizer \ --with-curlwrappers \ --enable-memory-limit \ --enable-discard-path \ --program-suffix=-net \ --enable-ucd-snmp-hack \ --with-openssl-dir=/usr \ --with-config-file-path=/etc \ --with-mysqli=/usr/bin/mysql_config And here is the tcpdump output for the following script run on the machine host1: ? var_dump(file(https://host2/;)); ? Both host1 and host2 are on the same subnet. listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes 15:00:48.017717 IP host2.57868 host.https: S 1342601093:1342601093(0) win 5840 mss 1460,sackOK,timestamp 77012717 0,nop,wscale 2 0x: 4500 003c 6968 4000 4006 f142 ac11 43fa E..[EMAIL PROTECTED]@..B..C. 0x0010: ac11 43f4 e20c 01bb 5006 7785 ..C.P.w. 0x0020: a002 16d0 824c 0204 05b4 0402 080a .L.. 0x0030: 0497 1eed 0103 0302 15:00:48.017867 IP host.https host2.57868: S 3439729057:3439729057(0) ack 1342601094 win 5792 mss 1460,sackOK,timestamp 13469031 77012717,nop,wscale 0 0x: 4500 003c 12b7 4000 4006 47f4 ac11 43f4 E..[EMAIL PROTECTED]@.G...C. 0x0010: ac11 43fa 01bb e20c cd06 19a1 5006 7786 ..C.P.w. 0x0020: a012 16a0 1591 0204 05b4 0402 080a 0x0030: 00cd 8567 0497 1eed 0103 0300...g 15:00:48.017888 IP host2.57868 host.https: . ack 1 win 1460 nop,nop,timestamp 77012718 13469031 0x: 4500 0034 696a 4000 4006 f148 ac11 43fa [EMAIL PROTECTED]@..H..C. 0x0010: ac11 43f4 e20c 01bb 5006 7786 cd06 19a2 ..C.P.w. 0x0020: 8010 05b4 5541 0101 080a 0497 1eee UA.. 0x0030: 00cd 8567...g 15:00:48.023936 IP host2.57868 host.https: F 1:1(0) ack 1 win 1460 nop,nop,timestamp 77012724 13469031 0x: 4500 0034 696c 4000 4006 f146 ac11 43fa [EMAIL PROTECTED]@..F..C. 0x0010: ac11 43f4 e20c 01bb 5006 7786 cd06 19a2 ..C.P.w. 0x0020: 8011 05b4 553a 0101 080a 0497 1ef4 U:.. 0x0030: 00cd 8567...g 15:00:48.024125 IP host.https host2.57868: F 1:1(0) ack 2 win 5792 nop,nop,timestamp 13469032 77012724 0x: 4500 0034 12b1 4000 4006 4802 ac11 43f4 [EMAIL PROTECTED]@.H...C. 0x0010: ac11 43fa 01bb e20c cd06 19a2 5006 7787 ..C.P.w. 0x0020: 8011 16a0 444c 0101 080a 00cd 8568 DL.h 0x0030: 0497 1ef4 15:00:48.024141 IP host2.57868 host.https: . ack 2 win 1460 nop,nop,timestamp 77012724 13469032 0x: 4500 0034 696e 4000 4006 f144 ac11 43fa [EMAIL PROTECTED]@..D..C. 0x0010: ac11 43f4 e20c 01bb 5006 7787 cd06 19a3 ..C.P.w. 0x0020: 8010 05b4 5538 0101 080a 0497 1ef4 U8.. 0x0030: 00cd 8568...h Previous Comments: [2005-07-19 14:38:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-19 14:35:37] subscription at nazarenko dot net Description: I have 64bit SuSE 9.3 and try to use file() function to read a webpage via http/https. The http protocol is ok, however https returns empty result without any errors/notices (E_ALL is on). I have compiled in OpenSSL support (OpenSSL is v0.9.7e). I have another machine with 32bit Linux on it in the same network, I have compiled PHP with similar settings and https works fine on it. Reproduce code: --- Using the following configure: ./configure --with-snmp --enable-cli --with-curl \ -disable-dom --prefix=/usr --disable-cgi \ --disable-spl --disable-xml --without-pear \ --disable-ipv6 --enable-shmop --enable-pcntl \ --without-iconv --disable-ctype --disable-libxml \ --enable-sysvsem
#33770 [Fbk-Opn]: file() does not work with https when curl wrappers are compiled in
ID: 33770 User updated by: subscription at nazarenko dot net -Summary: file() does not work with https on 64-bit Linux Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 PHP Version: 5CVS-2005-07-19 New Comment: Thank you for a speedy response. Indeed, with the minimal configure, it started working again. After 1 hour of mixing and matching the modules I found the culprit. It is: curl-7.13.0 libraries compiled in with the following parameters: --with-curl --with-curlwrappers Actually, without --with-curlwrappers it works fine. Tested both for 5.0.4 and 5CVS Previous Comments: [2005-07-19 21:32:47] [EMAIL PROTECTED] Works fine for me under FC4 x86_64smp. Try with this configure line: ./configure --disable-all --disable-cgi --with-openssl And use sapi/cli/php to run your script. [2005-07-19 21:23:47] [EMAIL PROTECTED] subscription at nazarenko dot net: Tried the latest snapshot as advised. Same effect as before, the problem persists. Test script: ?php var_dump(file(https://host2/;)); ? Both host1 and host2 are on the same subnet. (do NOT add any huge outputs of anything unless asked for!) [2005-07-19 14:38:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-19 14:35:37] subscription at nazarenko dot net Description: I have 64bit SuSE 9.3 and try to use file() function to read a webpage via http/https. The http protocol is ok, however https returns empty result without any errors/notices (E_ALL is on). I have compiled in OpenSSL support (OpenSSL is v0.9.7e). I have another machine with 32bit Linux on it in the same network, I have compiled PHP with similar settings and https works fine on it. Reproduce code: --- Using the following configure: ./configure --with-snmp --enable-cli --with-curl \ -disable-dom --prefix=/usr --disable-cgi \ --disable-spl --disable-xml --without-pear \ --disable-ipv6 --enable-shmop --enable-pcntl \ --without-iconv --disable-ctype --disable-libxml \ --enable-sysvsem --enable-sysvshm --enable-sockets \ --without-sqlite --disable-session --enable-sigchild \ --disable-simplexml --disable-tokenizer \ --with-curlwrappers --enable-memory-limit \ --enable-discard-path --program-suffix=-net \ --enable-ucd-snmp-hack --with-config-file-path=/etc \ --with-mysqli=/usr/bin/mysql_config -- Edit this bug report at http://bugs.php.net/?id=33770edit=1
#33665 [NEW]: Cannot compile with SNMP support
From: subscription at nazarenko dot net
Operating system: Linux SuSE 8.2
PHP version: 5.0.4
PHP Bug Type: Compile Failure
Bug description: Cannot compile with SNMP support
Description:
Trying to ./configure --with-snmp --enable-cli --disable-cgi
-prefix=/usr
I have installed net-snmp 5.1.3 + devel rpm's.
Am I missing any libraries?
Actual result:
--
config.log has:
configure:76426: checking for SNMP support
configure:76472: checking OpenSSL dir for SNMP
configure:76500: checking for net-snmp-config
configure:77666: checking for snmp_parse_oid in -lnetsnmp
configure:77685: gcc -o conftest -g -O2 conftest.c -lnetsnmp -lresolv
-lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lnetsnmp
-lcrypto -lm 15
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `EVP_DigestFinal_ex'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `AES_set_encrypt_key'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `EVP_MD_CTX_cleanup'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `EVP_MD_CTX_init'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `DES_cbc_encrypt'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `DES_ncbc_encrypt'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `DES_key_sched'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `AES_cfb128_encrypt'
collect2: ld returned 1 exit status
configure: failed program was:
#line 77674 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char snmp_parse_oid();
int main() {
snmp_parse_oid()
; return 0; }
configure:77802: checking for init_snmp in -lnetsnmp
configure:77821: gcc -o conftest -g -O2 conftest.c -lnetsnmp -lresolv
-lm -ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lnetsnmp
-lcrypto -lm 15
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `EVP_DigestFinal_ex'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `AES_set_encrypt_key'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `EVP_MD_CTX_cleanup'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `EVP_MD_CTX_init'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to [EMAIL PROTECTED]'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `DES_cbc_encrypt'
/usr/lib/gcc-lib/i486-suse-linux/3.3/../../../libnetsnmp.so: undefined
reference to `DES_ncbc_encrypt'
/usr/lib/gcc-lib/i486
#32081 [NEW]: Setting mysqli.default_socket in php.ini has no effect
From: subscription at nazarenko dot net
Operating system: Linux SuSE 8.2
PHP version: 5.0.3
PHP Bug Type: MySQLi related
Bug description: Setting mysqli.default_socket in php.ini has no effect
Description:
I am running MySQL 4.1.10 and PHP 5.0.3.
By default, on SuSE MySQL uses /var/lib/mysql/mysql.sock.
I changed the location of the MySQL socket to /srv/mysql/mysql.sock in
/etc/my.cnf and MySQL is fine with it.
In my php.ini I have set mysqli.default_socket to the new socket
/srv/mysql/mysql.sock.
Reproduce code:
---
The code:
$mysqli = mysqli_init();
$mysqli-real_connect('localhost', SQL_LOGIN, SQL_PASSWD);
produces the following warning:
mysqli::real_connect(): Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2) in /srv/www/htdocs/index.php on line 10
Expected result:
Since the socket value was omitted, it is expected that PHP uses the
default sockeet value from the php.ini file.
The error shows that the default socket value for MySQLi is ignored by
PHP.
Actual result:
--
When I first run phpinfo() I got the following output:
Client API version 4.1.10
MYSQLI_SOCKET/var/lib/mysql/mysql.sock
mysqli.default_socket/srv/mysql/mysql.sock
This made 3 things clear:
1) mysqli.default_socket variable *IS* correctly read from php.ini
2) mysqli.default_socket variable is *IGNORED* by the PHP interpreter
3) there is some variable called MYSQLI_SOCKET which is still set to the
old-default socket
I searched in the header files of MySQL and found a file called
/usr/include/mysql/mysql_version.h, which contained a line:
#define MYSQL_UNIX_ADDR /var/lib/mysql/mysql.sock
I changed it to /srv/mysql/mysql.sock and recompiled PHP again.
This time phpinfo() gave the following output:
Client API version 4.1.10
MYSQLI_SOCKET/srv/mysql/mysql.sock
mysqli.default_socket/srv/mysql/mysql.sock
However, the problem was not gone!
mysqli_real_connect() was still trying to use the hard-coded (?) value
from MySQL server /var/lib/mysql/mysql.sock.
Adding --with-mysql-sock=/srv/mysql/mysql.sock to the configure options
list did not help either. I guess this is by design as --with-mysql-sock
is not a MySQLi related option anyway.
--
Edit bug report at http://bugs.php.net/?id=32081edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32081r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32081r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32081r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32081r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32081r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32081r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32081r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32081r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32081r=support
Expected behavior: http://bugs.php.net/fix.php?id=32081r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32081r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32081r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32081r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32081r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32081r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32081r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32081r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32081r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32081r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32081r=mysqlcfg
#30412 [Fbk-Opn]: Apache Segmentation Fault (11)
ID: 30412 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: SuSE Linux 8.2 PHP Version: 5.0.4-Dev New Comment: Excuse me please, is the last message automatic? Has there been any work done related to this bug (i.e. threaded apache + php5 + oracle) in the latest snapshot? I cannot easily recompile PHP at the moment and will do so only if it is justified. Previous Comments: [2005-03-07 22:04:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-02-16 04:44:34] subscription at nazarenko dot net TNS_ADMIN is not used, since I do not utilize tnsnames.ora file. As you can see from the code example I use the connection description string directly in the script: ?php $db_conn = ocilogon( user, password, (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myoracle)(PORT= 1521)))(CONNECT_DATA=(SERVICE_NAME=CRPT; ? ORACLE_HOME is definitely set, otherwise there will be no successful queries at all. [2005-02-10 21:34:05] [EMAIL PROTECTED] Please check that you have set all environments variables (i.e. ORACLE_HOME, TNS_ADMIN etc) properly. [2005-02-10 21:17:23] subscription at nazarenko dot net Hello it is me again, Tested both 5.0.3 release and the latest snapshot php5-STABLE-200502101130 with both Apache 2.0.52 Prefork and Worker MPMs. 5.0.3 and the snapshot behave identically. Under Prefork MPM everything is 100% ok. Under Worker the same problem as before: some page loads are unsuccessful with no segfault. The browser just keeps waiting and waiting and nothing happens. This happens on average for 30% of page requests containing Oracle queries. Don't know if you want to pursue this further as the Prefork works fine now. Many thanks for your time and effort!! [2005-01-13 01:27:24] [EMAIL PROTECTED] Please, try latest snapshot with non-threaded Apache. Are you still able to replicate the problem ? 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/30412 -- Edit this bug report at http://bugs.php.net/?id=30412edit=1
#30412 [Fbk-Opn]: Apache Segmentation Fault (11)
ID: 30412 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: SuSE Linux 8.2 PHP Version: 5.0.4-Dev New Comment: TNS_ADMIN is not used, since I do not utilize tnsnames.ora file. As you can see from the code example I use the connection description string directly in the script: ?php $db_conn = ocilogon( user, password, (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myoracle)(PORT= 1521)))(CONNECT_DATA=(SERVICE_NAME=CRPT; ? ORACLE_HOME is definitely set, otherwise there will be no successful queries at all. Previous Comments: [2005-02-10 21:34:05] [EMAIL PROTECTED] Please check that you have set all environments variables (i.e. ORACLE_HOME, TNS_ADMIN etc) properly. [2005-02-10 21:17:23] subscription at nazarenko dot net Hello it is me again, Tested both 5.0.3 release and the latest snapshot php5-STABLE-200502101130 with both Apache 2.0.52 Prefork and Worker MPMs. 5.0.3 and the snapshot behave identically. Under Prefork MPM everything is 100% ok. Under Worker the same problem as before: some page loads are unsuccessful with no segfault. The browser just keeps waiting and waiting and nothing happens. This happens on average for 30% of page requests containing Oracle queries. Don't know if you want to pursue this further as the Prefork works fine now. Many thanks for your time and effort!! [2005-01-21 01:00:08] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-01-13 01:27:24] [EMAIL PROTECTED] Please, try latest snapshot with non-threaded Apache. Are you still able to replicate the problem ? [2004-12-03 11:52:49] rathamahata at ehouse dot ru Sorry, please ignore previous post. That was apache with MPM=prefork + php compiled against apache with mpm=worker. I don't know how did it work. After i recompiled php against current apache problem had disappeared. 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/30412 -- Edit this bug report at http://bugs.php.net/?id=30412edit=1
#30412 [NoF-Opn]: Apache Segmentation Fault (11)
ID: 30412 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: No Feedback +Status: Open Bug Type: OCI8 related Operating System: SuSE Linux 8.2 -PHP Version: 5.0.3RC1 +PHP Version: 5.0.4-Dev New Comment: Hello it is me again, Tested both 5.0.3 release and the latest snapshot php5-STABLE-200502101130 with both Apache 2.0.52 Prefork and Worker MPMs. 5.0.3 and the snapshot behave identically. Under Prefork MPM everything is 100% ok. Under Worker the same problem as before: some page loads are unsuccessful with no segfault. The browser just keeps waiting and waiting and nothing happens. This happens on average for 30% of page requests containing Oracle queries. Don't know if you want to pursue this further as the Prefork works fine now. Many thanks for your time and effort!! Previous Comments: [2005-01-21 01:00:08] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-01-13 01:27:24] [EMAIL PROTECTED] Please, try latest snapshot with non-threaded Apache. Are you still able to replicate the problem ? [2004-12-03 11:52:49] rathamahata at ehouse dot ru Sorry, please ignore previous post. That was apache with MPM=prefork + php compiled against apache with mpm=worker. I don't know how did it work. After i recompiled php against current apache problem had disappeared. [2004-12-03 11:31:54] rathamahata at ehouse dot ru It looks like this happens (the browser would just wait with nothing happening) even with prefork mpm. strace shows Process 27641 attached - interrupt to quit futex(0x83967f0, FUTEX_WAIT, 2, NULL which is strange becouse apache is compiled with mpm=prefork `apache2 -l' Compiled in modules: core.c mod_access.c mod_auth.c mod_include.c mod_deflate.c mod_log_config.c mod_expires.c mod_setenvif.c prefork.c http_core.c mod_mime.c mod_status.c mod_autoindex.c mod_info.c mod_cgi.c mod_dir.c mod_alias.c mod_rewrite.c mod_so.c [2004-12-02 15:17:32] subscription at nazarenko dot net Let me confirm it again after some more testing today that I still do get segfaults, but not that often than before. Also, let me point out that it seems to be exclusively Apache/PHP problem. The same script is run from the shell environment with no problems at all. Now to the example that you have asked for. It is really simple. In fact *any* Oracle query will cause occasional browser hanging. Here is a bit of code I used today for testing: ?php $db_conn = ocilogon( user, password, (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myoracle)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CRPT or die(Critical Error: No connection to Oracle!); $cmdstr = SELECT DISTINCT TRIM(XM.X_MEMBER_ID) MEMBER_ID, S.X_MEMBER_IDDBS_ID FROM TABLE_SITE_PART SP, TABLE_SITE_PART SP2, TABLE_X_MEMBERDATA XM, TABLE_SITES WHERE SP2.X_CLASS_KEY = 9 AND SP2.LEVEL_TO_BIN IN (0,1,2,3,4,5) AND SP2.SITE_PART2SITE_PART = SP.OBJID AND SP2.X_SITE_PART2MEMBERDATA = XM.OBJID AND SP.ALL_SITE_PART2SITE = S.OBJID AND XM.X_STATUS = 'Active' AND S.STATUS = '0' ORDER BY TRIM(XM.X_MEMBER_ID) ; $parsed = ociparse($db_conn, $cmdstr); ociexecute($parsed); $boxrows = ocifetchstatement($parsed, $listbox); OCIFreeStatement($parsed); print_r($listbox); ? Most of the times this would work fine returning me an array of data. But sometimes the browser would just wait with nothing happening. And very rarely the page would fail immediately (producing a segfault in apache's error log) Hope this helps. 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/30412 -- Edit this bug report at http://bugs.php.net/?id=30412edit=1
#30412 [Fbk-Opn]: Apache Segmentation Fault (11)
ID: 30412 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: SuSE Linux 8.2 -PHP Version: 5.0.2 +PHP Version: 5.0.3RC1 New Comment: Let me confirm it again after some more testing today that I still do get segfaults, but not that often than before. Also, let me point out that it seems to be exclusively Apache/PHP problem. The same script is run from the shell environment with no problems at all. Now to the example that you have asked for. It is really simple. In fact *any* Oracle query will cause occasional browser hanging. Here is a bit of code I used today for testing: ?php $db_conn = ocilogon( user, password, (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myoracle)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CRPT or die(Critical Error: No connection to Oracle!); $cmdstr = SELECT DISTINCT TRIM(XM.X_MEMBER_ID) MEMBER_ID, S.X_MEMBER_IDDBS_ID FROM TABLE_SITE_PART SP, TABLE_SITE_PART SP2, TABLE_X_MEMBERDATA XM, TABLE_SITES WHERE SP2.X_CLASS_KEY = 9 AND SP2.LEVEL_TO_BIN IN (0,1,2,3,4,5) AND SP2.SITE_PART2SITE_PART = SP.OBJID AND SP2.X_SITE_PART2MEMBERDATA = XM.OBJID AND SP.ALL_SITE_PART2SITE = S.OBJID AND XM.X_STATUS = 'Active' AND S.STATUS = '0' ORDER BY TRIM(XM.X_MEMBER_ID) ; $parsed = ociparse($db_conn, $cmdstr); ociexecute($parsed); $boxrows = ocifetchstatement($parsed, $listbox); OCIFreeStatement($parsed); print_r($listbox); ? Most of the times this would work fine returning me an array of data. But sometimes the browser would just wait with nothing happening. And very rarely the page would fail immediately (producing a segfault in apache's error log) Hope this helps. Previous Comments: [2004-12-02 01:20:38] [EMAIL PROTECTED] [Thu Dec 02 00:57:47 2004] [warn] child process 18167 still did not exit, sending a SIGTERM I don't think PHP/OCI8 is causing this. I saw this problem many times without OCI8 enabled or even without any module enabled at all. Some page loads are unsuccessful, but there is no segfault! The browser just keeps waiting and waiting and nothing I would be very thankful if you provide tiny reproduce script, that I can use to reproduce your problem. happens. [2004-12-02 01:05:47] subscription at nazarenko dot net Marking it as open... [2004-12-02 01:02:06] subscription at nazarenko dot net Hello again, Today I tried PHP 5.0.3RC1 with Apache 2.0.52 Worker and Oracle 9.2.0.4 Client for Linux. I'd say there has been improvement made! But not perfect. In fact the Bug #28603 which was reported by me some time ago and later marked as Bogus has been fixed with this new release!! What I mean is that Apache does not crash on graceful restart anymore. Even the Apache-Worker behaves fine. I am getting debug messages in the error log file, but I guess that will be removed in the release version: [Thu Dec 02 00:42:28 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations [Thu Dec 02 00:43:28 2004] [notice] SIGUSR1 received. Doing graceful restart OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / [Thu Dec 02 00:43:29 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / It is somewhat strange that I get some OCIDebug START and END messages *after* the Apache has started, as shown above. If I do full restart via /etc/init.d/apache2 restart, then sometimes I get the following: OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / [Thu Dec 02 00:57:47 2004] [warn] child process 18167 still did not exit, sending a SIGTERM [Thu Dec 02 00:57:47 2004] [warn] child process 18259 still did not exit, sending a SIGTERM [Thu Dec 02 00:57:51 2004] [error] child process 18167 still did not exit, sending a SIGKILL [Thu Dec 02 00
#30412 [Com]: Apache Segmentation Fault (11)
ID: 30412 Comment by: subscription at nazarenko dot net Reported By: mail-list at nazarenko dot net Status: No Feedback Bug Type: OCI8 related Operating System: SuSE Linux 8.2 PHP Version: 5.0.2 New Comment: Hello again, Today I tried PHP 5.0.3RC1 with Apache 2.0.52 Worker and Oracle 9.2.0.4 Client for Linux. I'd say there has been improvement made! But not perfect. In fact the Bug #28603 which was reported by me some time ago and later marked as Bogus has been fixed with this new release!! What I mean is that Apache does not crash on graceful restart anymore. Even the Apache-Worker behaves fine. I am getting debug messages in the error log file, but I guess that will be removed in the release version: [Thu Dec 02 00:42:28 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations [Thu Dec 02 00:43:28 2004] [notice] SIGUSR1 received. Doing graceful restart OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / [Thu Dec 02 00:43:29 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / It is somewhat strange that I get some OCIDebug START and END messages *after* the Apache has started, as shown above. If I do full restart via /etc/init.d/apache2 restart, then sometimes I get the following: OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / [Thu Dec 02 00:57:47 2004] [warn] child process 18167 still did not exit, sending a SIGTERM [Thu Dec 02 00:57:47 2004] [warn] child process 18259 still did not exit, sending a SIGTERM [Thu Dec 02 00:57:51 2004] [error] child process 18167 still did not exit, sending a SIGKILL [Thu Dec 02 00:57:51 2004] [error] child process 18259 still did not exit, sending a SIGKILL [Thu Dec 02 00:58:08 2004] [notice] SIGHUP received. Attempting to restart [Thu Dec 02 00:58:08 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations ...which i guess is ok, since Apache restarts successfully after all. Now to the not so good news: Apache gives significantly less segfaults than before when performing Oracle queries but they still do happen occasionally. Actually, I get *really* very few segfaults now, but there is a new behaviour not seen before. Some page loads are unsuccessful, but there is no segfault! The browser just keeps waiting and waiting and nothing happens. No segfault, no data coming in from Apache. This happens on average for 30% of page requests containing Oracle queries. Well, I hope that since we have seen some imporvement now it could be made working 100% sometime in the future. Thanks so much for addressing this issue! Regards, Andrei Previous Comments: [2004-11-01 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2004-10-23 11:39:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2004-10-13 19:12:05] mail-list at nazarenko dot net Sorry, I meant the bug #30410. [2004-10-13 19:11:13] mail-list at nazarenko dot net Please have a look at the bug #30412. The person who reported it has exactly the same problem. He confirms my experience -- the segfaults do not happen with 4.3.9 but are present with 5.0.2 [2004-10-12 20:31:29] mail-list at nazarenko dot net How can it be explained that I do not get those segfaults with the same configuration and PHP 4.3.x, but get them with PHP 5.0.x ? 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/30412 -- Edit this bug report at http://bugs.php.net/?id=30412edit=1
#30412 [NoF-Opn]: Apache Segmentation Fault (11)
ID: 30412 User updated by: subscription at nazarenko dot net -Reported By: mail-list at nazarenko dot net +Reported By: subscription at nazarenko dot net -Status: No Feedback +Status: Open Bug Type: OCI8 related Operating System: SuSE Linux 8.2 PHP Version: 5.0.2 New Comment: Marking it as open... Previous Comments: [2004-12-02 01:02:06] subscription at nazarenko dot net Hello again, Today I tried PHP 5.0.3RC1 with Apache 2.0.52 Worker and Oracle 9.2.0.4 Client for Linux. I'd say there has been improvement made! But not perfect. In fact the Bug #28603 which was reported by me some time ago and later marked as Bogus has been fixed with this new release!! What I mean is that Apache does not crash on graceful restart anymore. Even the Apache-Worker behaves fine. I am getting debug messages in the error log file, but I guess that will be removed in the release version: [Thu Dec 02 00:42:28 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations [Thu Dec 02 00:43:28 2004] [notice] SIGUSR1 received. Doing graceful restart OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / [Thu Dec 02 00:43:29 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / It is somewhat strange that I get some OCIDebug START and END messages *after* the Apache has started, as shown above. If I do full restart via /etc/init.d/apache2 restart, then sometimes I get the following: OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / OCIDebug: START php_mshutdown_ocibr / OCIDebug: END php_mshutdown_ocibr / [Thu Dec 02 00:57:47 2004] [warn] child process 18167 still did not exit, sending a SIGTERM [Thu Dec 02 00:57:47 2004] [warn] child process 18259 still did not exit, sending a SIGTERM [Thu Dec 02 00:57:51 2004] [error] child process 18167 still did not exit, sending a SIGKILL [Thu Dec 02 00:57:51 2004] [error] child process 18259 still did not exit, sending a SIGKILL [Thu Dec 02 00:58:08 2004] [notice] SIGHUP received. Attempting to restart [Thu Dec 02 00:58:08 2004] [notice] Apache/2.0.52 (Linux/SUSE) configured -- resuming normal operations ...which i guess is ok, since Apache restarts successfully after all. Now to the not so good news: Apache gives significantly less segfaults than before when performing Oracle queries but they still do happen occasionally. Actually, I get *really* very few segfaults now, but there is a new behaviour not seen before. Some page loads are unsuccessful, but there is no segfault! The browser just keeps waiting and waiting and nothing happens. No segfault, no data coming in from Apache. This happens on average for 30% of page requests containing Oracle queries. Well, I hope that since we have seen some imporvement now it could be made working 100% sometime in the future. Thanks so much for addressing this issue! Regards, Andrei [2004-11-01 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2004-10-23 11:39:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2004-10-13 19:12:05] mail-list at nazarenko dot net Sorry, I meant the bug #30410. [2004-10-13 19:11:13] mail-list at nazarenko dot net Please have a look at the bug #30412. The person who reported it has exactly the same problem. He confirms my experience -- the segfaults do not happen with 4.3.9 but are present with 5.0.2 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/30412 -- Edit this bug report at http://bugs.php.net/?id=30412edit=1
