#48695 [Asn->Fbk]: PHP_SELF / SCRIPT_NAME issues not bogus - bugfix in 5.2.9 still causing trouble
ID: 48695 Updated by: srina...@php.net Reported By: allerlei+bugs dot php dot net at sihw dot nl -Status: Assigned +Status: Feedback Bug Type: CGI related Operating System: Centos 4/5 PHP Version: 5.2.10 Assigned To: srinatar New Comment: hi as i mentioned in my comment, some help on how to reproduce this issue would be much appreciated. Previous Comments: [2009-07-11 10:20:50] sriram dot natarajan at gmail dot com i have even configured with SuEXEC and still unable to reproduce this issue. i must be missing some thing obvious. haven't figured out what it is though.. if any one has any better suggestions on what should be my apache config, i will appreciate. [2009-07-07 00:09:00] sriram dot natarajan at gmail dot com ok, i compiled cgiwrap 4.1 with the following settings. ./configure '--with-php=/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210' '--with-httpd-user=sriramn' '--with-php-cgiwrap' '--with-install-dir=/export/home/sriramn/sun/httpd22/cgi-bin' '--with-install-group=staff' --with-cgiwrapd --with-php-interpreter Initializing Logging Redirecting STDERR to STDOUT Setting SIGXCPU to default behaviour Environment Variables: QUERY_STRING: '' SCRIPT_NAME: '/cgi-bin/php-cgiwrapd' SCRIPT_FILENAME: '/export/home/sriramn/sun/httpd22/cgi-bin/php-cgiwrapd' REDIRECT_URL: '/php-cgi/cgi-info.php' PATH_INFO: '/sriramn/php-cgi/cgi-info.php' PATH_TRANSLATED: '/export/home/sriramn/sun/httpd22/htdocs/sriramn/php-cgi/cgi-info.php' REMOTE_USER: '' REMOTE_HOST: '' REMOTE_ADDR: '127.0.0.1' Trying to extract user from PATH_INFO. Retrieved User Name: 'sriramn' User Data Retrieved: UserID: 'sriramn' UID: '101' GID: '10' Home Dir: '/export/home/sriramn' Checking user minimum uid. Script Base Directory: '/export/home/sriramn/public_html/cgi-bin' Fetching script string Trying to extract script from PATH_INFO Extracted PATH_INFO '/php-cgi/cgi-info.php' Building script path Condensing slashes. Script Relative Path: 'php-cgi/cgi-info.php' Script Absolute Path: '/export/home/sriramn/public_html/cgi-bin/php-cgi/cgi-info.php' Checking for special interpreted script (php). Interpreter Path: '/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210' Fixing Environment Variables. Environment Variables: QUERY_STRING: '' SCRIPT_NAME: '/cgi-bin/php-cgiwrapd/sriramn/php-cgi/cgi-info.php' SCRIPT_FILENAME: '/export/home/sriramn/public_html/cgi-bin/php-cgi/cgi-info.php' REDIRECT_URL: '/php-cgi/cgi-info.php' PATH_INFO: '' PATH_TRANSLATED: '/export/home/sriramn/sun/httpd22/htdocs/sriramn/php-cgi/cgi-info.php' REMOTE_USER: '' REMOTE_HOST: '' REMOTE_ADDR: '127.0.0.1' UIDs/GIDs Changed To: RUID: '101' EUID: '101' RGID: '10' EGID: '10' Changing current directory to '/export/home/sriramn/public_html/cgi-bin/php-cgi' Executing: '/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210' Arguments: 0: '/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210' 1: 'cgi-info.php' Output of script follows: = X-Powered-By: PHP/5.2.10 Content-type: text/html server software Apache/2.2.11 (Unix) script name /php-cgi/cgi-info.php script filename /export/home/sriramn/sun/httpd22/htdocs/sriramn/php-cgi/cgi-info.php path info path translated redirect uri redirect url/php-cgi/cgi-info.php self uri is /php-cgi/cgi-info.php and php 5.2.10 seem to be returning the right output. what configuration am i missing ? fyi, here is how my apache conf looks .. AddHandler cgi-wrapper .php AddHandler cgi-wrapper .cgi Action cgi-wrapper /cgi-bin/php-cgiwrapd/sriramn what am I missing here ? i will also hook up SuEXEC and see if I can reproduce that way.. [2009-07-02 14:19:51] allerlei+bugs dot php dot net at sihw dot nl Probably not easy to reproduce without a wrapper like cgiwrap. I did not get suexec to work, but if you have an install with suexec handling php-cgi succesfully, that might work. Here are the $_SERVER values on my test system with apache. This uses /spinwebstartscript/startscript/php/USERNAME as a handler for php files. So the file test.php will be called through the hand
#48695 [Fbk]: PHP_SELF / SCRIPT_NAME issues not bogus - bugfix in 5.2.9 still causing trouble
ID: 48695 Updated by: srina...@php.net Reported By: allerlei+bugs dot php dot net at sihw dot nl Status: Feedback Bug Type: CGI related Operating System: Centos 4/5 PHP Version: 5.2.10 Assigned To: srinatar New Comment: can you kindly provide the output of PATH_TRANSLATED SCRIPT_FILENAME from a simple cgi script (not php). i would like to see the env variable before it is passed to php. to get this info, if you could kindly write a 2 line cgi script that prints this value that should suffice. I am afraid that if i don't hear any response too soon, i need to close this bug as bogus. i have tried my best reproduce it (with suEXEC as well as with cgi-wrapper) and have also checked with apache 1.3.41 as well as with apache 2.x and still unable to reproduce it. either i am missing some thing or you had some issues with your 'startscript' cgi wrapper that you resolved it on your own. Previous Comments: [2009-07-14 09:43:20] srina...@php.net hi as i mentioned in my comment, some help on how to reproduce this issue would be much appreciated. [2009-07-11 10:20:50] sriram dot natarajan at gmail dot com i have even configured with SuEXEC and still unable to reproduce this issue. i must be missing some thing obvious. haven't figured out what it is though.. if any one has any better suggestions on what should be my apache config, i will appreciate. [2009-07-07 00:09:00] sriram dot natarajan at gmail dot com ok, i compiled cgiwrap 4.1 with the following settings. ./configure '--with-php=/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210' '--with-httpd-user=sriramn' '--with-php-cgiwrap' '--with-install-dir=/export/home/sriramn/sun/httpd22/cgi-bin' '--with-install-group=staff' --with-cgiwrapd --with-php-interpreter Initializing Logging Redirecting STDERR to STDOUT Setting SIGXCPU to default behaviour Environment Variables: QUERY_STRING: '' SCRIPT_NAME: '/cgi-bin/php-cgiwrapd' SCRIPT_FILENAME: '/export/home/sriramn/sun/httpd22/cgi-bin/php-cgiwrapd' REDIRECT_URL: '/php-cgi/cgi-info.php' PATH_INFO: '/sriramn/php-cgi/cgi-info.php' PATH_TRANSLATED: '/export/home/sriramn/sun/httpd22/htdocs/sriramn/php-cgi/cgi-info.php' REMOTE_USER: '' REMOTE_HOST: '' REMOTE_ADDR: '127.0.0.1' Trying to extract user from PATH_INFO. Retrieved User Name: 'sriramn' User Data Retrieved: UserID: 'sriramn' UID: '101' GID: '10' Home Dir: '/export/home/sriramn' Checking user minimum uid. Script Base Directory: '/export/home/sriramn/public_html/cgi-bin' Fetching script string Trying to extract script from PATH_INFO Extracted PATH_INFO '/php-cgi/cgi-info.php' Building script path Condensing slashes. Script Relative Path: 'php-cgi/cgi-info.php' Script Absolute Path: '/export/home/sriramn/public_html/cgi-bin/php-cgi/cgi-info.php' Checking for special interpreted script (php). Interpreter Path: '/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210' Fixing Environment Variables. Environment Variables: QUERY_STRING: '' SCRIPT_NAME: '/cgi-bin/php-cgiwrapd/sriramn/php-cgi/cgi-info.php' SCRIPT_FILENAME: '/export/home/sriramn/public_html/cgi-bin/php-cgi/cgi-info.php' REDIRECT_URL: '/php-cgi/cgi-info.php' PATH_INFO: '' PATH_TRANSLATED: '/export/home/sriramn/sun/httpd22/htdocs/sriramn/php-cgi/cgi-info.php' REMOTE_USER: '' REMOTE_HOST: '' REMOTE_ADDR: '127.0.0.1' UIDs/GIDs Changed To: RUID: '101' EUID: '101' RGID: '10' EGID: '10' Changing current directory to '/export/home/sriramn/public_html/cgi-bin/php-cgi' Executing: '/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210' Arguments: 0: '/export/home/sriramn/sun/httpd22/cgi-bin/php-cgi.5210' 1: 'cgi-info.php' Output of script follows: = X-Powered-By: PHP/5.2.10 Content-type: text/html server software Apache/2.2.11 (Unix) script name /php-cgi/cgi-info.php script filename /export/home/sriramn/sun/httpd22/htdocs/sriramn/php-cgi/cgi-info.php path info path translated redirect uri redirect url/php-cgi/cgi-info.php self uri is /php-cgi/cgi-info.php and php 5.2.10 seem to be returning the right output. what c
#48774 [Opn]: SIGSEGVs when using curl_copy_handle()
ID: 48774
Updated by: srina...@php.net
Reported By: fel...@php.net
Status: Open
Bug Type: cURL related
Operating System: Linux
PHP Version: 5.3CVS-2009-07-02 (CVS)
-Assigned To:
+Assigned To: srinatar
New Comment:
while looking into this bug, i also realized that this below test case
is also broken
less curl_copy_handle_basic_002.phpt
...
curl_setopt($ch, CURLOPT_POSTFIELDS,
"Hello=World&Foo=Bar&Person=John%20Doe");
curl_setopt($ch, CURLOPT_URL, $url); //set the url we want to use
$copy = curl_copy_handle($ch);
curl_close($ch);
...
(currently, marked as expected failure..) so, i have filed a separate
bug : 48965 to track this separately
Previous Comments:
[2009-07-14 09:40:45] sriram dot natarajan at gmail dot com
Hi
though the above patch does fix the crash reported by the developer,
on further investigation this patch is not the right fix.
the issue that is happening is when the form input data is a array, the
constructed form data is not available when executing curl_exec on the
cloned handle.
[2009-07-11 10:54:13] sriram dot natarajan at gmail dot com
here is a better way to read the patches..
http://pastebin.org/1041
[2009-07-11 10:12:27] sriram dot natarajan at gmail dot com
i was able to reproduce this on rhel 5 which ships with curl 7.15.5.
and this below patch seems to fix this problem
--- ext/curl/interface.c.ORIG 2009-07-09 15:24:00.0 -0700
+++ ext/curl/interface.c2009-07-11 03:08:56.0 -0700
@@ -1444,9 +1444,13 @@
zend_llist_copy(&dupch->to_free.str, &ch->to_free.str);
/* Don't try to free copied strings, they're free'd when the
original handle is destroyed */
dupch->to_free.str.dtor = NULL;
-#endif
+
zend_llist_copy(&dupch->to_free.slist, &ch->to_free.slist);
+ dupch->to_free.slist.dtor = NULL;
+
zend_llist_copy(&dupch->to_free.post, &ch->to_free.post);
+ dupch->to_free.post.dtor = NULL;
+#endif
ZEND_REGISTER_RESOURCE(return_value, dupch, le_curl);
dupch->id = Z_LVAL_P(return_value);
need to investigate and possibly add couple of test cases
[2009-07-09 16:31:59] daniel at haxx dot se
I think it would help the devs if you'd also specify what libcurl
version you use (preferably with curl -V or similar to give all the
details).
[2009-07-02 13:20:33] fel...@php.net
Description:
See below.
Reproduce code:
---
1º
http://localhost/";;
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, array("Hello" => "World"));
curl_setopt($ch, CURLOPT_URL, $url);
$copy = curl_copy_handle($ch);
curl_close($ch);
2º
http://localhost/";;
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, array("Hello" => "World"));
curl_setopt($ch, CURLOPT_URL, $url);
$copy = curl_copy_handle($ch);
curl_close($ch);
curl_exec($copy);
curl_close($copy);
Expected result:
No SIGSEGV.
Actual result:
--
1º
*** glibc detected *** sapi/cli/php: double free or corruption
(fasttop): 0x0a663260 ***
=== Backtrace: =
/lib/i686/cmov/libc.so.6[0xb65a81d4]
/lib/i686/cmov/libc.so.6(cfree+0x96)[0xb65aa186]
/usr/local/lib/libcurl.so.4(curl_formfree+0x8a)[0xb74533ca]
sapi/cli/php[0x819c1af]
sapi/cli/php(zend_llist_destroy+0x33)[0x8612f05]
sapi/cli/php(zend_llist_clean+0x11)[0x8612f71]
sapi/cli/php[0x81a0a40]
sapi/cli/php[0x81a0d81]
sapi/cli/php[0x86321e4]
sapi/cli/php(zend_hash_del_key_or_index+0x192)[0x862f5d9]
sapi/cli/php(_zend_list_delete+0xa0)[0x8631df4]
sapi/cli/php(_zval_dtor_func+0x198)[0x861cb28]
sapi/cli/php[0x860cfcc]
sapi/cli/php(_zval_ptr_dtor+0xb8)[0x860d3b1]
sapi/cli/php(_zval_ptr_dtor_wrapper+0x21)[0x861cf08]
sapi/cli/php[0x862fa96]
sapi/cli/php(zend_hash_graceful_reverse_destroy+0x3e)[0x862fc1a]
sapi/cli/php[0x860c5bb]
sapi/cli/php[0x861f79a]
sapi/cli/php(php_request_shutdown+0x682)[0x8590ac0]
sapi/cli/php[0x87035c7]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb654f775]
sapi/cli/php[0x8078a91]
2º
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb631a6f0 (LWP 4050)]
0xb74ef368 in curl_formfree () from /usr/local/lib/libcurl.so.4
Current language: auto; currently asm
(gdb) bt
#0 0xb74ef368 in curl_formfree () from /usr/local/lib/libcurl.so.4
#1 0xb74ef37c in curl_
#48965 [Asn]: curl is not able to post a string properly from a cloned handle
ID: 48965
Updated by: srina...@php.net
Reported By: sriram dot natarajan at gmail dot com
Status: Assigned
Bug Type: cURL related
Operating System: linux
PHP Version: 5.3.0
Assigned To: srinatar
New Comment:
yes, this is an issue with HEAD, 5.2 and 5.3
- sriram
Previous Comments:
[2009-07-20 14:55:36] j...@php.net
See also bug #48774
[2009-07-20 09:42:17] j...@php.net
only PHP_5_3 and HEAD? Not PHP_5_2..?
[2009-07-18 07:10:07] sriram dot natarajan at gmail dot com
Description:
currently, within php tests, the following tests are marked as
'expected failures'
curl_copy_handle_basic_002.phpt
curl_copy_handle_basic_005.phpt
which both does some thing like
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,
"Hello=World&Foo=Bar&Person=John%20Doe");
$copy = curl_copy_handle($ch);
curl_close($ch);
$curl_content_copy = curl_exec($copy);
curl_close($copy);
var_dump( $curl_content_copy );
Expected result:
these tests should pass fine.
Actual result:
--
string(163) "array(1) {
["test"]=>
string(7) "getpost"
}
--
Edit this bug report at http://bugs.php.net/?id=48965&edit=1
#48774 [Asn->Opn]: SIGSEGVs when using curl_copy_handle()
ID: 48774 Updated by: srina...@php.net Reported By: fel...@php.net -Status: Assigned +Status: Open Bug Type: cURL related Operating System: Linux PHP Version: 5.3CVS-2009-07-02 (CVS) Assigned To: srinatar New Comment: This bug has been fixed in SVN. 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. Previous Comments: [2009-07-21 22:57:09] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=284567 Log: - Fix badly applied patch (bug #48774) [2009-07-21 20:32:33] s...@php.net Automatic comment from SVN on behalf of srinatar Revision: http://svn.php.net/viewvc/?view=revision&revision=284557 Log: - Fixed bug #48774 (SIGSEGVs when using curl_copy_handle()). [2009-07-20 14:54:55] j...@php.net See also bug #48965 [2009-07-18 07:10:50] srina...@php.net while looking into this bug, i also realized that this below test case is also broken less curl_copy_handle_basic_002.phpt ... curl_setopt($ch, CURLOPT_POSTFIELDS, "Hello=World&Foo=Bar&Person=John%20Doe"); curl_setopt($ch, CURLOPT_URL, $url); //set the url we want to use $copy = curl_copy_handle($ch); curl_close($ch); ... (currently, marked as expected failure..) so, i have filed a separate bug : 48965 to track this separately [2009-07-14 09:40:45] sriram dot natarajan at gmail dot com Hi though the above patch does fix the crash reported by the developer, on further investigation this patch is not the right fix. the issue that is happening is when the form input data is a array, the constructed form data is not available when executing curl_exec on the cloned handle. 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/48774 -- Edit this bug report at http://bugs.php.net/?id=48774&edit=1
#48965 [Bgs]: curl is not able to post a string properly from a cloned handle
ID: 48965 Updated by: srina...@php.net Reported By: sriram dot natarajan at gmail dot com Status: Bogus Bug Type: cURL related Operating System: * PHP Version: 5.*, 6CVS (2009-07-22) Assigned To: srinatar New Comment: should these below test cases be removed as it is doing some thing which is not supported or standard behavior ? curl_copy_handle_basic_002.phpt curl_copy_handle_basic_005.phpt just curious as to what is the practice in this case ? Previous Comments: [2009-07-28 12:19:47] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is a cURL limitation.. [2009-07-25 22:15:16] j...@php.net The reason is explained here: http://curl.haxx.se/libcurl/c/curl_easy_duphandle.html You can not close the original handle before doing curl_exec($copy).. [2009-07-21 20:45:19] srina...@php.net yes, this is an issue with HEAD, 5.2 and 5.3 - sriram [2009-07-20 14:55:36] j...@php.net See also bug #48774 [2009-07-20 09:42:17] j...@php.net only PHP_5_3 and HEAD? Not PHP_5_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/48965 -- Edit this bug report at http://bugs.php.net/?id=48965&edit=1
#48182 [Asn->Csd]: ssl handshake fails during asynchronous socket connection
ID: 48182
Updated by: srina...@php.net
Reported By: frase at cs dot wisc dot edu
-Status: Assigned
+Status: Closed
Bug Type: OpenSSL related
Operating System: *
PHP Version: 5.2.10, 5.3.0
-Assigned To: pajoye
+Assigned To: srinatar
New Comment:
This bug has been fixed in SVN.
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.
Committed revision 286465.
Previous Comments:
[2009-07-10 13:38:01] frase at cs dot wisc dot edu
The supplied patch does fix the problem in 5.3.0 on Linux; I have no
Windows build environment so I can't test it there but can't see why it
wouldn't also work. Since the patch was to OpenSSL I've changed the
category back.
Many thanks!
[2009-07-09 21:53:03] sriram dot natarajan at gmail dot com
better still, here is the patch (more readable format)
http://pastebin.org/805
[2009-07-09 21:47:44] sriram dot natarajan at gmail dot com
thanks for your patience.
here is a patch that should address your issue. to apply this patch,
save the above text into a file and run
--- ext/openssl/xp_ssl.c.ORIG Thu Jul 9 12:20:44 2009
+++ ext/openssl/xp_ssl.cThu Jul 9 12:29:18 2009
@@ -672,7 +672,11 @@
* we notice that the connect
has actually been established */
php_stream_socket_ops.set_option(stream, option, value, ptrparam
TSRMLS_CC);
- if (xparam->outputs.returncode
== 0 && sslsock->enable_on_connect) {
+ if
((sslsock->enable_on_connect) &&
+
((xparam->outputs.returncode == 0) ||
+(xparam->op ==
STREAM_XPORT_OP_CONNECT_ASYNC && xparam->outputs.returncode == 1 &&
+
xparam->outputs.error_code == EINPROGRESS)))
+ {
if
(php_stream_xport_crypto_setup(stream, sslsock->method, NULL TSRMLS_CC)
< 0 ||
php_stream_xport_crypto_enable(stream, 1 TSRMLS_CC) < 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Failed to enable crypto");
- download and unzip the latest php 5.3snapshot from
http://snaps.php.net
- cd ; patch -p0 -d . <
now, you can run make and should be able to test it.
i will wait for some one to review this patch . hopefully, should
happen before next release :-)
[2009-07-01 16:28:14] frase at cs dot wisc dot edu
This bug remains also in 5.2.10.
Let's try a new summary and changing the category to "Sockets", maybe
it will get someone's attention.
[2009-06-30 14:28:01] frase at cs dot wisc dot edu
This bug remains in 5.3.0 final.
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/48182
--
Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48695 [Asn]: PHP_SELF / SCRIPT_NAME issues not bogus - bugfix in 5.2.9 still causing trouble
ID: 48695
Updated by: srina...@php.net
Reported By: allerlei+bugs dot php dot net at sihw dot nl
Status: Assigned
Bug Type: CGI related
Operating System: Centos 4/5
PHP Version: 5.2.10
Assigned To: srinatar
New Comment:
in default apache cgi/fastcgi mode, apache sets some of these cgi
variables differently compared to what this bug submitter is doing in
his environment. hence this bug wasn't easy to reproduce.
as per the default apache cgi/fastcgi environment, apache sets
SCRIPT_FILENAME - to point to the location of the handler and
PATH_TRANSLATED to point to the location of the translated path of the
uri (translated from the document root). however, SCRIPT_NAME can be set
incorrectly (by apache cgi) in this default environment. So, php-cgi
sapi code needed to fix the SCRIPT_NAME in the default environment.
now, this potentially affects other web servers like iplanet web
server. so, a fix for this issue went into php 5.2.9/5.2.10 (see also
bug #47149/ #47042). now this fix handles scenario for apache as well as
other web servers in default mode.
however, here bug submitter uses apache in cgi environment along with a
custom apache handler (startscript - a handler script with custom
modifications based on cgiwrap which is another popular apache handler
script for cgi environment in multi hosting mode).
here, the bug seems to happen if some one uses custom apache handler
(some thing that mimics programs like cgiwrap) and accordingly munges
SCRIPT_FILENAME , PATH_TRANSLATED and other cgi variables appropriately
before feeding to php-cgi process.
php-cgi sapi code, with php version 5.2.9/10, expects the
SCRIPT_FILENAME to point to the apache handler while PATH_TRANSLATED to
point to the virtual path of the input uri.
however, the custom apache handler script that the bug submitter uses
in his environment - configured SCRIPT_FILENAME / PATH_TRANSLATED to
point to the virtual path of the input uri (to be the actual file name
of the input request uri)
this behavior is different from that of default apache behavior as well
as that of cgi wrappers like cgiwrap etc. hence bug submitter is seeing
different behavior with 5.2.10.
having said that - i couldn't find official documentation anywhere
within apache web site where it says SCRIPT_FILENAME cannot point to the
actual input uri, so, i can't outright reject out bug submitter's custom
apache handler code as well.
i am currently looking into the the best way to resolve this issue so
that customers like this bug submitter can continue to work without
having to make any changes into their apache handler script.
Previous Comments:
[2009-07-20 08:20:21] allerlei+bugs dot php dot net at sihw dot nl
Sorry about the delay and the work I caused. I hope this is not
something I missed somewhere. The thing is, the same 'startscript' is
used for both 5.2.8 and 5.2.10. This program uses the php-cgi executable
to start the script (is execs into php-cgi + arguments).
I used this script to generate the environment:
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
foreach my $i (sort keys %ENV)
{
print "${i}: " . $ENV{$i} . "\n";
}
#end
This is (most of) the output:
DOCUMENT_ROOT: /home/pakket/wensweb/web
GATEWAY_INTERFACE: CGI/1.1
HTTP_ACCEPT:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_CHARSET: UTF-8,*
HTTP_ACCEPT_ENCODING: gzip,deflate
HTTP_ACCEPT_LANGUAGE: nl-nl,en;q=0.7,fr;q=0.3
HTTP_CONNECTION: keep-alive
HTTP_HOST: www.wensweb.nl
HTTP_KEEP_ALIVE: 300
HTTP_USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 6.0; nl;
rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
PATH: /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
PATH_INFO:
PATH_TRANSLATED: /home/pakket/wensweb/web/test8932.cgi
QUERY_STRING:
REDIRECT_HANDLER: startscript_exe
REDIRECT_SCRIPT_URI: http://www.wensweb.nl/test8932.cgi
REDIRECT_SCRIPT_URL: /test8932.cgi
REDIRECT_STATUS: 200
REDIRECT_URL: /test8932.cgi
REMOTE_ADDR: 83.161.60.47
REMOTE_PORT: 50783
REQUEST_METHOD: GET
REQUEST_URI: /test8932.cgi
SCRIPT_FILENAME: /home/pakket/wensweb/web/test8932.cgi
SCRIPT_NAME: /spinwebstartscript/startscript/wensweb/exe/test8932.cgi
SCRIPT_URI: http://www.wensweb.nl/test8932.cgi
SCRIPT_URL: /test8932.cgi
SERVER_ADDR: 81.26.210.110
SERVER_ADMIN: *
SERVER_NAME: www.wensweb.nl
SERVER_PORT: 80
SERVER_PROTOCOL: HTTP/1.1
SERVER_SIGNATURE:
SERVER_SOFTWARE: Apache
--
The script is now removed ofcause.
Do you think these values are correct enough? If you think this is not
bogus (as all stuff works ok in 5.2.8..) I can give you access if you
need it. Please e-mail me privately for that.
Jelmer)
[2009-07-16 19:25:15] srina...@php.net
can you kindly provide the output of
PATH_TRANSLA
#48695 [Asn->Ana]: PHP_SELF / SCRIPT_NAME issues not bogus - bugfix in 5.2.9 still causing trouble
ID: 48695
Updated by: srina...@php.net
Reported By: allerlei+bugs dot php dot net at sihw dot nl
-Status: Assigned
+Status: Analyzed
Bug Type: CGI related
Operating System: Centos 4/5
PHP Version: 5.2.10
Assigned To: srinatar
Previous Comments:
[2009-07-29 07:36:09] srina...@php.net
in default apache cgi/fastcgi mode, apache sets some of these cgi
variables differently compared to what this bug submitter is doing in
his environment. hence this bug wasn't easy to reproduce.
as per the default apache cgi/fastcgi environment, apache sets
SCRIPT_FILENAME - to point to the location of the handler and
PATH_TRANSLATED to point to the location of the translated path of the
uri (translated from the document root). however, SCRIPT_NAME can be set
incorrectly (by apache cgi) in this default environment. So, php-cgi
sapi code needed to fix the SCRIPT_NAME in the default environment.
now, this potentially affects other web servers like iplanet web
server. so, a fix for this issue went into php 5.2.9/5.2.10 (see also
bug #47149/ #47042). now this fix handles scenario for apache as well as
other web servers in default mode.
however, here bug submitter uses apache in cgi environment along with a
custom apache handler (startscript - a handler script with custom
modifications based on cgiwrap which is another popular apache handler
script for cgi environment in multi hosting mode).
here, the bug seems to happen if some one uses custom apache handler
(some thing that mimics programs like cgiwrap) and accordingly munges
SCRIPT_FILENAME , PATH_TRANSLATED and other cgi variables appropriately
before feeding to php-cgi process.
php-cgi sapi code, with php version 5.2.9/10, expects the
SCRIPT_FILENAME to point to the apache handler while PATH_TRANSLATED to
point to the virtual path of the input uri.
however, the custom apache handler script that the bug submitter uses
in his environment - configured SCRIPT_FILENAME / PATH_TRANSLATED to
point to the virtual path of the input uri (to be the actual file name
of the input request uri)
this behavior is different from that of default apache behavior as well
as that of cgi wrappers like cgiwrap etc. hence bug submitter is seeing
different behavior with 5.2.10.
having said that - i couldn't find official documentation anywhere
within apache web site where it says SCRIPT_FILENAME cannot point to the
actual input uri, so, i can't outright reject out bug submitter's custom
apache handler code as well.
i am currently looking into the the best way to resolve this issue so
that customers like this bug submitter can continue to work without
having to make any changes into their apache handler script.
[2009-07-20 08:20:21] allerlei+bugs dot php dot net at sihw dot nl
Sorry about the delay and the work I caused. I hope this is not
something I missed somewhere. The thing is, the same 'startscript' is
used for both 5.2.8 and 5.2.10. This program uses the php-cgi executable
to start the script (is execs into php-cgi + arguments).
I used this script to generate the environment:
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
foreach my $i (sort keys %ENV)
{
print "${i}: " . $ENV{$i} . "\n";
}
#end
This is (most of) the output:
DOCUMENT_ROOT: /home/pakket/wensweb/web
GATEWAY_INTERFACE: CGI/1.1
HTTP_ACCEPT:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_CHARSET: UTF-8,*
HTTP_ACCEPT_ENCODING: gzip,deflate
HTTP_ACCEPT_LANGUAGE: nl-nl,en;q=0.7,fr;q=0.3
HTTP_CONNECTION: keep-alive
HTTP_HOST: www.wensweb.nl
HTTP_KEEP_ALIVE: 300
HTTP_USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 6.0; nl;
rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
PATH: /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
PATH_INFO:
PATH_TRANSLATED: /home/pakket/wensweb/web/test8932.cgi
QUERY_STRING:
REDIRECT_HANDLER: startscript_exe
REDIRECT_SCRIPT_URI: http://www.wensweb.nl/test8932.cgi
REDIRECT_SCRIPT_URL: /test8932.cgi
REDIRECT_STATUS: 200
REDIRECT_URL: /test8932.cgi
REMOTE_ADDR: 83.161.60.47
REMOTE_PORT: 50783
REQUEST_METHOD: GET
REQUEST_URI: /test8932.cgi
SCRIPT_FILENAME: /home/pakket/wensweb/web/test8932.cgi
SCRIPT_NAME: /spinwebstartscript/startscript/wensweb/exe/test8932.cgi
SCRIPT_URI: http://www.wensweb.nl/test8932.cgi
SCRIPT_URL: /test8932.cgi
SERVER_ADDR: 81.26.210.110
SERVER_ADMIN: *
SERVER_NAME: www.wensweb.nl
SERVER_PORT: 80
SERVER_PROTOCOL: HTTP/1.1
SERVER_SIGNATURE:
SERVER_SOFTWARE: Apache
--
The script is now removed ofcause.
Do you think these values are correct enough? If you think this is not
bogus (as all stuff works ok in 5.2.8..) I can give you access if you
need it. Please e-mail me privately for that.
Jelmer)
--
#48695 [Ana->Bgs]: PHP_SELF / SCRIPT_NAME issues not bogus - bugfix in 5.2.9 still causing trouble
ID: 48695
Updated by: srina...@php.net
Reported By: allerlei+bugs dot php dot net at sihw dot nl
-Status: Analyzed
+Status: Bogus
Bug Type: CGI related
Operating System: Centos 4/5
PHP Version: 5.2.10
Assigned To: srinatar
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
After discussing this issue with the bug submitter , moving this issue
to bogus (not an issue).
here, the submitter was trying to use php-cgi as not an standard apache
handler but with their own apache handler. however, their own standard
handler was not behaving the way apache handler behaves. hencey,they run
into this issue.
with php 5.2.10 and above , if running under cgi/fastcgi environment ,
we expect PATH_TRANSLATED to provide the actual location of the script
to execute while SCRIPT_FILENAME (env variable from apache) to be
pointing to the location of php-cgi binary itself. This is the default
behavior of apache handler and also other popular handlers like cgiwrap
etc.
so, if some one is writing a custom handler, they need to follow the
same convention as done with default handler behavior.
Previous Comments:
[2009-07-29 07:36:09] srina...@php.net
in default apache cgi/fastcgi mode, apache sets some of these cgi
variables differently compared to what this bug submitter is doing in
his environment. hence this bug wasn't easy to reproduce.
as per the default apache cgi/fastcgi environment, apache sets
SCRIPT_FILENAME - to point to the location of the handler and
PATH_TRANSLATED to point to the location of the translated path of the
uri (translated from the document root). however, SCRIPT_NAME can be set
incorrectly (by apache cgi) in this default environment. So, php-cgi
sapi code needed to fix the SCRIPT_NAME in the default environment.
now, this potentially affects other web servers like iplanet web
server. so, a fix for this issue went into php 5.2.9/5.2.10 (see also
bug #47149/ #47042). now this fix handles scenario for apache as well as
other web servers in default mode.
however, here bug submitter uses apache in cgi environment along with a
custom apache handler (startscript - a handler script with custom
modifications based on cgiwrap which is another popular apache handler
script for cgi environment in multi hosting mode).
here, the bug seems to happen if some one uses custom apache handler
(some thing that mimics programs like cgiwrap) and accordingly munges
SCRIPT_FILENAME , PATH_TRANSLATED and other cgi variables appropriately
before feeding to php-cgi process.
php-cgi sapi code, with php version 5.2.9/10, expects the
SCRIPT_FILENAME to point to the apache handler while PATH_TRANSLATED to
point to the virtual path of the input uri.
however, the custom apache handler script that the bug submitter uses
in his environment - configured SCRIPT_FILENAME / PATH_TRANSLATED to
point to the virtual path of the input uri (to be the actual file name
of the input request uri)
this behavior is different from that of default apache behavior as well
as that of cgi wrappers like cgiwrap etc. hence bug submitter is seeing
different behavior with 5.2.10.
having said that - i couldn't find official documentation anywhere
within apache web site where it says SCRIPT_FILENAME cannot point to the
actual input uri, so, i can't outright reject out bug submitter's custom
apache handler code as well.
i am currently looking into the the best way to resolve this issue so
that customers like this bug submitter can continue to work without
having to make any changes into their apache handler script.
[2009-07-20 08:20:21] allerlei+bugs dot php dot net at sihw dot nl
Sorry about the delay and the work I caused. I hope this is not
something I missed somewhere. The thing is, the same 'startscript' is
used for both 5.2.8 and 5.2.10. This program uses the php-cgi executable
to start the script (is execs into php-cgi + arguments).
I used this script to generate the environment:
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
foreach my $i (sort keys %ENV)
{
print "${i}: " . $ENV{$i} . "\n";
}
#end
This is (most of) the output:
DOCUMENT_ROOT: /home/pakket/wensweb/web
GATEWAY_INTERFACE: CGI/1.1
HTTP_ACCEPT:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_CHARSET: UTF-8,*
HTTP_ACCEPT_ENCODING: gzip,deflate
HTTP_ACCEPT_LANGUAGE: nl-nl,en;q=0.7,fr;q=0.3
HTTP_CONNECTION: keep-alive
HTTP_HOST: www.wensweb.nl
HTTP_KEEP_ALIVE: 300
HTTP_USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 6.0; nl;
rv:1.9.0.11) Gecko/2009060215 Fi
#49173 [Fbk]: Php don't work with mod_fcgid if I load a extension
ID: 49173 Updated by: srina...@php.net Reported By: malina dot laszlo at malina dot hu Status: Feedback Bug Type: Dynamic loading Operating System: Debian Lenny PHP Version: 5.3.0 New Comment: i very much doubt if this is a php bug. i bet that extension like gd.so is probably depending on a library which it is probably unable to load in your fastcgi environment. you can verify this by running ldd on gd.so and if there is any dependent library that is not in /lib or /usr/lib (or for that any matter any directory that is not in /etc/ld.so.conf.d/*.conf) then this could be the cause. to confirm this is the issue, you could try loading an extension which does not depend on libraries that is not in /lib or /usr/lib. if it works fine, then you could either a) update your apachectl script to add LD_LIBRARY_PATH to include all your dependent library locations b) create a custom .conf file under /etc/ld.so.conf.d which contains the list of directories to search in your environment. Previous Comments: [2009-08-06 09:43:57] malina dot laszlo at malina dot hu Hi! I tried to compile the PHP (not snapshot, but release). There are two ways to do: 1. I am updating system libraries (libgd, libpng, etc) and compiling gd extension by shared (--with-gd=shared,/usr and png,jpg,xpm, freetype,etc by shared) 2. I compiling gd extension by "embedded" (it is not shared). (--with-gd [it is embedded for me] and png, jpg,xpm, etc is not shared) Results: Point 1: it is failed, same error Point 2: this is good, no error! I will try to compile snapshot-php5.3 by shared and "embedded". I'm curious :) [2009-08-06 08:57:47] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-06 08:07:09] malina dot laszlo at malina dot hu Hi! I am trying to load extensions and each works well except for the gd.so. If I load gd, server send me "Status 500" and written above logs. Before there was already a compiling problem (gdhelper), but this is no, without error compiled. Thanks for your help! Bearcheese [2009-08-06 00:31:26] malina dot laszlo at malina dot hu Description: Hello! I compiled php-5.3.0 (CGI), apache-2.2.12 (mpm-worker) and mod_fcgid-2.2.0 on Debian Lenny. I have more extension: mysql, mysqli, pdo, gd, gettext, memcache, imagick, idn, etc. When I give extension_dir (with absoluth path) and I does NOT allow to load extensions then no problem (and no extension). When I does allow to load only ONE extension (for example gd.so), then the server send me "Internal server error" (status 500). I can see in apache error-log: [warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error. [info] (104)Connection reset by peer: mod_fcgid: can't read data from fcgid handler [warn] (104)Connection reset by peer: mod_fcgid: ap_pass_brigade failed in handle_request function What is problem? (Sorry for my bad English!) -- Edit this bug report at http://bugs.php.net/?id=49173&edit=1
#48668 [Ctl]: foreach with array will coredump php
ID: 48668 Updated by: srina...@php.net Reported By: dmda at yandex dot ru Status: Critical Bug Type: Reproducible crash Operating System: Solaris PHP Version: 5.3.0RC4 Assigned To: dsp New Comment: by any chance, the submitter built this php5.3 on one machine and ran it on another machine ? currently, php 5.3 build process includes -xtarget=native within the configure flags when used with sun studio compiler. this would mean that this compiled program will not work on different class of sparc machines (unless recompiled for that platform) for e.g, if some one currently built php 5.3 on ultra-sparc III+/IV+ based system (like v410, v220, v880 etc) then if they try to run the same on older hardware with chips like sparc II+ hardware, then they might run into crash. Previous Comments: [2009-07-28 14:25:31] d...@php.net PHP is broken on Sparc (and possible every other processor that requires memalignment) at the moment [2009-06-26 15:42:15] d...@php.net It looks like this is a memalign issue. PHP 5.3.0 is now build with flags to avoid the crash. I assign the bug to me to provide a proper fix for the issue for 5.3.1 [2009-06-24 12:21:10] johan...@php.net When using --enable-dbug the code works, without --enable-debug the code fails, maybe that's the reason why I didn't see this before. uname -a SunOS techra46 5.8 Generic_117350-54 sun4u sparc SUNW,Sun-Fire-V210 The issue seems to be independent from the compiler but in some way system dependent, another similar box worked for me. [2009-06-24 06:49:42] dmda at yandex dot ru to me it looks like bogus pointer appeared in the heap's cache first, then it was returned by the allocator, called by ALLOC_ZVAL(). I see no other reasons for the tmp pointer to have this strange value. [2009-06-24 00:32:54] scott...@php.net Don't think its endian specific, PPC chip works. Will test with another sparc box shortly. 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/48668 -- Edit this bug report at http://bugs.php.net/?id=48668&edit=1
#49209 [Fbk]: apche2 crashes and return blank output
ID: 49209 Updated by: srina...@php.net Reported By: bendl at pjcomp dot cz Status: Feedback Bug Type: Apache2 related Operating System: Debian Lenny 2.6.26-2-amd64 PHP Version: 5.2.10 New Comment: is your apache pre-fork or worker mpm ? Previous Comments: [2009-08-10 18:56:33] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-10 13:39:00] bendl at pjcomp dot cz Description: apache2 crashes about 2-10x within 100 reloads. There are too many messages in apache error.log (too often) [Mon Aug 10 15:34:12 2009] [notice] child pid 27199 exit signal Segmentation fault (11) [Mon Aug 10 15:34:13 2009] [notice] child pid 28539 exit signal Segmentation fault (11) [Mon Aug 10 15:34:15 2009] [notice] child pid 27827 exit signal Segmentation fault (11) [Mon Aug 10 15:34:15 2009] [notice] child pid 29382 exit signal Segmentation fault (11) [Mon Aug 10 15:34:18 2009] [notice] child pid 28132 exit signal Segmentation fault (11) [Mon Aug 10 15:34:20 2009] [notice] child pid 29426 exit signal Segmentation fault (11) [Mon Aug 10 15:34:25 2009] [notice] child pid 29016 exit signal Segmentation fault (11) [Mon Aug 10 15:34:30 2009] [notice] child pid 29437 exit signal Segmentation fault (11) Actual result: -- [Mon Aug 10 15:20:05 2009] [notice] child pid 22113 exit signal Segmentation fault (11) *** glibc detected *** /usr/sbin/apache2: munmap_chunk(): invalid pointer: 0x7fc6672e6598 *** === Backtrace: = /lib/libc.so.6[0x7fc6643916c8] /usr/lib/apache2/modules/libphp5.so(zend_hash_destroy+0x28)[0x7fc661564aa8] /usr/lib/apache2/modules/libphp5.so(zend_object_std_dtor+0x29)[0x7fc661575ed9] /usr/lib/apache2/modules/libphp5.so(zend_objects_free_object_storage+0x9)[0x7fc661575ef9] /usr/lib/apache2/modules/libphp5.so(zend_objects_store_free_object_storage+0x3f)[0x7fc661578fcf] /usr/lib/apache2/modules/libphp5.so(shutdown_executor+0x20c)[0x7fc66154f36c] /usr/lib/apache2/modules/libphp5.so(zend_deactivate+0x62)[0x7fc66155a0b2] /usr/lib/apache2/modules/libphp5.so(php_request_shutdown+0x192)[0x7fc661514fa2] /usr/lib/apache2/modules/libphp5.so[0x7fc6615cebb3] /usr/sbin/apache2(ap_run_handler+0x83)[0x7fc665174e13] /usr/sbin/apache2(ap_invoke_handler+0x9f)[0x7fc66517853f] /usr/sbin/apache2(ap_internal_redirect+0x60)[0x7fc665185d70] /usr/lib/apache2/modules/mod_rewrite.so[0x7fc65edccba5] /usr/sbin/apache2(ap_run_handler+0x83)[0x7fc665174e13] /usr/sbin/apache2(ap_invoke_handler+0x9f)[0x7fc66517853f] /usr/sbin/apache2(ap_process_request+0x1c8)[0x7fc665185f48] /usr/sbin/apache2[0x7fc665182e78] /usr/sbin/apache2(ap_run_process_connection+0x83)[0x7fc66517c7e3] /usr/sbin/apache2[0x7fc66518a84e] /usr/sbin/apache2[0x7fc66518ab3a] /usr/sbin/apache2(ap_mpm_run+0xab2)[0x7fc66518b652] /usr/sbin/apache2(main+0xa2d)[0x7fc66516127d] /lib/libc.so.6(__libc_start_main+0xe6)[0x7fc66433e5c6] /usr/sbin/apache2[0x7fc665160329] === Memory map: 7fc65a66-7fc65a67a000 r-xp 08:01 1185616 /lib/libgcc_s.so.1 7fc65a67a000-7fc65a879000 ---p 0001a000 08:01 1185616 /lib/libgcc_s.so.1 7fc65a879000-7fc65a87a000 rw-p 00019000 08:01 1185616 /lib/libgcc_s.so.1 -- Edit this bug report at http://bugs.php.net/?id=49209&edit=1
#48182 [Asn]: asynchronous socket connection over ssl fails entirely
ID: 48182 Updated by: srina...@php.net Reported By: frase at cs dot wisc dot edu Status: Assigned Bug Type: OpenSSL related Operating System: * PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: thanks for verifying it. let me try this again with php 5.2.11rc1 and see why it is happening (again). Previous Comments: [2009-08-14 13:56:38] frase at cs dot wisc dot edu To clarify, I tested the posted patch by recompiling 5.3.0 on Ubuntu Linux, and the fix worked. I was not able to test the patch in 5.2.10 on Windows as I have no suitable build environment. The posted 5.2.11RC1 binaries (under Apache 2.2.11) now exhibit this new problem. [2009-08-14 13:49:53] frase at cs dot wisc dot edu I'm re-opening this bug as the fix appears not to work in 5.2.11RC1. With the same testing code as in the original report, when connecting synchronously, all is well. But when connecting asynchronously I get these warnings: Warning: stream_socket_client() [function.stream-socket-client]: SSL: The operation completed successfully. in test-async-ssl.php on line 14 Warning: stream_socket_client() [function.stream-socket-client]: Failed to enable crypto in test-async-ssl.php on line 14 Warning: stream_socket_client() [function.stream-socket-client]: unable to connect to ssl://91.189.90.211:443 (Unknown error) in test-async-ssl.php on line 14 Line 14 is of course the stream_socket_client() call. Additionally, after these warnings, $errno contains 10035 and $errstr is empty. [2009-07-28 19:34:15] srina...@php.net This bug has been fixed in SVN. 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. Committed revision 286465. [2009-07-10 13:38:01] frase at cs dot wisc dot edu The supplied patch does fix the problem in 5.3.0 on Linux; I have no Windows build environment so I can't test it there but can't see why it wouldn't also work. Since the patch was to OpenSSL I've changed the category back. Many thanks! [2009-07-09 21:53:03] sriram dot natarajan at gmail dot com better still, here is the patch (more readable format) http://pastebin.org/805 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/48182 -- Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48182 [Asn->Fbk]: asynchronous socket connection over ssl fails entirely
ID: 48182 Updated by: srina...@php.net Reported By: frase at cs dot wisc dot edu -Status: Assigned +Status: Feedback Bug Type: OpenSSL related Operating System: * PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: i was able to verify this successfully by compiling php 5.2.11 rc1 (did not use the rc1 candidate build) on windows and run the below script that you attached as part of this bug report. now, if you have a different test script that is causing this issue then i would suggest that you should better file a separate bug and attach this new test case. this way , we can track different issues separately rather than overloading this bug. Previous Comments: [2009-08-18 13:40:41] frase at cs dot wisc dot edu The new problem could be unrelated, it is definitely different behavior than before. I've reported it here only because it still only affects ssl:// socket connections opened asynchronously -- tcp sockets open fine (both sync and async), and ssl sockets open fine synchronously. Also, I have a new clue. The very first attempt (ssl+async) on a freshly booted Apache server works fine. It is only on the second and subsequent attempts that the new warnings appear and the socket won't open. When I restart Apache, it works one more time. This is Windows 2000 Professional SP4, Apache 2.2.11, with the posted PHP 5.2.11RC1-Win32-VC6 binary (threadsafe, and apparently including OpenSSL 0.9.8k) configured as an Apache module (not CGI). Hope that helps. [2009-08-18 02:11:12] srina...@php.net thanks for verifying it. let me try this again with php 5.2.11rc1 and see why it is happening (again). [2009-08-14 13:56:38] frase at cs dot wisc dot edu To clarify, I tested the posted patch by recompiling 5.3.0 on Ubuntu Linux, and the fix worked. I was not able to test the patch in 5.2.10 on Windows as I have no suitable build environment. The posted 5.2.11RC1 binaries (under Apache 2.2.11) now exhibit this new problem. [2009-08-14 13:49:53] frase at cs dot wisc dot edu I'm re-opening this bug as the fix appears not to work in 5.2.11RC1. With the same testing code as in the original report, when connecting synchronously, all is well. But when connecting asynchronously I get these warnings: Warning: stream_socket_client() [function.stream-socket-client]: SSL: The operation completed successfully. in test-async-ssl.php on line 14 Warning: stream_socket_client() [function.stream-socket-client]: Failed to enable crypto in test-async-ssl.php on line 14 Warning: stream_socket_client() [function.stream-socket-client]: unable to connect to ssl://91.189.90.211:443 (Unknown error) in test-async-ssl.php on line 14 Line 14 is of course the stream_socket_client() call. Additionally, after these warnings, $errno contains 10035 and $errstr is empty. [2009-07-28 19:34:15] srina...@php.net This bug has been fixed in SVN. 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. Committed revision 286465. 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/48182 -- Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#48182 [Fbk->Csd]: asynchronous socket connection over ssl fails entirely
ID: 48182 Updated by: srina...@php.net Reported By: frase at cs dot wisc dot edu -Status: Feedback +Status: Closed Bug Type: OpenSSL related Operating System: * PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: This bug has been fixed in SVN. 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 original reported issue is now resolved in all platforms. however, the bug submitter is noticing the same script behaving differently on windows. and has filed a separate bug to track this (#49295). hence, closing this as fixed in svn . Previous Comments: [2009-08-19 13:54:53] frase at cs dot wisc dot edu It is exactly the same script that produces this new error for me on Windows. However as you request, I have opened a new bug#49295 for this behavior. [2009-08-19 03:35:30] srina...@php.net i was able to verify this successfully by compiling php 5.2.11 rc1 (did not use the rc1 candidate build) on windows and run the below script that you attached as part of this bug report. now, if you have a different test script that is causing this issue then i would suggest that you should better file a separate bug and attach this new test case. this way , we can track different issues separately rather than overloading this bug. [2009-08-18 13:40:41] frase at cs dot wisc dot edu The new problem could be unrelated, it is definitely different behavior than before. I've reported it here only because it still only affects ssl:// socket connections opened asynchronously -- tcp sockets open fine (both sync and async), and ssl sockets open fine synchronously. Also, I have a new clue. The very first attempt (ssl+async) on a freshly booted Apache server works fine. It is only on the second and subsequent attempts that the new warnings appear and the socket won't open. When I restart Apache, it works one more time. This is Windows 2000 Professional SP4, Apache 2.2.11, with the posted PHP 5.2.11RC1-Win32-VC6 binary (threadsafe, and apparently including OpenSSL 0.9.8k) configured as an Apache module (not CGI). Hope that helps. [2009-08-18 02:11:12] srina...@php.net thanks for verifying it. let me try this again with php 5.2.11rc1 and see why it is happening (again). [2009-08-14 13:56:38] frase at cs dot wisc dot edu To clarify, I tested the posted patch by recompiling 5.3.0 on Ubuntu Linux, and the fix worked. I was not able to test the patch in 5.2.10 on Windows as I have no suitable build environment. The posted 5.2.11RC1 binaries (under Apache 2.2.11) now exhibit this new 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/48182 -- Edit this bug report at http://bugs.php.net/?id=48182&edit=1
#49295 [Asn]: stream_socket_client() fails on SSL+async
ID: 49295 Updated by: srina...@php.net Reported By: frase at cs dot wisc dot edu Status: Assigned Bug Type: OpenSSL related Operating System: Win 2000 Pro SP4 PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: this issue seems to be happening when this script is executed more than once and also seems to be happening only on windows. Previous Comments: [2009-08-19 13:52:18] frase at cs dot wisc dot edu Description: stream_socket_client() can only open one socket using SSL and the STREAM_CLIENT_ASYNC_CONNECT flag, and then fails every time until the Apache process is restarted. SSL sockets without ASYNC open fine, as do plain TCP sockets with or without ASYNC. Originally reported as an update to bug #48182, which also only affected the combination of SSL+ASYNC, but now reported separately here per srina...@php.net's request. Additionally, the timeout (argument #4 to stream_socket_client()) is not ignored when using ASYNC, contrary to the manual: if set to 0 here, the first warning is "SSL: connection timeout" instead of "SSL: The operation completed successfully." Windows 2000 Professional SP4 Apache 2.2.11 PHP 5.2.11RC1-Win32-VC6-x86 (threadsafe binary from http://windows.php.net/qa/) configured as an Apache module with php_openssl.dll and libeay32.dll+ssleay.dll v0.9.8k Reproduce code: --- http://bugs.php.net/?id=49295&edit=1
#49394 [Csd]: Probable date_format regression due to #48058
ID: 49394
Updated by: srina...@php.net
Reported By: hjones at hopone dot net
Status: Closed
Bug Type: Strings related
Operating System: Solaris 9 (Sparc V9; 64-bit)
PHP Version: 5.2.10
New Comment:
the fix for this bug was delivered as part of fix for bug:48276 (
http://bugs.php.net/bug.php?id=48276). if you wish, you can use
5.2.11RC1 candidate build available from
http://downloads.php.net/ilia/php-5.2.11RC1.tar.bz2
pl. note that these RC1 builds are meant for testing and not
production.
Previous Comments:
[2009-08-27 21:27:10] der...@php.net
This bug has been fixed in SVN.
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.
This is already fixed in SVN, please try a snapshot.
[2009-08-27 20:49:24] hjones at hopone dot net
PHP was compiled with the following GCC:
# gcc -v
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.3.2
[2009-08-27 20:43:17] hjones at hopone dot net
Description:
Upgrading from 5.2.9 to 5.2.10 causes setcookie() to return the year
'' instead of '2009' when used with time() as the cookie expiry.
Replacing 5.2.10's ext/date/php_date.{c,h} with 5.2.9's copy and
recompiling corrects this issue.
I believe this is a regression caused by PHP bug #48058
Reproduce code:
---
Expected result:
Set-Cookie: php_test_cookie=test_cookie_value; expires=Sun, 13-Sep-2009
11:31:54 GMT
Actual result:
--
Set-Cookie: php_test_cookie=test_cookie_value; expires=Sun, 13-Sep-
11:31:54 GMT
--
Edit this bug report at http://bugs.php.net/?id=49394&edit=1
#49295 [Asn]: stream_socket_client() fails on SSL+async
ID: 49295 Updated by: srina...@php.net Reported By: frase at cs dot wisc dot edu Status: Assigned Bug Type: OpenSSL related Operating System: Win 2000 Pro SP4 PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: ok, i was looking into this issue today. the issue is that , especially on windows -where sockets are not file descriptors unlike in unix, async sockets and openssl works together only if we use BIO wrappers provided by openssl module instead of directly accessing underlying sockets as file descriptors. the possible right way to do this would be to use to socket wrappers provided by SSL module (known as BIO wrappers which makes it work properly on windows). this will require some amount of fiddling our openssl module. i don't think, 5.2 is a good place to do this change. for now, commenting this below code should help you to run your script properly on windows. stream_set_blocking($socket, 0); i will spend more time on this and investigate on the best way to use BIO wrappers within existing openssl module say within php 5.3 Previous Comments: [2009-08-21 15:05:47] frase at cs dot wisc dot edu I had a chance to compile and test PHP5.2.11RC1 under Linux this morning (Ubuntu Jaunty, Apache 2.2.11 from repositories), and these warnings do not appear, however I noticed another problem. Although the SSL+async connection is successful and data is returned under Linux, the socket is not actually opened asynchonously. The script blocks until the socket has finished opening, exactly as it does without the ASYNC flag. This is also true under Windows, for the first run -- after that, of course, it returns the errors posted above. [2009-08-21 01:15:44] srina...@php.net this issue seems to be happening when this script is executed more than once and also seems to be happening only on windows. [2009-08-19 13:52:18] frase at cs dot wisc dot edu Description: stream_socket_client() can only open one socket using SSL and the STREAM_CLIENT_ASYNC_CONNECT flag, and then fails every time until the Apache process is restarted. SSL sockets without ASYNC open fine, as do plain TCP sockets with or without ASYNC. Originally reported as an update to bug #48182, which also only affected the combination of SSL+ASYNC, but now reported separately here per srina...@php.net's request. Additionally, the timeout (argument #4 to stream_socket_client()) is not ignored when using ASYNC, contrary to the manual: if set to 0 here, the first warning is "SSL: connection timeout" instead of "SSL: The operation completed successfully." Windows 2000 Professional SP4 Apache 2.2.11 PHP 5.2.11RC1-Win32-VC6-x86 (threadsafe binary from http://windows.php.net/qa/) configured as an Apache module with php_openssl.dll and libeay32.dll+ssleay.dll v0.9.8k Reproduce code: --- http://bugs.php.net/?id=49295&edit=1
#49295 [Asn]: stream_socket_client() fails on SSL+async
ID: 49295 Updated by: srina...@php.net Reported By: frase at cs dot wisc dot edu Status: Assigned Bug Type: OpenSSL related Operating System: Win 2000 Pro SP4 PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: just a follow up note, this issue (async not working consistently with openssl on windows) has always been the case and this issue has nothing to do with the fix that went in for bug:48182. Previous Comments: [2009-09-02 08:09:22] srina...@php.net ok, i was looking into this issue today. the issue is that , especially on windows -where sockets are not file descriptors unlike in unix, async sockets and openssl works together only if we use BIO wrappers provided by openssl module instead of directly accessing underlying sockets as file descriptors. the possible right way to do this would be to use to socket wrappers provided by SSL module (known as BIO wrappers which makes it work properly on windows). this will require some amount of fiddling our openssl module. i don't think, 5.2 is a good place to do this change. for now, commenting this below code should help you to run your script properly on windows. stream_set_blocking($socket, 0); i will spend more time on this and investigate on the best way to use BIO wrappers within existing openssl module say within php 5.3 [2009-08-21 15:05:47] frase at cs dot wisc dot edu I had a chance to compile and test PHP5.2.11RC1 under Linux this morning (Ubuntu Jaunty, Apache 2.2.11 from repositories), and these warnings do not appear, however I noticed another problem. Although the SSL+async connection is successful and data is returned under Linux, the socket is not actually opened asynchonously. The script blocks until the socket has finished opening, exactly as it does without the ASYNC flag. This is also true under Windows, for the first run -- after that, of course, it returns the errors posted above. [2009-08-21 01:15:44] srina...@php.net this issue seems to be happening when this script is executed more than once and also seems to be happening only on windows. [2009-08-19 13:52:18] frase at cs dot wisc dot edu Description: stream_socket_client() can only open one socket using SSL and the STREAM_CLIENT_ASYNC_CONNECT flag, and then fails every time until the Apache process is restarted. SSL sockets without ASYNC open fine, as do plain TCP sockets with or without ASYNC. Originally reported as an update to bug #48182, which also only affected the combination of SSL+ASYNC, but now reported separately here per srina...@php.net's request. Additionally, the timeout (argument #4 to stream_socket_client()) is not ignored when using ASYNC, contrary to the manual: if set to 0 here, the first warning is "SSL: connection timeout" instead of "SSL: The operation completed successfully." Windows 2000 Professional SP4 Apache 2.2.11 PHP 5.2.11RC1-Win32-VC6-x86 (threadsafe binary from http://windows.php.net/qa/) configured as an Apache module with php_openssl.dll and libeay32.dll+ssleay.dll v0.9.8k Reproduce code: --- http://bugs.php.net/?id=49295&edit=1
#49447 [Opn->Asn]: php engine need to correctly check for socket API return status on windows
ID: 49447 Updated by: srina...@php.net Reported By: sriram dot natarajan at gmail dot com -Status: Open +Status: Assigned Bug Type: Sockets related Operating System: windows xp PHP Version: 5.3.0 -Assigned To: +Assigned To: srinatar Previous Comments: [2009-09-03 01:36:03] sriram dot natarajan at gmail dot com Description: Unlike bsd sockets, Win32 Socket API does not return -1 on failure for most of the common socket api calls like bind, accept, connect etc. in fact, the error status is another integer with numbers like 10035 etc. so, checking for returns status on these socket API's like -1 or <= 0 is wrong. i noticed this issue while debugging another problem on windows. hence, filing this bug to track this issue . checking for correct error status on these API is important during trouble shooting scenarios. -- Edit this bug report at http://bugs.php.net/?id=49447&edit=1
#49447 [Asn->Ana]: php engine need to correctly check for socket API return status on windows
ID: 49447
Updated by: srina...@php.net
Reported By: sriram dot natarajan at gmail dot com
-Status: Assigned
+Status: Analyzed
Bug Type: Sockets related
Operating System: windows xp
PHP Version: 5.3.0
Assigned To: srinatar
New Comment:
here is the patch to address this issue.
Index: ext/openssl/xp_ssl.c
===
--- ext/openssl/xp_ssl.c(revision 287975)
+++ ext/openssl/xp_ssl.c(working copy)
@@ -259,6 +259,10 @@
SSL_CTX_free(sslsock->ctx);
sslsock->ctx = NULL;
}
+#ifdef PHP_WIN32
+ if (sslsock->s.socket == -1)
+ sslsock->s.socket = SOCK_ERR;
+#endif
if (sslsock->s.socket != SOCK_ERR) {
#ifdef PHP_WIN32
/* prevent more data from coming in */
Index: ext/ftp/ftp.c
===
--- ext/ftp/ftp.c (revision 287975)
+++ ext/ftp/ftp.c (working copy)
@@ -147,7 +147,7 @@
size = sizeof(ftp->localaddr);
memset(&ftp->localaddr, 0, size);
- if (getsockname(ftp->fd, (struct sockaddr*) &ftp->localaddr, &size)
== -1) {
+ if (getsockname(ftp->fd, (struct sockaddr*) &ftp->localaddr, &size)
!= 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "getsockname
failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
@@ -1387,7 +1387,7 @@
sa = (struct sockaddr *) &ftp->localaddr;
/* bind/listen */
- if ((fd = socket(sa->sa_family, SOCK_STREAM, 0)) == -1) {
+ if ((fd = socket(sa->sa_family, SOCK_STREAM, 0)) == SOCK_ERR) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "socket() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
@@ -1420,17 +1420,17 @@
php_any_addr(sa->sa_family, &addr, 0);
size = php_sockaddr_size(&addr);
- if (bind(fd, (struct sockaddr*) &addr, size) == -1) {
+ if (bind(fd, (struct sockaddr*) &addr, size) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "bind() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
- if (getsockname(fd, (struct sockaddr*) &addr, &size) == -1) {
+ if (getsockname(fd, (struct sockaddr*) &addr, &size) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "getsockname()
failed:
%s (%d)", strerror(errno), errno);
goto bail;
}
- if (listen(fd, 5) == -1) {
+ if (listen(fd, 5) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "listen() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
Index: ext/sockets/sockets.c
===
--- ext/sockets/sockets.c (revision 287975)
+++ ext/sockets/sockets.c (working copy)
@@ -370,14 +370,14 @@
sock->type = PF_INET;
- if (bind(sock->bsd_socket, (struct sockaddr *)&la, sizeof(la)) < 0)
{
+ if (bind(sock->bsd_socket, (struct sockaddr *)&la, sizeof(la)) != 0)
{
PHP_SOCKET_ERROR(sock, "unable to bind to given address",
errno);
close(sock->bsd_socket);
efree(sock);
return 0;
}
- if (listen(sock->bsd_socket, backlog) < 0) {
+ if (listen(sock->bsd_socket, backlog) != 0) {
PHP_SOCKET_ERROR(sock, "unable to listen on socket", errno);
close(sock->bsd_socket);
efree(sock);
Index: main/network.c
===
--- main/network.c (revision 287975)
+++ main/network.c (working copy)
@@ -314,7 +314,7 @@
SET_SOCKET_BLOCKING_MODE(sockfd, orig_flags);
- if ((n = connect(sockfd, addr, addrlen)) < 0) {
+ if ((n = connect(sockfd, addr, addrlen)) != 0) {
error = php_socket_errno();
if (error_code) {
@@ -348,7 +348,7 @@
BSD-derived systems set errno correctly
Solaris returns -1 from getsockopt in case of error
*/
- if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, (char*)&error,
&len) <
0) {
+ if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, (char*)&error,
&len) !=
0) {
ret = -1;
}
} else {
@@ -375,7 +375,7 @@
if (asynchronous) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Asynchronous
connect()
not supported on this platform");
}
- return connec
#49447 [Asn->Csd]: php engine need to correctly check for socket API return status on windows
ID: 49447
Updated by: srina...@php.net
Reported By: sriram dot natarajan at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Sockets related
Operating System: win32 only - windows xp
PHP Version: 5.3.0
Assigned To: srinatar
New Comment:
This bug has been fixed in SVN.
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.
fix for this issue has been integrated
Previous Comments:
[2009-09-04 07:59:49] s...@php.net
Automatic comment from SVN on behalf of srinatar
Revision: http://svn.php.net/viewvc/?view=revision&revision=288034
Log: - Fixed bug #49447 (php engine need to correctly check for socket
API
return status on windows). (Sriram Natarajan)
[2009-09-03 01:39:46] srina...@php.net
here is the patch to address this issue.
Index: ext/openssl/xp_ssl.c
===
--- ext/openssl/xp_ssl.c(revision 287975)
+++ ext/openssl/xp_ssl.c(working copy)
@@ -259,6 +259,10 @@
SSL_CTX_free(sslsock->ctx);
sslsock->ctx = NULL;
}
+#ifdef PHP_WIN32
+ if (sslsock->s.socket == -1)
+ sslsock->s.socket = SOCK_ERR;
+#endif
if (sslsock->s.socket != SOCK_ERR) {
#ifdef PHP_WIN32
/* prevent more data from coming in */
Index: ext/ftp/ftp.c
===
--- ext/ftp/ftp.c (revision 287975)
+++ ext/ftp/ftp.c (working copy)
@@ -147,7 +147,7 @@
size = sizeof(ftp->localaddr);
memset(&ftp->localaddr, 0, size);
- if (getsockname(ftp->fd, (struct sockaddr*) &ftp->localaddr, &size)
== -1) {
+ if (getsockname(ftp->fd, (struct sockaddr*) &ftp->localaddr, &size)
!= 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "getsockname
failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
@@ -1387,7 +1387,7 @@
sa = (struct sockaddr *) &ftp->localaddr;
/* bind/listen */
- if ((fd = socket(sa->sa_family, SOCK_STREAM, 0)) == -1) {
+ if ((fd = socket(sa->sa_family, SOCK_STREAM, 0)) == SOCK_ERR) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "socket() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
@@ -1420,17 +1420,17 @@
php_any_addr(sa->sa_family, &addr, 0);
size = php_sockaddr_size(&addr);
- if (bind(fd, (struct sockaddr*) &addr, size) == -1) {
+ if (bind(fd, (struct sockaddr*) &addr, size) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "bind() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
- if (getsockname(fd, (struct sockaddr*) &addr, &size) == -1) {
+ if (getsockname(fd, (struct sockaddr*) &addr, &size) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "getsockname()
failed:
%s (%d)", strerror(errno), errno);
goto bail;
}
- if (listen(fd, 5) == -1) {
+ if (listen(fd, 5) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "listen() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
Index: ext/sockets/sockets.c
===
--- ext/sockets/sockets.c (revision 287975)
+++ ext/sockets/sockets.c (working copy)
@@ -370,14 +370,14 @@
sock->type = PF_INET;
- if (bind(sock->bsd_socket, (struct sockaddr *)&la, sizeof(la)) < 0)
{
+ if (bind(sock->bsd_socket, (struct sockaddr *)&la, sizeof(la)) != 0)
{
PHP_SOCKET_ERROR(sock, "unable to bind to given address",
errno);
close(sock->bsd_socket);
efree(sock);
return 0;
}
- if (listen(sock->bsd_socket, backlog) < 0) {
+ if (listen(sock->bsd_socket, backlog) != 0) {
PHP_SOCKET_ERROR(sock, "unable to listen on socket", errno);
close(sock->bsd_socket);
efree(sock);
Index: main/network.c
===
--- main/network.c (revision 287975)
+++ main/network.c (working copy)
@@ -314,7 +314,7 @@
SET_SOCKET_BLOCKING_MODE(sockfd, orig_flags);
- if ((n = connect(sockfd, addr, addrlen)) < 0) {
+
#47230 [NoF->Csd]: Bug with gcc Optimizer on Sparc systems
ID: 47230 Updated by: srina...@php.net Reported By: lneve at mail dot nih dot gov -Status: No Feedback +Status: Closed Bug Type: Reproducible crash Operating System: Solaris 10 (completely patched) PHP Version: 5.3.0-beta2-dev New Comment: This bug has been fixed in SVN. 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. this issue is not because of a bug with gcc in sparc. sparc requires memory accesses to be aligned. however, with php 5.3, zend stack was not aligned and this was causing php 5.3 to crash on sparc as well as on irix. this issue is now resolved with dmitry's commit as part of his fix for bug #46074. this below diff fixes this issue: http://svn.php.net/viewvc?view=revision&revision=287992 Previous Comments: [2009-07-29 21:28:00] lepage at grm dot polymtl dot ca not able to compile with sun studio to many dependance (libs) need to be recompile with sun studio. php5.3-200907282230 still has the same problem. [2009-07-16 00:45:49] lepage at grm dot polymtl dot ca URL for sun studio is http://developers.sun.com/sunstudio/ will try it or wait for 5.3.1, when is it scheduled ? [2009-07-15 08:05:37] sriram dot natarajan at gmail dot com hi please see related bug - http://bugs.php.net/bug.php?id=48668 . if you compile with sun studio 12 (which is available for free from http://www.sun.com/sunstudio , you should not have this problem. future releases of php 5.3 should address this issue [2009-07-14 22:22:03] lepage at grm dot polymtl dot ca same problem here with php-5.3.0. on Solaris 10 and gcc 4.3.2 [2009-05-05 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". 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/47230 -- Edit this bug report at http://bugs.php.net/?id=47230&edit=1
#48668 [Ctl->Csd]: foreach with array will coredump php
ID: 48668
Updated by: srina...@php.net
Reported By: dmda at yandex dot ru
-Status: Critical
+Status: Closed
Bug Type: Reproducible crash
Operating System: Solaris
PHP Version: 5.3.0RC4
Assigned To: dsp
New Comment:
This bug has been fixed in SVN.
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.
this issue is now resolved with dmitry's commit as part of his fix for
bug #46074.
this below diff fixes this issue:
http://svn.php.net/viewvc?view=revision&revision=287992
Previous Comments:
[2009-08-26 22:42:48] sriram dot natarajan at gmail dot com
Ok, I am back. thanks for suggesting this patches. However, I just
tried your patch and I found that it still crashes in my machine. I will
investigate it further and once I have a patch I will post it here.
[2009-08-18 20:47:38] dmda at yandex dot ru
to demonstrate how it works, I wrote some trivial examples:
1) bad coding practice or misligned memory operations that lead to Bus
Error:
#include "inttypes.h"
typedef struct {
int16_t i;
} s16;
typedef struct {
int32_t i;
} s32;
int main() {
char *c = (char*)malloc(sizeof(s16) + sizeof(s32));
s16* v1 = (void*)(c);
s32* v2 = (void*)((char*)v1 + sizeof(s16));
printf("&v1=%x\n", v1);
printf("&v2=%x\n", v2);
v2->i = 55;
printf("ok\n");
return 0;
}
you'll note that the address of v2 is not aligned to 32bit boundary and
therefore v2->i = 55 will crash:
$gcc a.c -o a
$./a
&v1=208e8
&v2=208ea
Bus Error (core dumped)
2) Fix with MEMORY ALIGNMENT
#include "inttypes.h"
typedef struct {
int16_t i;
} s16;
typedef struct {
int32_t i;
} s32;
#define ALIGNGRANUL 4
#define ALIGN(a) ((a + ALIGNGRANUL - 1) & ~(ALIGNGRANUL - 1))
int main() {
char *c = (char*)malloc(ALIGN(sizeof(s16)) + ALIGN(sizeof(s32)));
s16* v1 = (void*)(c);
s32* v2 = (void*)((char*)v1 + ALIGN(sizeof(s16)));
printf("&v1=%x\n", v1);
printf("&v2=%x\n", v2);
v2->i = 55;
printf("ok\n");
return 0;
}
you'll see that all addresses are properly aligned to 32bit boundary:
$gcc a.c -o a
$./a
&v1=208e8
&v2=208ec
ok
3) a better fix that does not need any knowledge about memory
alignment:
#include "inttypes.h"
typedef struct {
int16_t i;
} s16;
typedef struct {
int32_t i;
} s32;
typedef struct {
s16 v1;
s32 v2;
} ss;
int main() {
ss* v = malloc(sizeof(ss));
printf("&v1=%x\n", &v->v1);
printf("&v2=%x\n", &v->v2);
v->v2.i = 55;
printf("ok\n");
return 0;
}
you'll see that it works too:
$gcc a.c -o a
$./a
&v1=208e8
&v2=208ec
ok
so you see this is all around sizeof() :) while actually it's all about
memory alignment.
[2009-08-18 17:42:20] dmda at yandex dot ru
Dear sriram ,
Where did I say that the problem is in allocation size?
Once again, the problem is in the data alignment.
And fixing the code I mentioned, it fixes the Bus error.
diff -U5 ./php-5.3.0/Zend/zend_execute.h
./php-5.3.0D/Zend/zend_execute.h
--- ./php-5.3.0/Zend/zend_execute.h 2009-06-09 05:26:02.0
-0400
+++ ./php-5.3.0D/Zend/zend_execute.h2009-08-18 12:27:18.080008000
-0400
@@ -154,11 +154,11 @@
zend_vm_stack_extend((count) TSRMLS_CC);
\
}
\
} while (0)
static inline zend_vm_stack zend_vm_stack_new_page(int count) {
- zend_vm_stack page =
(zend_vm_stack)emalloc(sizeof(*page)+sizeof(page->elements[0])*(count-1));
+ zend_vm_stack page =
(zend_vm_stack)emalloc(ZEND_MM_ALIGNED_SIZE(sizeof(*page))+ZEND_MM_ALIGNED_SIZE(sizeof(page->elements[0]))*(count-1));
page->top = page->elements;
page->end = page->elements + count;
page->prev = NULL;
return page;
@@ -217,11 +217,11 @@
static inline void *zend_vm_stack_alloc(size_t size TSRMLS_DC)
{
void *ret;
- size = (size + (sizeof(void*) - 1)) / sizeof(void*);
+ size = (size + (ZEND_MM_ALIGNED_SIZE(sizeof(void*)) - 1)) /
ZEND_MM_ALIGNED_SIZE(sizeof(void*));
ZEND_VM_STACK_GROW_IF_NEEDED((int)size);
ret = (void*)EG(argument_stack)->top;
EG(argument_stack)->top += size;
return ret;
diff -U5 ./php-5.3.0/Zend/zend_opcode.c
./php-5.3.0D/Zend/zend_opcode.c
--- ./php-5.3.0/Zend/zend_opcode.c 2009-06-05 19:20:59.0 -0400
+++ ./php-5.3.0D/Zend/zend_opcode.c 2009-08-18 12:29:21.630007000
-0400
@@ -43,11 +43,11 @@
}
}
static void op_array_allo
#49295 [Asn]: stream_socket_client() fails on SSL+async
ID: 49295 Updated by: srina...@php.net Reported By: frase at cs dot wisc dot edu Status: Assigned Bug Type: OpenSSL related Operating System: Win 2000 Pro SP4 PHP Version: 5.2.11RC2 Assigned To: srinatar New Comment: as i mentioned to you last time, our openssl implementation is incorrectly using file based sockets instead of openssl provided 'BIO' for underlying communication. this will require re-implementation of some of php's openssl implementation. this should be an issue only on windows. Previous Comments: [2009-09-04 13:21:10] frase at cs dot wisc dot edu I'm sure this is expected, but the bug remains in 5.2.11RC2. I also noticed another clue: I mentioned previously that SSL+ASYNC works once (but not asynchronously) after starting Apache, and then fails and throws warnings. It turns out any SSL socket connection will cause future SSL+ASYNC attempts to do this, even if the first one was SYNC. So to get SSL+ASYNC to connect, it must be the very first SSL socket opened since Apache started. [2009-09-02 14:17:18] frase at cs dot wisc dot edu Commenting the stream_set_blocking() doesn't change anything for me on Windows. SSL+ASYNC still works exactly once (but doesn't actually connect asynchronously) and then gives the warnings; SSL+SYNC still works fine, as does TCP+ASYNC. Thanks for your work on this. I get complaints about it every week because if the remote server doesn't respond then our software gets stuck in the connection phase, and since the connection phase cannot be made asynchronous, the user is unable to abort it and just has to wait. [2009-09-02 08:38:01] srina...@php.net just a follow up note, this issue (async not working consistently with openssl on windows) has always been the case and this issue has nothing to do with the fix that went in for bug:48182. [2009-09-02 08:09:22] srina...@php.net ok, i was looking into this issue today. the issue is that , especially on windows -where sockets are not file descriptors unlike in unix, async sockets and openssl works together only if we use BIO wrappers provided by openssl module instead of directly accessing underlying sockets as file descriptors. the possible right way to do this would be to use to socket wrappers provided by SSL module (known as BIO wrappers which makes it work properly on windows). this will require some amount of fiddling our openssl module. i don't think, 5.2 is a good place to do this change. for now, commenting this below code should help you to run your script properly on windows. stream_set_blocking($socket, 0); i will spend more time on this and investigate on the best way to use BIO wrappers within existing openssl module say within php 5.3 [2009-08-21 15:05:47] frase at cs dot wisc dot edu I had a chance to compile and test PHP5.2.11RC1 under Linux this morning (Ubuntu Jaunty, Apache 2.2.11 from repositories), and these warnings do not appear, however I noticed another problem. Although the SSL+async connection is successful and data is returned under Linux, the socket is not actually opened asynchonously. The script blocks until the socket has finished opening, exactly as it does without the ASYNC flag. This is also true under Windows, for the first run -- after that, of course, it returns the errors posted above. 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/49295 -- Edit this bug report at http://bugs.php.net/?id=49295&edit=1
#49572 [Opn]: use of C++ style comments causes build failure
ID: 49572 Updated by: srina...@php.net Reported By: mamfelt at gmail dot com Status: Open Bug Type: Compile Failure Operating System: AIX 6.1 PHP Version: 5.2SVN-2009-09-16 (snap) New Comment: thanks for reporting this bug. this issue seems to be brought in with svn commit r280638 you can work around this issue - for now - by using -qcpluscmt within the CFLAGS export CFLAGS=-qcpluscmt ./configure ... gmake Previous Comments: [2009-09-16 17:15:22] mamfelt at gmail dot com Description: A C++ style comment in main/streams/memory.c causes a build failure. Reproduce code: --- in /php5.2-200909161430/main/streams/memory.c: self->innerstream = php_stream_memory_create_rel(mode); php_stream_auto_cleanup(self->innerstream); // do not warn if innerstream is GC'ed before stream ((php_stream_memory_data*)self->innerstream->abstract)->owner_ptr = &self->innerstream; Corrected as: self->innerstream = php_stream_memory_create_rel(mode); php_stream_auto_cleanup(self->innerstream); /* do not warn if innerstream is GC'ed before stream */ ((php_stream_memory_data*)self->innerstream->abstract)->owner_ptr = &self->innerstream; Expected result: A normal build Actual result: -- prj/php5.2-200909161430/main/streams/memory.c", line 566.53: 1506-046 (S) Syntax error. "/data/home/michael/prj/php5.2-200909161430/main/streams/memory.c", line 566.105: 1506-209 (S) Character constants must end before the end of a line. "/data/home/michael/prj/php5.2-200909161430/main/streams/memory.c", line 566.88: 1506-076 (W) Character constant 'ed before stream' has more than 4 characters. No more than rightmost 4 characters are used. -- Edit this bug report at http://bugs.php.net/?id=49572&edit=1
#49571 [Opn]: CURLOPT_POSTREDIR not implemented
ID: 49571 Updated by: srina...@php.net Reported By: info at pcxtra dot nl Status: Open Bug Type: Feature/Change Request Operating System: Windows XP PHP Version: 5.3.0 Assigned To: srinatar New Comment: I am not sure, i completely understand your issue here. when you post data to a server returning with 302, curl will by default return with GET requests (which is non-RFC compliant) as per HTTP/1.1 spec 10.3.3 in http://www.ietf.org/rfc/rfc2068.txt If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: When automatically redirecting a POST request after receiving a 302 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request. curl to provide backward compatibility will by default return with GET for post requests returning with 301/302 redirects. now, if you wanted to stop this behavior, and instead curl to be standards compliant ,then you need to set this CURL_POSTREDIR option. as you mentioned, this option makes sense only when used with CURLOPT_FOLLOWLOCATION. is this what you are looking for ? Previous Comments: [2009-09-16 13:54:26] info at pcxtra dot nl Description: I'd like to use the CURLOPT_POSTREDIR. When I try to POST data to a page it will return with 302 and CURL will redirect with POST. However I need to configure this to redirect with GET which can be configured with CURLOPT_POSTREDIR which is added in curl 7.19.1. (I'm using PHP 5.3 with Curl 7.19.4) I also tried curl_setopt($ch, 161 , 0); (also tried 1,2 and 3) in the hope it would still work, but it didn't. Reproduce code: --- By POSTing something to an URL which returns 302 and the following settings: curl_setopt($ch, CURLOPT_MAXREDIRS, 1); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); It will show with curl_getinfo: [request_header] => POST /Account/MyPortal.aspx HTTP/1.1 Expected result: I would have expected (and wanted) [request_header] => GET /Account/MyPortal.aspx HTTP/1.1 -- Edit this bug report at http://bugs.php.net/?id=49571&edit=1
#49572 [Asn->Csd]: use of C++ style comments causes build failure
ID: 49572 Updated by: srina...@php.net Reported By: mamfelt at gmail dot com -Status: Assigned +Status: Closed Bug Type: Compile Failure Operating System: AIX 6.1 PHP Version: 5.2SVN-2009-09-16 (snap) Assigned To: srinatar New Comment: This bug has been fixed in SVN. 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. ok, thanks. Previous Comments: [2009-09-17 02:45:25] s...@php.net Automatic comment from SVN on behalf of srinatar Revision: http://svn.php.net/viewvc/?view=revision&revision=288393 Log: - Fixed bug #49572 (use of C++ style comments causes build failure) [2009-09-16 18:56:05] paj...@php.net Can you simply commit the fix please? All affected branches? :-) [2009-09-16 18:50:13] srina...@php.net thanks for reporting this bug. this issue seems to be brought in with svn commit r280638 you can work around this issue - for now - by using -qcpluscmt within the CFLAGS export CFLAGS=-qcpluscmt ./configure ... gmake [2009-09-16 17:15:22] mamfelt at gmail dot com Description: A C++ style comment in main/streams/memory.c causes a build failure. Reproduce code: --- in /php5.2-200909161430/main/streams/memory.c: self->innerstream = php_stream_memory_create_rel(mode); php_stream_auto_cleanup(self->innerstream); // do not warn if innerstream is GC'ed before stream ((php_stream_memory_data*)self->innerstream->abstract)->owner_ptr = &self->innerstream; Corrected as: self->innerstream = php_stream_memory_create_rel(mode); php_stream_auto_cleanup(self->innerstream); /* do not warn if innerstream is GC'ed before stream */ ((php_stream_memory_data*)self->innerstream->abstract)->owner_ptr = &self->innerstream; Expected result: A normal build Actual result: -- prj/php5.2-200909161430/main/streams/memory.c", line 566.53: 1506-046 (S) Syntax error. "/data/home/michael/prj/php5.2-200909161430/main/streams/memory.c", line 566.105: 1506-209 (S) Character constants must end before the end of a line. "/data/home/michael/prj/php5.2-200909161430/main/streams/memory.c", line 566.88: 1506-076 (W) Character constant 'ed before stream' has more than 4 characters. No more than rightmost 4 characters are used. -- Edit this bug report at http://bugs.php.net/?id=49572&edit=1
#49571 [Opn->Fbk]: CURLOPT_POSTREDIR not implemented
ID: 49571 Updated by: srina...@php.net Reported By: info at pcxtra dot nl -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: Windows XP PHP Version: 5.3.0 Assigned To: srinatar Previous Comments: [2009-09-17 08:39:26] info at pcxtra dot nl Thanks for you response! You mentioned: when you post data to a server returning with 302, curl will by default return with GET requests (which is non-RFC compliant) I also had this understanding and expected that the curl behaviour is non RFC compliant by returning with a GET after a 302. However I did not experience this. In my case it returns with another POST (according to the request_header field returned by curl_getinfo() ) All I found then is to configure this behaviour with CURLOPT_POSTREDIR which doesn't seem to be supported. So in fact I'm looking to the curl default behaviour that is to redirect with a GET method after a POST. And then I don't need the option CURLOPT_POSTREDIR. Will you be able to duplicate or do I need to provide more details? [2009-09-17 02:11:10] srina...@php.net I am not sure, i completely understand your issue here. when you post data to a server returning with 302, curl will by default return with GET requests (which is non-RFC compliant) as per HTTP/1.1 spec 10.3.3 in http://www.ietf.org/rfc/rfc2068.txt If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. Note: When automatically redirecting a POST request after receiving a 302 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request. curl to provide backward compatibility will by default return with GET for post requests returning with 301/302 redirects. now, if you wanted to stop this behavior, and instead curl to be standards compliant ,then you need to set this CURL_POSTREDIR option. as you mentioned, this option makes sense only when used with CURLOPT_FOLLOWLOCATION. is this what you are looking for ? [2009-09-16 13:54:26] info at pcxtra dot nl Description: I'd like to use the CURLOPT_POSTREDIR. When I try to POST data to a page it will return with 302 and CURL will redirect with POST. However I need to configure this to redirect with GET which can be configured with CURLOPT_POSTREDIR which is added in curl 7.19.1. (I'm using PHP 5.3 with Curl 7.19.4) I also tried curl_setopt($ch, 161 , 0); (also tried 1,2 and 3) in the hope it would still work, but it didn't. Reproduce code: --- By POSTing something to an URL which returns 302 and the following settings: curl_setopt($ch, CURLOPT_MAXREDIRS, 1); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); It will show with curl_getinfo: [request_header] => POST /Account/MyPortal.aspx HTTP/1.1 Expected result: I would have expected (and wanted) [request_header] => GET /Account/MyPortal.aspx HTTP/1.1 -- Edit this bug report at http://bugs.php.net/?id=49571&edit=1
#49571 [Fbk]: CURLOPT_POSTREDIR not implemented
ID: 49571
Updated by: srina...@php.net
Reported By: info at pcxtra dot nl
Status: Feedback
Bug Type: Feature/Change Request
Operating System: Windows XP
PHP Version: 5.3.0
Assigned To: srinatar
New Comment:
hi
hmm.. when i commented this below line in your example
/*
curl_setopt( $ch, CURLOPT_CUSTOMREQUEST, "POST");
*/
i was able to get curl to send a 'GET' request after post returning a
redirect.
127.0.0.1 - - [23/Sep/2009:16:25:51 -0700] "POST /curl.php?redir=true
HTTP/1.1" 302 50
127.0.0.1 - - [23/Sep/2009:16:25:51 -0700] "GET /curl.php?start=true
HTTP/1.1" 200 1323
127.0.0.1 - - [23/Sep/2009:16:25:51 -0700] "GET /curl.php?target=true
HTTP/1.1" 200 4
similarly, when i changed the redirect to 302, i was also able to get
curl to issue a 'get' request after a redirect.
127.0.0.1 - - [23/Sep/2009:16:25:13 -0700] "POST /curl.php?redir=true
HTTP/1.1" 301 50
127.0.0.1 - - [23/Sep/2009:16:25:13 -0700] "GET /curl.php?target=true
HTTP/1.1" 200 4
127.0.0.1 - - [23/Sep/2009:16:25:13 -0700] "GET /curl.php?start=true
HTTP/1.1" 200 1333
now, here is a simple patch against 5.3, which allows you to do
curl_setopt( $ch, CURLOPT_POSTREDIR, 3 ) and which forces curl to issue
POST (or same request) after seeing a redirect.
Index: ext/curl/interface.c
===
--- ext/curl/interface.c(revision 288624)
+++ ext/curl/interface.c(working copy)
@@ -747,8 +747,10 @@
REGISTER_CURL_CONSTANT(CURLFTPSSL_CONTROL);
REGISTER_CURL_CONSTANT(CURLFTPSSL_ALL);
#endif
+
#if LIBCURL_VERSION_NUM > 0x071301
REGISTER_CURL_CONSTANT(CURLOPT_CERTINFO);
+ REGISTER_CURL_CONSTANT(CURLOPT_POSTREDIR);
#endif
/* SSH support works in 7.19.0+ using libssh2 */
@@ -1669,6 +1671,12 @@
}
error = curl_easy_setopt(ch->cp, option,
Z_LVAL_PP(zvalue));
break;
+#if LIBCURL_VERSION_NUM > 0x071301
+ case CURLOPT_POSTREDIR:
+ convert_to_long_ex(zvalue);
+ error = curl_easy_setopt(ch->cp,
CURLOPT_POSTREDIR, Z_LVAL_PP(zvalue) & CURL_REDIR_POST_ALL);
+ break;
+#endif
case CURLOPT_PRIVATE:
case CURLOPT_URL:
case CURLOPT_PROXY:
Previous Comments:
[2009-09-18 14:59:19] info at pcxtra dot nl
I made a copy/paste failure...
instead of: Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I
get [request_header] => POST /curl.php?redir=true HTTP/1.1 while I
would expect the GET method.
it should be: Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I
get [request_header] => POST /dev/impeng/curl.php?target=true HTTP/1.1
while I would expect the GET method.
[2009-09-18 14:51:08] info at pcxtra dot nl
I've completed a full running test. Please save it as curl.php and
start it with curl.php?start=true. The idea is that it will do a POST to
curl.php?redir=true. This page will response with 302 and redirect to
curl.php?target=true. Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I
get [request_header] => POST /curl.php?redir=true HTTP/1.1 while I would
expect the GET method.
http://";. $_SERVER["SERVER_NAME"] . $_SERVER["SCRIPT_NAME"];
if( isset($_GET["redir"]) )
header("Location: ".$me."?target=true",TRUE,302);
if( isset($_GET["target"]) ) {
echo "done";
exit();
}
if( isset($_GET["start"]) ) {
$ch = curl_init( $me . "?redir=true");
curl_setopt( $ch, CURLINFO_HEADER_OUT, 1 );
curl_setopt( $ch, CURLOPT_HEADER, 1 );
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );
curl_setopt( $ch, CURLOPT_CUSTOMREQUEST, "POST");
curl_setopt( $ch, CURLOPT_POST, 1 );
curl_setopt( $ch, CURLOPT_POSTFIELDS, "data=somedata");
curl_setopt($ch, CURLOPT_MAXREDIRS, 1 );
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
$content = curl_exec( $ch );
echo '' . htmlspecialchars(
print_r(curl_getinfo( $ch ), true) ). '';
echo '' . htmlspecialchars(
$content ). '';
}
echo "usage: ".$me."?start=true";
?>
[2009-09-17 08:39:26] info at pcxtra dot nl
Thanks for you response!
You mentioned: when you post data to a server returning with 302, curl
will by default return with GET requests (which is non-RFC compliant)
I also had this understanding and expected that the curl behaviour is
non RFC compliant by returning with a GET after a 30
#49098 [Opn]: Using custom session handler causes segfault in session_save_state
ID: 49098
Updated by: srina...@php.net
Reported By: bugs at timj dot co dot uk
Status: Open
Bug Type: Session related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
i do have a wordpress running with php 5.2.11 for my site and i don't
have any issues. if you do notice with the latest php build, if you can
provide a test case to reproduce this bug that would be useful.
as i noted earlier, i was not able to reproduce this bug with the
provided test case here.
Previous Comments:
[2009-09-18 19:43:06] ulf at ladb dot unm dot edu
Hi,
Is this bug still under investigation? Just wondering because 5.2.9 is
the last version of PHP that works with Wordpress/MySQL without crashing
Apache.
Thanks.
[2009-09-16 18:19:08] sriram dot natarajan at gmail dot com
i just took the latest php snapshot from http://snaps.php.net and tried
it out. if you notice, my script is just a completion of your script - i
just filled in some missing pieces in your script - like creating the
table etc .
i am also using mysql 5.1.30
[2009-09-16 06:01:10] t...@php.net
sriram:
a) can you specify exactly which snapshot you use so that I can
confirm/deny what you say
b) did you try my test script? what does that do? why did you make up a
new one?
[2009-09-16 02:26:55] sriram dot natarajan at gmail dot com
i just tried a simple php with mdb2/http_session2 with the latest php
snapshot and was not able to reproduce this issue. is there some thing
else required to reproduce this issue ?
here is the simple script that i had to try it out
loadModule('Manager');
$mdb2->loadModule('Extended');
$db = $mdb2->connect($dsn);
$table_fields = array
(
'id' => array(
'type' => 'text',
'length' => '32'),
'data' => array(
'type' => 'text',
'length' => '32'),
'skey' => array(
'type' => 'text',
'length' => '32'),
'expiry' => array(
'type' => 'integer',
'notnull' => 1,
'unsigned' => 0),
);
$table_constraints = array(
'primary' => true,
'fields' => array (
'id' => array()),
);
$s = $mdb2->createTable('session_data', $table_fields);
if (PEAR::isError($s)) {
die($s->getMessage() . ', ' . $s->getDebugInfo());
}
$mdb2->createConstraint('session_data',
'primary_key',$table_constraints);
$mdb2->createSequence('primary_key');
$options = array();
$options['dsn'] = $dsn;
$options['table'] = 'session_data';
HTTP_Session2::setContainer('MDB2', $options);
HTTP_Session2::start('MySESS');
HTTP_Session2::set('variable', 'The string');
?>
[2009-09-04 11:30:40] t...@php.net
Further info: the crash does NOT occur if the DSN string is changed to
"mysql://..." instead of "mysqli://..." (this also seemed to be the case
in similar bug #48922)
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/49098
--
Edit this bug report at http://bugs.php.net/?id=49098&edit=1
#49571 [Fbk->Tbd]: CURLOPT_POSTREDIR not implemented
ID: 49571
Updated by: srina...@php.net
Reported By: info at pcxtra dot nl
-Status: Feedback
+Status: To be documented
Bug Type: Feature/Change Request
Operating System: Windows XP
PHP Version: 5.3.0
Assigned To: srinatar
New Comment:
following needs to be documented
Whenever there is a redirect request (either 301 or 302) , curl
(against HTTP/1.1 spec) always follows with a GET request. However, if
your applications wants compliance with HTTP/1.1 spec, and be able to
issue a POST request after a POST redirect, user can use
curl_setopt( , CURLOPT_POSTREDIR, 3);
here 3 tells curl module to redirect both 301 as well as 302 requests.
0,1,2,3 are the valid options for the last argument.
0 -> do not set any behavior
1 -> follow redirect with the same type of request only for 301
redirects.
2 -> follow redirect with the same type of request only for 302
redirects.
3 -> follow redirect with the same type of request both for 301 and 302
redirects.
for example, if users wants the ability to redirect only for 301
requests, then they could use
curl_setopt( , CURLOPT_POSTREDIR, 1);
Previous Comments:
[2009-09-24 18:20:50] s...@php.net
Automatic comment from SVN on behalf of srinatar
Revision: http://svn.php.net/viewvc/?view=revision&revision=288677
Log: - Fixed bug #49571 (CURLOPT_POSTREDIR not implemented).
[2009-09-23 23:31:05] srina...@php.net
hi
hmm.. when i commented this below line in your example
/*
curl_setopt( $ch, CURLOPT_CUSTOMREQUEST, "POST");
*/
i was able to get curl to send a 'GET' request after post returning a
redirect.
127.0.0.1 - - [23/Sep/2009:16:25:51 -0700] "POST /curl.php?redir=true
HTTP/1.1" 302 50
127.0.0.1 - - [23/Sep/2009:16:25:51 -0700] "GET /curl.php?start=true
HTTP/1.1" 200 1323
127.0.0.1 - - [23/Sep/2009:16:25:51 -0700] "GET /curl.php?target=true
HTTP/1.1" 200 4
similarly, when i changed the redirect to 302, i was also able to get
curl to issue a 'get' request after a redirect.
127.0.0.1 - - [23/Sep/2009:16:25:13 -0700] "POST /curl.php?redir=true
HTTP/1.1" 301 50
127.0.0.1 - - [23/Sep/2009:16:25:13 -0700] "GET /curl.php?target=true
HTTP/1.1" 200 4
127.0.0.1 - - [23/Sep/2009:16:25:13 -0700] "GET /curl.php?start=true
HTTP/1.1" 200 1333
now, here is a simple patch against 5.3, which allows you to do
curl_setopt( $ch, CURLOPT_POSTREDIR, 3 ) and which forces curl to issue
POST (or same request) after seeing a redirect.
Index: ext/curl/interface.c
===
--- ext/curl/interface.c(revision 288624)
+++ ext/curl/interface.c(working copy)
@@ -747,8 +747,10 @@
REGISTER_CURL_CONSTANT(CURLFTPSSL_CONTROL);
REGISTER_CURL_CONSTANT(CURLFTPSSL_ALL);
#endif
+
#if LIBCURL_VERSION_NUM > 0x071301
REGISTER_CURL_CONSTANT(CURLOPT_CERTINFO);
+ REGISTER_CURL_CONSTANT(CURLOPT_POSTREDIR);
#endif
/* SSH support works in 7.19.0+ using libssh2 */
@@ -1669,6 +1671,12 @@
}
error = curl_easy_setopt(ch->cp, option,
Z_LVAL_PP(zvalue));
break;
+#if LIBCURL_VERSION_NUM > 0x071301
+ case CURLOPT_POSTREDIR:
+ convert_to_long_ex(zvalue);
+ error = curl_easy_setopt(ch->cp,
CURLOPT_POSTREDIR, Z_LVAL_PP(zvalue) & CURL_REDIR_POST_ALL);
+ break;
+#endif
case CURLOPT_PRIVATE:
case CURLOPT_URL:
case CURLOPT_PROXY:
[2009-09-18 14:59:19] info at pcxtra dot nl
I made a copy/paste failure...
instead of: Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I
get [request_header] => POST /curl.php?redir=true HTTP/1.1 while I
would expect the GET method.
it should be: Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I
get [request_header] => POST /dev/impeng/curl.php?target=true HTTP/1.1
while I would expect the GET method.
[2009-09-18 14:51:08] info at pcxtra dot nl
I've completed a full running test. Please save it as curl.php and
start it with curl.php?start=true. The idea is that it will do a POST to
curl.php?redir=true. This page will response with 302 and redirect to
curl.php?target=true. Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I
get [request_header] => POST /curl.php?redir=true HTTP/1.1 while I would
expect the GET method.
http://";. $_SERVER["SERVER_NAME"] . $_SERVER["SCRIPT_NAME"];
if( isset($_GET["redir"]) )
header("Location: ".$me."?
#49571 [Tbd]: CURLOPT_POSTREDIR not implemented
ID: 49571 Updated by: srina...@php.net Reported By: info at pcxtra dot nl Status: To be documented Bug Type: Feature/Change Request Operating System: Windows XP PHP Version: 5.3.0 -Assigned To: +Assigned To: srinatar New Comment: docs comments already provided. Previous Comments: [2009-09-24 18:28:30] srina...@php.net following needs to be documented Whenever there is a redirect request (either 301 or 302) , curl (against HTTP/1.1 spec) always follows with a GET request. However, if your applications wants compliance with HTTP/1.1 spec, and be able to issue a POST request after a POST redirect, user can use curl_setopt( , CURLOPT_POSTREDIR, 3); here 3 tells curl module to redirect both 301 as well as 302 requests. 0,1,2,3 are the valid options for the last argument. 0 -> do not set any behavior 1 -> follow redirect with the same type of request only for 301 redirects. 2 -> follow redirect with the same type of request only for 302 redirects. 3 -> follow redirect with the same type of request both for 301 and 302 redirects. for example, if users wants the ability to redirect only for 301 requests, then they could use curl_setopt( , CURLOPT_POSTREDIR, 1); [2009-09-24 18:20:50] s...@php.net Automatic comment from SVN on behalf of srinatar Revision: http://svn.php.net/viewvc/?view=revision&revision=288677 Log: - Fixed bug #49571 (CURLOPT_POSTREDIR not implemented). [2009-09-23 23:31:05] srina...@php.net hi hmm.. when i commented this below line in your example /* curl_setopt( $ch, CURLOPT_CUSTOMREQUEST, "POST"); */ i was able to get curl to send a 'GET' request after post returning a redirect. 127.0.0.1 - - [23/Sep/2009:16:25:51 -0700] "POST /curl.php?redir=true HTTP/1.1" 302 50 127.0.0.1 - - [23/Sep/2009:16:25:51 -0700] "GET /curl.php?start=true HTTP/1.1" 200 1323 127.0.0.1 - - [23/Sep/2009:16:25:51 -0700] "GET /curl.php?target=true HTTP/1.1" 200 4 similarly, when i changed the redirect to 302, i was also able to get curl to issue a 'get' request after a redirect. 127.0.0.1 - - [23/Sep/2009:16:25:13 -0700] "POST /curl.php?redir=true HTTP/1.1" 301 50 127.0.0.1 - - [23/Sep/2009:16:25:13 -0700] "GET /curl.php?target=true HTTP/1.1" 200 4 127.0.0.1 - - [23/Sep/2009:16:25:13 -0700] "GET /curl.php?start=true HTTP/1.1" 200 1333 now, here is a simple patch against 5.3, which allows you to do curl_setopt( $ch, CURLOPT_POSTREDIR, 3 ) and which forces curl to issue POST (or same request) after seeing a redirect. Index: ext/curl/interface.c === --- ext/curl/interface.c(revision 288624) +++ ext/curl/interface.c(working copy) @@ -747,8 +747,10 @@ REGISTER_CURL_CONSTANT(CURLFTPSSL_CONTROL); REGISTER_CURL_CONSTANT(CURLFTPSSL_ALL); #endif + #if LIBCURL_VERSION_NUM > 0x071301 REGISTER_CURL_CONSTANT(CURLOPT_CERTINFO); + REGISTER_CURL_CONSTANT(CURLOPT_POSTREDIR); #endif /* SSH support works in 7.19.0+ using libssh2 */ @@ -1669,6 +1671,12 @@ } error = curl_easy_setopt(ch->cp, option, Z_LVAL_PP(zvalue)); break; +#if LIBCURL_VERSION_NUM > 0x071301 + case CURLOPT_POSTREDIR: + convert_to_long_ex(zvalue); + error = curl_easy_setopt(ch->cp, CURLOPT_POSTREDIR, Z_LVAL_PP(zvalue) & CURL_REDIR_POST_ALL); + break; +#endif case CURLOPT_PRIVATE: case CURLOPT_URL: case CURLOPT_PROXY: [2009-09-18 14:59:19] info at pcxtra dot nl I made a copy/paste failure... instead of: Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I get [request_header] => POST /curl.php?redir=true HTTP/1.1 while I would expect the GET method. it should be: Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I get [request_header] => POST /dev/impeng/curl.php?target=true HTTP/1.1 while I would expect the GET method. [2009-09-18 14:51:08] info at pcxtra dot nl I've completed a full running test. Please save it as curl.php and start it with curl.php?start=true. The idea is that it will do a POST to curl.php?redir=true. This page will response with 302 and redirect to curl.php?target=true. Now with CURLOPT_FOLLOWLOCATION=1 it goes wrong. I get [request_header] => POST /curl.php?redir=true HTTP/1.1 while I would expect the GET method. http://";. $_SERVER["S
#47204 [Opn]: Missing support for CURLOPT_IOCTLFUNCTION
ID: 47204
Updated by: srina...@php.net
Reported By: a...@php.net
Status: Open
Bug Type: Feature/Change Request
Operating System: Irrelevant
-PHP Version: 5.2.8
+PHP Version: 5.3
-Assigned To:
+Assigned To: srinatar
New Comment:
since, this is a feature, this will probably apply only for 5.3
onwards.
Previous Comments:
[2009-09-20 17:31:31] j...@php.net
Recategorized, this is not a bug.
[2009-09-20 08:47:21] a...@php.net
Marking this as "cURL related" to increase visibility.
[2009-06-22 16:04:07] felix-php at 7val dot com
This problem not only occurs when negotiating HTTP Auth. It's much
easier to provoke by posting to a URL that answers with a redirect.
Any valid HTTP redirect (be it 302, 303 or 307) lets curl rewind its
request body before following the Location header. Thus
CURLOPT_READFUNCTION is pretty useless for accessing web servers in
the wild. Therefore I think it's rather a bug than a feature.
Reproduce:
Both examples above with an extra
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
and a URL answering with a redirect.
(Tested with PHP 5.2.9 and curl 7.19.5)
Proposal:
Instead of adding CURLOPT_IOCTLFUNCTION to the PHP extension, this bug
could be fixed by adding the CURLTOP_SEEKFUNCTION functionality. If
set, curl uses this to rewind the body, too (see Curl_readrewind() in
transfer.c). But the seek_func callback is also used for resuming
uploads which might be a nice side effect.
[2009-01-23 23:39:02] a...@php.net
The same problem without PHP callback, using CURLOPT_READDATA to read
request body from a file:
http://www.example.com/digest/');
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
curl_setopt($ch, CURLOPT_USERPWD, 'user:password');
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Length: ' .
filesize('./postdata')));
curl_setopt($ch, CURLOPT_READDATA, fopen('./postdata', 'rb'));
if (!curl_exec($ch)) {
echo 'Error #' . curl_errno($ch) . ': ' . curl_error($ch);
}
?>
This also prints "Error #65: necessary data rewind wasn't possible"
[2009-01-23 23:28:24] a...@php.net
Description:
PHP's cURL extension allows using a callback for reading the request
body via CURLOPT_READFUNCTION, but it doesn't provide a way to set a
CURLOPT_IOCTLFUNCTION callback for rewinding the request body.
This rewinding may be needed when doing a POST or PUT HTTP request to
resource protected by Digest authentication.
Reproduce code:
---
= strlen($data)) {
return '';
}
$string = substr($data, $position, $length);
$position += strlen($string);
return $string;
}
$ch = curl_init();
curl_setopt($ch, CURLOPT_POST, true);
// This should be some URL protected by HTTP digest auth!
curl_setopt($ch, CURLOPT_URL, 'http://www.example.com/digest/');
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
curl_setopt($ch, CURLOPT_USERPWD, 'user:password');
curl_setopt($ch, CURLOPT_READFUNCTION, 'read_callback');
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Length: ' .
strlen($data)));
if (!curl_exec($ch)) {
echo 'Error #' . curl_errno($ch) . ': ' . curl_error($ch);
}
?>
Expected result:
Request should proceed.
Actual result:
--
Error #65: necessary data rewind wasn't possible
--
Edit this bug report at http://bugs.php.net/?id=47204&edit=1
#41631 [Asn]: default_socket_timeout does not work with SSL
ID: 41631 Updated by: srina...@php.net Reported By: david at acz dot org Status: Assigned Bug Type: OpenSSL related Operating System: * -PHP Version: 5.2.6 +PHP Version: 5.2.11 Assigned To: pajoye New Comment: bug #48524 depends on this fix (http://bugs.php.net/bug.php?id=48524&edit=1) i wish , bug tracking system allowed to be able to close a bug as duplicate of another. then, we could close 48524 as dup of this (41631). this can also trigger the internal score for this bug to be increased (helping in set priority etc). Previous Comments: [2009-09-18 10:10:02] marcin at php4u dot co dot uk Still can reproduce on Windows XP SP3, PHP 5.2.6 while connecting to https, script doesn't time out [2009-07-22 03:24:17] vergara_rh at yahoo dot com I would greatly appreciate if this bug will be fix. [2009-07-02 15:34:54] karl dot debisschop at pearson dot com Just to keep information flowing, I have also tested with windows 5.3.0 and the issue is still present. [2009-06-24 15:58:08] paj...@php.net stupid auto no feedback, re assigned. [2009-06-24 15:55:15] karl dot debisschop at pearson dot com Downloaded PHP-2.x-win latest (5.2.11-dev) and confirmed that the issue is still present. 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/41631 -- Edit this bug report at http://bugs.php.net/?id=41631&edit=1
#49098 [Opn->Fbk]: Using custom session handler causes segfault in session_save_state
ID: 49098
Updated by: srina...@php.net
Reported By: bugs at timj dot co dot uk
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Linux
PHP Version: 5.2.10
New Comment:
unable to reproduce with the earlier provided test case. so, need more
information to reproduce / investigate this bug . also, would be useful
to know if this still happens with either 5.2.11 (or latest svn
snapshot)
Previous Comments:
[2009-09-24 17:48:47] srina...@php.net
i do have a wordpress running with php 5.2.11 for my site and i don't
have any issues. if you do notice with the latest php build, if you can
provide a test case to reproduce this bug that would be useful.
as i noted earlier, i was not able to reproduce this bug with the
provided test case here.
[2009-09-18 19:43:06] ulf at ladb dot unm dot edu
Hi,
Is this bug still under investigation? Just wondering because 5.2.9 is
the last version of PHP that works with Wordpress/MySQL without crashing
Apache.
Thanks.
[2009-09-16 18:19:08] sriram dot natarajan at gmail dot com
i just took the latest php snapshot from http://snaps.php.net and tried
it out. if you notice, my script is just a completion of your script - i
just filled in some missing pieces in your script - like creating the
table etc .
i am also using mysql 5.1.30
[2009-09-16 06:01:10] t...@php.net
sriram:
a) can you specify exactly which snapshot you use so that I can
confirm/deny what you say
b) did you try my test script? what does that do? why did you make up a
new one?
[2009-09-16 02:26:55] sriram dot natarajan at gmail dot com
i just tried a simple php with mdb2/http_session2 with the latest php
snapshot and was not able to reproduce this issue. is there some thing
else required to reproduce this issue ?
here is the simple script that i had to try it out
loadModule('Manager');
$mdb2->loadModule('Extended');
$db = $mdb2->connect($dsn);
$table_fields = array
(
'id' => array(
'type' => 'text',
'length' => '32'),
'data' => array(
'type' => 'text',
'length' => '32'),
'skey' => array(
'type' => 'text',
'length' => '32'),
'expiry' => array(
'type' => 'integer',
'notnull' => 1,
'unsigned' => 0),
);
$table_constraints = array(
'primary' => true,
'fields' => array (
'id' => array()),
);
$s = $mdb2->createTable('session_data', $table_fields);
if (PEAR::isError($s)) {
die($s->getMessage() . ', ' . $s->getDebugInfo());
}
$mdb2->createConstraint('session_data',
'primary_key',$table_constraints);
$mdb2->createSequence('primary_key');
$options = array();
$options['dsn'] = $dsn;
$options['table'] = 'session_data';
HTTP_Session2::setContainer('MDB2', $options);
HTTP_Session2::start('MySESS');
HTTP_Session2::set('variable', 'The string');
?>
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/49098
--
Edit this bug report at http://bugs.php.net/?id=49098&edit=1
#49738 [Fbk->Opn]: calling mcrypt after mcrypt_generic_deinit crashes
ID: 49738
Updated by: srina...@php.net
Reported By: terrafr...@php.net
-Status: Feedback
+Status: Open
Bug Type: mcrypt related
Operating System: Windows XP
PHP Version: 5.2.11
New Comment:
thanks for reporting this issue.
i was able to reproduce this and here is the back trace
current thread: t...@1
[1] permute_ip(0x8c6fa70, 0x0, 0x8046588, 0xfeeec5ea), at 0xfeeeca3e
[2] des_LTX__mcrypt_encrypt(0x0, 0x8c6fa70, 0x0, 0xfeef00b2), at
0xfeeec603
[3] ecb_LTX__mcrypt(0x0, 0x8c6fa70, 0x8, 0x8, 0x0, 0xfeeec5dc,
0xfeeec7dc, 0xfeee6732), at 0xfeef0153
[4] mcrypt(0x8dfcd20, 0x0, 0x8c6fa70, 0x8, 0x8046678), at 0xfeee676f
=>[5] mcrypt_generic(0x8dfcd20, 0x8c6fa70, 0x8), at 0xfeee50a0
[6] zif_mcrypt_generic(ht = 2, return_value = 0x8c6f938,
return_value_ptr = (nil), this_ptr = (nil), return_value_used = 1), line
682 in "mcrypt.c"
[7] zend_do_fcall_common_helper_SPEC(execute_data = 0x8dfcf60), line
313 in "zend_vm_execute.h"
[8] ZEND_DO_FCALL_SPEC_CONST_HANDLER(execute_data = 0x8dfcf60), line
1602 in "zend_vm_execute.h"
[9] execute(op_array = 0x8c6f098), line 104 in "zend_vm_execute.h"
[10] zend_execute_scripts(type = 8, retval = (nil), file_count = 3,
... = (nil), ...), line 1188 in "zend.c"
[11] php_execute_script(primary_file = 0x8047140), line 2214 in
"main.c"
[12] main(argc = 2, argv = 0x80471bc), line 1190 in "php_cli.c"
here is why this issue is happening
when mcrypt_generic_deinit is invoked , we should set init = 0 so that
next request of mcrypt_generic will force user to invoke generic_init
again.
here is a patch that can address this bug
[srir...@sriramn]'PHP_5_3'>svn diff
Index: ext/mcrypt/mcrypt.c
===
--- ext/mcrypt/mcrypt.c (revision 289068)
+++ ext/mcrypt/mcrypt.c (working copy)
@@ -780,6 +780,7 @@
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Could not
terminate encryption specifier");
RETURN_FALSE
}
+ pm->init = 0;
RETURN_TRUE
}
/* }}} */
Previous Comments:
[2009-10-01 16:19:25] j...@php.net
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.
[2009-10-01 16:17:10] terrafr...@php.net
Description:
In bug # 41252, it was observed that, in PHP4, calling mcrypt_generic()
before calling mcrypt_module_open() would cause PHP4 to crash. PHP5
apparently had extra checks to protect against this that were
backported. These extra checks, however, do not appear to be
sufficient, as the following reproduce code demonstrates.
Sure, calling mcrypt_generic_deinit() before calling mcrypt_generic is
probably not something you ought to be doing, anyway, but I still don't
think it ought to crash PHP.
Reproduce code:
---
Expected result:
Warning: mcrypt_generic(): Operation disallowed prior to
mcrypt_generic_init() in {filename} on line 5
Actual result:
--
It crashes.
--
Edit this bug report at http://bugs.php.net/?id=49738&edit=1
#49738 [Opn->Csd]: calling mcrypt after mcrypt_generic_deinit crashes
ID: 49738
Updated by: srina...@php.net
Reported By: terrafr...@php.net
-Status: Open
+Status: Closed
Bug Type: mcrypt related
Operating System: Windows XP
PHP Version: 5.2.11
Assigned To: srinatar
New Comment:
This bug has been fixed in SVN.
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.
Previous Comments:
[2009-10-02 00:13:53] s...@php.net
Automatic comment from SVN on behalf of srinatar
Revision: http://svn.php.net/viewvc/?view=revision&revision=289076
Log: - Fixed bug #49738 (calling mcrypt after mcrypt_generic_deinit
crashes).
[2009-10-01 19:58:21] srina...@php.net
thanks for reporting this issue.
i was able to reproduce this and here is the back trace
current thread: t...@1
[1] permute_ip(0x8c6fa70, 0x0, 0x8046588, 0xfeeec5ea), at 0xfeeeca3e
[2] des_LTX__mcrypt_encrypt(0x0, 0x8c6fa70, 0x0, 0xfeef00b2), at
0xfeeec603
[3] ecb_LTX__mcrypt(0x0, 0x8c6fa70, 0x8, 0x8, 0x0, 0xfeeec5dc,
0xfeeec7dc, 0xfeee6732), at 0xfeef0153
[4] mcrypt(0x8dfcd20, 0x0, 0x8c6fa70, 0x8, 0x8046678), at 0xfeee676f
=>[5] mcrypt_generic(0x8dfcd20, 0x8c6fa70, 0x8), at 0xfeee50a0
[6] zif_mcrypt_generic(ht = 2, return_value = 0x8c6f938,
return_value_ptr = (nil), this_ptr = (nil), return_value_used = 1), line
682 in "mcrypt.c"
[7] zend_do_fcall_common_helper_SPEC(execute_data = 0x8dfcf60), line
313 in "zend_vm_execute.h"
[8] ZEND_DO_FCALL_SPEC_CONST_HANDLER(execute_data = 0x8dfcf60), line
1602 in "zend_vm_execute.h"
[9] execute(op_array = 0x8c6f098), line 104 in "zend_vm_execute.h"
[10] zend_execute_scripts(type = 8, retval = (nil), file_count = 3,
... = (nil), ...), line 1188 in "zend.c"
[11] php_execute_script(primary_file = 0x8047140), line 2214 in
"main.c"
[12] main(argc = 2, argv = 0x80471bc), line 1190 in "php_cli.c"
here is why this issue is happening
when mcrypt_generic_deinit is invoked , we should set init = 0 so that
next request of mcrypt_generic will force user to invoke generic_init
again.
here is a patch that can address this bug
[srir...@sriramn]'PHP_5_3'>svn diff
Index: ext/mcrypt/mcrypt.c
===
--- ext/mcrypt/mcrypt.c (revision 289068)
+++ ext/mcrypt/mcrypt.c (working copy)
@@ -780,6 +780,7 @@
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Could not
terminate encryption specifier");
RETURN_FALSE
}
+ pm->init = 0;
RETURN_TRUE
}
/* }}} */
[2009-10-01 16:19:25] j...@php.net
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.
[2009-10-01 16:17:10] terrafr...@php.net
Description:
In bug # 41252, it was observed that, in PHP4, calling mcrypt_generic()
before calling mcrypt_module_open() would cause PHP4 to crash. PHP5
apparently had extra checks to protect against this that were
backported. These extra checks, however, do not appear to be
sufficient, as the following reproduce code demonstrates.
Sure, calling mcrypt_generic_deinit() before calling mcrypt_generic is
probably not something you ought to be doing, anyway, but I still don't
think it ought to crash PHP.
Reproduce code:
---
Expected result:
Warning: mcrypt_generic(): Operation disallowed prior to
mcrypt_generic_init() in {filename} on line 5
Actual result:
--
It crashes.
--
Edit this bug report at http://bugs.php.net/?id=49738&edit=1
#49503 [Opn->Asn]: "failed to open semaphore file"
ID: 49503 Updated by: srina...@php.net Reported By: mike at fuelsaver-mpg dot com -Status: Open +Status: Assigned Bug Type: Session related Operating System: Linux 2.6.9-023stab048.6-enterpr PHP Version: 5.2.10 -Assigned To: +Assigned To: srinatar New Comment: i will assign it to myself so that i can look more into this some time next week Previous Comments: [2009-10-02 01:06:00] sriram dot natarajan at gmail dot com i am just curious - how does this affect writing session to memcached ? [2009-10-01 12:36:22] senker at gmail dot com It also disables writing sessions to memcached, so if you are using memcached, you have to stick to 5.2.9. Please escalate this to higher priority, it's unbelievable such important bug spans over two PHP versions already. [2009-09-30 00:11:39] phi...@php.net There was some feedback, status->open. [2009-09-18 22:38:38] jd at cpanel dot net Still present in 5.2.11. This looks like it's identical to bugs 49401, 49427 and 49433 which were incorrectly marked as bogus. This happens when the mm session module tries to initialize itself. You don't need anything configured to use MM to hit the problem. As this particular bug illustrates, even a valid session.save_path setting wont avoid running into the same spurious warning. Ex: j...@jd:~$ /usr/local/bin/php -i | grep -i session PHP Warning: PHP Startup: mm_create(0, /session_mm_cli32004) failed, err mm:core: failed to open semaphore file (Permission denied) in Unknown on line 0 session Session Support => enabled session.auto_start => Off => Off session.bug_compat_42 => On => On session.bug_compat_warn => On => On session.cache_expire => 180 => 180 session.cache_limiter => nocache => nocache session.cookie_domain => no value => no value session.cookie_httponly => Off => Off session.cookie_lifetime => 0 => 0 session.cookie_path => / => / session.cookie_secure => Off => Off session.entropy_file => no value => no value session.entropy_length => 0 => 0 session.gc_divisor => 100 => 100 session.gc_maxlifetime => 1440 => 1440 session.gc_probability => 1 => 1 session.hash_bits_per_character => 4 => 4 session.hash_function => 0 => 0 session.name => PHPSESSID => PHPSESSID session.referer_check => no value => no value session.save_handler => files => files session.save_path => no value => no value session.serialize_handler => php => php session.use_cookies => On => On session.use_only_cookies => Off => Off session.use_trans_sid => 0 => 0 WDDX Session Serializer => enabled The change between 5.2.9 and 5.2.10 that makes the difference is the warning added in revision 280733: r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose r280733 | jani | 2009-05-18 12:23:42 -0500 (Mon, 18 May 2009) | 2 lines Changed paths: M /php/php-src/branches/PHP_5_2/ext/session/mod_files.c M /php/php-src/branches/PHP_5_2/ext/session/mod_mm.c M /php/php-src/branches/PHP_5_2/ext/session/mod_user.c M /php/php-src/branches/PHP_5_2/ext/session/php_session.h M /php/php-src/branches/PHP_5_2/ext/session/session.c MFH: Sync WS / CS changes where applicable It's not really clear why the warning was added to the 5.2 branch though, since it doesn't look like it was added to trunk or 5.3 in revisions 280729 and 280728. svn diff http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ext/session/mod_mm.c http://svn.php.net/repository/php/php-src/trunk/ext/session/mod_mm.c [2009-09-17 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". 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/49503 -- Edit this bug report at http://bugs.php.net/?id=49503&edit=1
#49808 [Opn]: srinatar
ID: 49808 Updated by: srina...@php.net Reported By: sriram dot natarajan at gmail dot com Status: Open Bug Type: LDAP related Operating System: unix PHP Version: 5.3SVN-2009-10-08 (snap) New Comment: here is a patch that addresses this issue [sn123...@mbelshe]'php-5.2.11'>diff -u ext/ldap/config.m4.ORIG ext/ldap/config.m4 --- ext/ldap/config.m4.ORIG Wed Oct 7 23:58:39 2009 +++ ext/ldap/config.m4 Thu Oct 8 00:37:21 2009 @@ -181,7 +181,10 @@ dnl Solaris 2.8 claims to be 2004 API, but doesn't have dnl ldap_parse_reference() nor ldap_start_tls_s() - AC_CHECK_FUNCS([ldap_parse_result ldap_parse_reference ldap_start_tls_s]) + dnl Verify whether the LDAP_DIR includes these ldap functions. + AC_CHECK_LIB([ldap_parse_result], [ldap], [HAVE_LDAP_PARSE_RESULT]) + AC_CHECK_LIB([ldap_parse_reference], [ldap], [HAVE_LDAP_PARSE_REFERENCE]) + AC_CHECK_LIB([ldap_start_tls_s], [ldap], [HAVE_LDAP_START_TLS_S]) dnl dnl SASL check if no one has objections to this suggested patch, i can commit it Previous Comments: [2009-10-08 07:56:21] sriram dot natarajan at gmail dot com Description: php ldap extension's config.m4 when enabled with ldap extension checks to see if certain ldap functions are to be enabled. currently, these ldap functions are checked to be available on the system rather than with the ldap library that the customer is trying to compile with for example, if i try to php with openldap on solaris or aix, current ldap's config.m4 extension uses AC_CHECK_FUNCS to determine if these functions are available on the system . this is ok, if ldap library is available on the system (like is the case with linux) better solution would be to check if these functions are avaialable with the ldap library provided at this option : --with-ldap= Reproduce code: --- compiling with --with-ldap= on aix or solaris machine causes these ldap functions to be not available even though opendlap library has them Expected result: ldap_parse_result, ldap_start_tls_s functions should be available on any unix systems if compiled against openldap library Actual result: -- all ldap functions are avaialable if linked against openldap -- Edit this bug report at http://bugs.php.net/?id=49808&edit=1
#49808 [Opn->Asn]: srinatar
ID: 49808 Updated by: srina...@php.net Reported By: sriram dot natarajan at gmail dot com -Status: Open +Status: Assigned Bug Type: LDAP related Operating System: unix PHP Version: 5.3SVN-2009-10-08 (snap) -Assigned To: +Assigned To: srinatar Previous Comments: [2009-10-08 07:58:06] srina...@php.net here is a patch that addresses this issue [sn123...@mbelshe]'php-5.2.11'>diff -u ext/ldap/config.m4.ORIG ext/ldap/config.m4 --- ext/ldap/config.m4.ORIG Wed Oct 7 23:58:39 2009 +++ ext/ldap/config.m4 Thu Oct 8 00:37:21 2009 @@ -181,7 +181,10 @@ dnl Solaris 2.8 claims to be 2004 API, but doesn't have dnl ldap_parse_reference() nor ldap_start_tls_s() - AC_CHECK_FUNCS([ldap_parse_result ldap_parse_reference ldap_start_tls_s]) + dnl Verify whether the LDAP_DIR includes these ldap functions. + AC_CHECK_LIB([ldap_parse_result], [ldap], [HAVE_LDAP_PARSE_RESULT]) + AC_CHECK_LIB([ldap_parse_reference], [ldap], [HAVE_LDAP_PARSE_REFERENCE]) + AC_CHECK_LIB([ldap_start_tls_s], [ldap], [HAVE_LDAP_START_TLS_S]) dnl dnl SASL check if no one has objections to this suggested patch, i can commit it [2009-10-08 07:56:21] sriram dot natarajan at gmail dot com Description: php ldap extension's config.m4 when enabled with ldap extension checks to see if certain ldap functions are to be enabled. currently, these ldap functions are checked to be available on the system rather than with the ldap library that the customer is trying to compile with for example, if i try to php with openldap on solaris or aix, current ldap's config.m4 extension uses AC_CHECK_FUNCS to determine if these functions are available on the system . this is ok, if ldap library is available on the system (like is the case with linux) better solution would be to check if these functions are avaialable with the ldap library provided at this option : --with-ldap= Reproduce code: --- compiling with --with-ldap= on aix or solaris machine causes these ldap functions to be not available even though opendlap library has them Expected result: ldap_parse_result, ldap_start_tls_s functions should be available on any unix systems if compiled against openldap library Actual result: -- all ldap functions are avaialable if linked against openldap -- Edit this bug report at http://bugs.php.net/?id=49808&edit=1
#49809 [Opn]: time_sleep_until is not available on solaris
ID: 49809 Updated by: srina...@php.net Reported By: sriram dot natarajan at gmail dot com Status: Open Bug Type: *Compile Issues Operating System: solaris PHP Version: 5.3SVN-2009-10-08 (SVN) New Comment: here is a patch against configure.in (for 5.3) that addresses this issue. pl. let me know,if this looks ok. Index: configure.in === --- configure.in(revision 289333) +++ configure.in(working copy) @@ -621,13 +621,14 @@ unlockpt \ unsetenv \ usleep \ -nanosleep \ utime \ vsnprintf \ vasprintf \ asprintf \ ) +PHP_CHECK_FUNC(nanosleep, c, rt) + dnl Check for getaddrinfo, should be a better way, but... dnl Also check for working getaddrinfo AC_CACHE_CHECK([for getaddrinfo], ac_cv_func_getaddrinfo, if no one has any objections, i can commit this patch Previous Comments: [2009-10-08 08:23:55] sriram dot natarajan at gmail dot com Description: while investigating another bug, i noticed that time_sleep_until function is not available on opensolaris. While debugging, I realized that solaris defines the time related functions within -lrt and PHP_CHECK_FUNCS macros is not able to correctly identify that this function is available within system . because of this, nanosleep dependent API is disabled on this platform Reproduce code: --- time_sleep_until function is not available in solaris / opensolaris Expected result: this function should be available on platforms where nanosleep is available. Actual result: -- time_sleep_until or other nanosleep dependent functions are not available -- Edit this bug report at http://bugs.php.net/?id=49809&edit=1
#49808 [Fbk->Bgs]: ldap configure issue
ID: 49808 Updated by: srina...@php.net Reported By: sriram dot natarajan at gmail dot com -Status: Feedback +Status: Bogus Bug Type: LDAP related Operating System: unix PHP Version: 5.3SVN-2009-10-08 (snap) Assigned To: srinatar New Comment: Jani you are right. using autoconf 2.13 made this problem go away. i should haved listened to the warning when i ran buildconf. Previous Comments: [2009-10-08 10:09:57] j...@php.net I have objection because that patch won't work. And it's exactly same thing as what is already done in ext/ldap/config.m4. What was the configure line you used? Are you using proper autoconf version (only supported and working one is 2.13!) [2009-10-08 07:58:06] srina...@php.net here is a patch that addresses this issue [sn123...@mbelshe]'php-5.2.11'>diff -u ext/ldap/config.m4.ORIG ext/ldap/config.m4 --- ext/ldap/config.m4.ORIG Wed Oct 7 23:58:39 2009 +++ ext/ldap/config.m4 Thu Oct 8 00:37:21 2009 @@ -181,7 +181,10 @@ dnl Solaris 2.8 claims to be 2004 API, but doesn't have dnl ldap_parse_reference() nor ldap_start_tls_s() - AC_CHECK_FUNCS([ldap_parse_result ldap_parse_reference ldap_start_tls_s]) + dnl Verify whether the LDAP_DIR includes these ldap functions. + AC_CHECK_LIB([ldap_parse_result], [ldap], [HAVE_LDAP_PARSE_RESULT]) + AC_CHECK_LIB([ldap_parse_reference], [ldap], [HAVE_LDAP_PARSE_REFERENCE]) + AC_CHECK_LIB([ldap_start_tls_s], [ldap], [HAVE_LDAP_START_TLS_S]) dnl dnl SASL check if no one has objections to this suggested patch, i can commit it [2009-10-08 07:56:21] sriram dot natarajan at gmail dot com Description: php ldap extension's config.m4 when enabled with ldap extension checks to see if certain ldap functions are to be enabled. currently, these ldap functions are checked to be available on the system rather than with the ldap library that the customer is trying to compile with for example, if i try to php with openldap on solaris or aix, current ldap's config.m4 extension uses AC_CHECK_FUNCS to determine if these functions are available on the system . this is ok, if ldap library is available on the system (like is the case with linux) better solution would be to check if these functions are avaialable with the ldap library provided at this option : --with-ldap= Reproduce code: --- compiling with --with-ldap= on aix or solaris machine causes these ldap functions to be not available even though opendlap library has them Expected result: ldap_parse_result, ldap_start_tls_s functions should be available on any unix systems if compiled against openldap library Actual result: -- all ldap functions are avaialable if linked against openldap -- Edit this bug report at http://bugs.php.net/?id=49808&edit=1
#49829 [Fbk]: ./configure --with-mysql=mysqlnd gave configure error
ID: 49829 Updated by: srina...@php.net Reported By: eddychu at yahoo dot com Status: Feedback Bug Type: Compile Failure Operating System: CentOS 5.3 PHP Version: 5.3.0 New Comment: also, for these kind of configure errors, it is better if you provide with the corresponding error you noticed inside config.log file (created under the same location where you are trying to build). as sjoerd suggested, you probably don't have mysql develop rpm installed on your system. Previous Comments: [2009-10-12 13:01:18] u...@php.net Works fine for me. Please make sure that configure is sane: rm configure ; ./buildconf --force ; ./configure --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd [2009-10-10 12:11:31] sjo...@php.net Thank you for your bug report. Have you installed the MySQL development files, from the mysql-devel package? [2009-10-10 02:12:33] eddychu at yahoo dot com Description: Followed http://us.php.net/manual/en/mysqlnd.install.php instructions to attempt to configure PHP to build with mysqlnd support, but it gave error: configure: error: Cannot find MySQL header files under mysqlnd,. Note that the MySQL client library is not bundled anymore! although ext/mysqlnd folder is right there under php-5.3.0. And no Makefile was generated so I can't build PHP. Either the instructions are wrong or the configure scripts are wrong. Reproduce code: --- --- >From manual page: mysqlnd.install --- Simply try to configure with mysqlnd: ./configure --with-mysql=mysqlnd, --with-mysqli=mysqlnd and --with-pdo-mysql=mysqlnd Expected result: Expected ./configure --with-mysql=mysqlnd, --with-mysqli=mysqlnd and --with-pdo-mysql=mysqlnd to successfully generate the Makefile. If other configure option(s) are required for these to work, they should be mentioned in the above manual page. Actual result: -- configure: error: Cannot find MySQL header files under mysqlnd,. Note that the MySQL client library is not bundled anymore! Can't proceed further. -- Edit this bug report at http://bugs.php.net/?id=49829&edit=1
#49850 [Opn]: Cannot override Apache2 vhost ErrorLog with vhost error_log
ID: 49850 Updated by: srina...@php.net Reported By: rmichael-php at edgeofthenet dot org Status: Open Bug Type: Apache2 related Operating System: OpenSolaris PHP Version: 5.2.11 New Comment: did you try to reproduce this issue with recently released php 5.2.11 ? i am not able to reproduce this issue with latest php snapshot (http://snaps.php.net) on both php 5.2. and php 5.3 Previous Comments: [2009-10-12 19:22:24] rmichael-php at edgeofthenet dot org Description: (This bug is against PHP 5.2.9, but I cannot choose it in the pull-down menu; and, there is nothing related in ChangeLogs since then.) PHP error_log output goes to Apache's ErrorLog file, not the php_admin_value error_log I specify. Both Apache's ErrorLog and PHP's error_log are being specified in a virtualhost configuration file: Results in phpinfo() indicating the error_log is in fact the file set with "php_admin_value error_log", but the test string appears in the Apache ErrorLog file instead. I believe this is dupe of 31419, but that bug was closed. http://bugs.php.net/bug.php?id=31419 # httpd -V Server version: Apache/2.2.11 (Unix) Server built: Jun 24 2009 11:50:30 Server's Module Magic Number: 20051115:21 Server loaded: APR 1.3.3, APR-Util 1.3.7 Compiled using: APR 1.3.3, APR-Util 1.3.4 # php --version PHP 5.2.9 (cli) (built: Jun 4 2009 21:25:09) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Reproduce code: --- php_admin_flag display_errors On php_admin_flag display_startup_errors On php_admin_value error_reporting 6143 php_admin_flag log_errors On php_admin_value error_log /path/to/my_php-error_log ErrorLog /path/to/my_apache-error_log Expected result: Error log output should go to /path/to/my_php-error_log as specified in the virtualhost configuration file. (Just consulted bugs suggest relates issues; none apply.) -- Edit this bug report at http://bugs.php.net/?id=49850&edit=1
#49840 [Opn->Fbk]: PHP_SELF returns incorrect value
ID: 49840 Updated by: srina...@php.net Reported By: lxd717 at gmail dot com -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: WINXP PHP Version: 5.2.11 New Comment: also provide the version of web server are you using ? as bug #49825 mentions, are you seeing this issue with IIS as well ? if yes, then this bug will need to be moved as duplicate of 49825 . Previous Comments: [2009-10-12 11:10:19] sjo...@php.net See also Bug #49825 PHP_SELF duplicate path. [2009-10-12 03:48:35] lxd717 at gmail dot com Actual result: -- /confucian/η??Õѧָ׷/test.php/confucian/???1??2?-|???/test. php [2009-10-12 03:47:14] lxd717 at gmail dot com Description: PHP_SELF returns incorrect value. I creat a folder with chinese, the path is '/confucian/西æ¹å²å¦èä½/', and then I check phpinfo(),I found that $_SERVER['PHP_SELF'] returns incorrect value. But folders Created in english found no errors. Reproduce code: --- file: test.php The script test.php was created in a non-english folder,such as '/confucian/西æ¹å²å¦èä½/'. Expected result: /confucian/%e8%a5%bf%e6%96%b9%e5%93%b2%e5%ad%a6%e8%91%97%e4%bd%9c/test.php or /confucian/西æ¹å²å¦èä½/test.php Actual result: -- /confucian/η??Õѧָ׷/index.php/confucian/???1??2?-|???/index.php -- Edit this bug report at http://bugs.php.net/?id=49840&edit=1
#49810 [Fbk->Bgs]: safe_mode uid/gid are always 0/1024
ID: 49810 Updated by: srina...@php.net Reported By: php-dev at micallef dot fr -Status: Feedback +Status: Bogus Bug Type: Safe Mode/open_basedir Operating System: Solaris 10 PHP Version: 5.2.11 New Comment: this is not a php bug. i recommend closing this as bogus. i have heard this issue from some of my other customers using cool stack as well. it turns out that apache in cool stack is compiled with - D_FILE_OFFSET_BITS=64 and php is not compiled with this similar flags. when one uses -D_FILE_OFFSET_BITS=64, stat file structure size used with both apache as well as php's apache sapi module is different. hence, you are running into this issue. this issue is already reported in cool stack forum multiple time. please check out their new version known as web stack under http://www.sun.com/webstack and this should address your concern. Previous Comments: [2009-10-19 15:07:45] j...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2009-10-08 08:48:12] php-dev at micallef dot fr Description: Hello, We have a Sparc T2000 with coolstack for apache (v2.2.9) and php 5.2.11. When I activate safe_mode, we have this error : Warning: Unknown: SAFE MODE Restriction in effect. The script whose uid/gid is 1/1024 is not allowed to access /david/SHERPA/index.php owned by uid/gid 1024/512 in Unknown on line 0 Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0 Fatal error: Unknown: Failed opening required '/test/php/index.php' (include_path='.:/opt/php-5.2.11/includes') in Unknown on line 0 I suppose that de problem come with function php_getuid and php_getgid. I have done same test on RHEL_5 and I haven't any problem. Do you have a idea ? Reproduce code: --- Expected result: Warning: Unknown: SAFE MODE Restriction in effect. The script whose uid/gid is 1/1024 is not allowed to access /david/SHERPA/index.php owned by uid/gid 1024/512 in Unknown on line 0 Warning: Unknown: failed to open stream: Permission denied in Unknown on line 0 Fatal error: Unknown: Failed opening required '/test/php/index.php' (include_path='.:/opt/php-5.2.11/includes') in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=49810&edit=1
#46218 [NoF->Fbk]: apache2 reaches max clients limit with error in php_stdiop_set_option
ID: 46218 Updated by: srina...@php.net Reported By: funky2step at gmail dot com -Status: No Feedback +Status: Feedback Bug Type: Streams related Operating System: RHEL ES Rel 4 (Nahant Update 6) PHP Version: 5.2.6 New Comment: to me, it sounds more like configuration issue rather than a possible bug within php. if your application is taking time to long to process , then either you will need to reduce the maximum execution time of your php script (within php.ini) or increase apache's max client value to address to your system load.. did you try to reduce the maximum_execution_time in your php.ini setting to make sure that your php scripts are terminated after some time ? if you think it is some php bug that is causing it, get pstack output of your php process on a regular basis and see what all these processes are doing Previous Comments: [2009-10-20 00:06:42] joliver at gmx dot at Exactly the same problem here: Debian Lenny, apache 2.2.9 (prefork), php 5.2.6, eaccelerator 0.9.5.3 Server crashes every few days with "server reached MaxClients setting, consider raising the MaxClients setting" When restarting several warnings "child process XXX still did not exit, sending a SIGTERM" show up (however much less than MaxClients). We first suspected a Slowloris attack, however we can rule out this after counting new connections in the firewall-logs. [2009-10-08 20:04:27] apache at vacances-location dot net I experiencing exactly the same problem, Apache2 crash with message "reaches the maxclients limit", with no load, and it don't kill the old processes. I have the same versions, but on Debian Lenny. Somebody have a fix ? [2009-04-14 01:00:01] 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". [2009-04-09 09:24:52] funky2step at googlemail dot com We used the prefork mpm. [2009-04-07 11:06:02] david at dsanders dot co dot uk I too am seeing this bug on Apache 2.2.9 with PHP 5.2.6 using MPM Prefork. In a web crawler application that I have written it continually hangs up max clients. 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/46218 -- Edit this bug report at http://bugs.php.net/?id=46218&edit=1
#49816 [Fbk->Opn]: output corruption using flush
ID: 49816 Updated by: srina...@php.net Reported By: paul at wcclan dot net -Status: Feedback +Status: Open Bug Type: Output Control Operating System: FreeBSD 7.2-RELEASE-p4 PHP Version: 5.2.11 New Comment: this is reproduced with latest php 5.2 svn snapshot as well. rolling back to revision 287422 within main/SAPI.c seems to resolve this issue. Previous Comments: [2009-10-23 12:35:01] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ If it fails also with this snapshot, I think I broke it when fixing bug #49248 :( [2009-10-22 19:49:18] paul at wcclan dot net I installed php 5.3.0. Here the bug doesn't appear either. Unfortunately I can't move to 5.3.0 yet due to some compatibility issues. [2009-10-22 19:27:53] paul at wcclan dot net To shed some more light on this I did the following: - In the source directory I have of my old 5.2.10 php installation I executed make install clean - Apache restart - The test url now displays correctly in the browser. A request through telnet shows compression is also being applied. - In the source directory of my 5.2.11 installation I executed make install clean - Apache restart - The test URL is displaying corrupt data again. A request through telnet shows the datastream is compressed or at least altered. For this test I did notice something weird. With PHP 5.2.10 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:12:50 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.10 X-Powered-By: PHP/5.2.10 Content-Encoding: gzip Vary: Accept-Encoding Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html With PHP 5.2.11 the response header is as follows: HTTP/1.1 200 OK Date: Thu, 22 Oct 2009 19:23:13 GMT Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k PHP/5.2.11 X-Powered-By: PHP/5.2.11 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html So in this example there is a problem with the headers. Note that this is not only a header problem as a request for /phpinfo still returns the correct headers as in the example given before. The output is however still corrupted when using flush. [2009-10-20 06:57:52] alec at alec dot pl The last PHP version it works with is 5.2.10. Compiled in the same system (libs). [2009-10-19 15:15:36] j...@php.net See also bug #48725 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/49816 -- Edit this bug report at http://bugs.php.net/?id=49816&edit=1
#46917 [Opn]: Socket handling completely broken
ID: 46917
Updated by: srina...@php.net
Reported By: jost_boekemeier at users dot sf dot net
Status: Open
Bug Type: Streams related
Operating System: win32 only
PHP Version: 5.2.8
New Comment:
hi
please refer to bug #49447 (http://bugs.php.net/bug.php?id=49447)
where I have attempted to resolve this issue.
i am not sure, if you tried with php 5.2.11 or with recent snapshot
and let me know if this resolved your issue
Previous Comments:
[2009-01-10 16:12:15] jost_boekemeier at users dot sf dot net
Here's a test case:
- TestServer.java --
import java.io.InputStream;
import java.io.OutputStream;
import java.net.ServerSocket;
import java.net.Socket;
public class TestServer {
public static void main(String args[]) throws Exception {
ServerSocket ss = new ServerSocket (9090);
System.out.println("accepting connections");
Socket s = ss.accept();
System.out.println("got initial request");
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();
while (true) {
out.write((byte)in.read());
out.flush();
System.out.println("waiting for next request");
}
}
}
-TestClient.php--
To reproduce this bug on Windows XP and above, start the server with:
java TestServer
and refresh the
http://127.0.0.1/TestClient.php
a few times.
Then stop TestServer and start it again.
Refresh
http://127.0.0.1/TestClient.php
to get a broken connection from PHP.
I was able to reproduce this bug with yesterday's 5.2 windows
snapshot.
Regards,
Jost Bökemeier
[2009-01-07 20:44:43] fel...@php.net
I changed the EGAIN to EWOULDBLOCK in the checking.
http://news.php.net/php.cvs/55434
[2009-01-06 19:51:15] jost_boekemeier at users dot sf dot net
The windows equivalent to EAGAIN is EWOULDBLOCK or WSAEWOULDBLOCK.
Could it be that EAGAIN is 0 on windows?
Unfortunately I don't have the time and resources to debug this at the
moment.
[2009-01-06 19:15:52] jost_boekemeier at users dot sf dot net
Well, the initialization is okay now.
However, the code still doesn't work on windows. Which means that
there's another bug.
The php_socket_errno() != EAGAIN looks suspicious.
"Depending on whether your socket is blocking or non-blocking, you
either get FD_CLOSE notification, or recv() returns 0 (graceful
disconnection), or recv() returns WSAECONNRESET error."
I don' see how the current code handles these three cases properly.
[2009-01-06 17:41:49] fel...@php.net
Currently the WSASetLastError(0); already exists for Windows in the
code.
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/46917
--
Edit this bug report at http://bugs.php.net/?id=46917&edit=1
#49838 [Ver->Opn]: feof() reached end while reading big HTTP response from socket using fgets.
ID: 49838
Updated by: srina...@php.net
Reported By: travian dot utils at gmail dot com
-Status: Verified
+Status: Open
Bug Type: Sockets related
Operating System: *
PHP Version: 5.2.11
New Comment:
this issue is no longer reproducible with latest svn snapshot
(http://snaps.php.net). pl. verify with latest snapshot and let us know.
Previous Comments:
[2009-10-12 21:42:32] lbarn...@php.net
Verified (with gmc at sonologic dot nl's script), 5.2.11 only
[2009-10-12 19:17:05] travian dot utils at gmail dot com
Hello, Sjoerd.
Sorry for not fully clear description.
Thank you for interest to this problem.
gmc(at)sonologic(dot)nl understood my description and put code for
reproducing this problem. Thanks also to him.
Problem occurred when we updated PHP from 5.2.10 to 5.2.11 on our
production.
On PHP 5.2.10 problem code on the same server worked properly.
We tested problem code on the same server using PHP version 5.2.8 and
also code worked properly.
Now we rewrote our code for downloading big HTTP files without using
fgets(using socket_create, socket_bind, socket_connect, socket_select,
socket_write, socket_read and socket_close).
It works fine on PHP 5.2.8 and 5.2.11.
And it working fine in production on PHP 5.2.11.
So this is bug, not a configuration issue.
--
With best regards,
Andrei.
[2009-10-12 11:51:32] gmc at sonologic dot nl
I'm experiencing the same problem on:
FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Tue Oct 14 11:55:05
CEST 2008 r...@postel:/usr/obj/usr/src/sys/GENERIC i386
The problem is that feof($fp) returns TRUE, even though the end of the
remote file has not been reached.
The below script reproduces the problem. I'm sorry it depends on an
external resource, that's just the nature of the problem. AFAICS, the
bug is not dependent on the particular file chosen, it occurs for any
large text file.
http://www.mersenneforum.org/txt/43.txt";;
if (!($fp = fopen($file, "r"))) {
die("could not open XML input from $file");
}
$chunkno=1;
$total=0;
while($data=fgets($fp,1)) {
$total+=strlen($data);
if($trigger_bug) {
print "chunk $chunkno, total ".$total."
(+".strlen($data)."), eof: ".(feof($fp)?1:0)."\n";
} else {
print "chunk $chunkno, total ".$total."
(+".strlen($data).")\n";
}
$chunkno++;
}
fclose($fp);
?>
With $trigger_bug set to true, this will terminate before all of the
file is read. With $trigger_bug set to false it will read the entire
file. Note that the only difference between the two is that the script
displays the output of feof($fp).
This bug started to bite us when we upgraded from 5.2.1 to 5.2.11, it
is not present in 5.2.1 / 5.1.4.
[2009-10-12 11:13:06] sjo...@php.net
Thank you for your bug report.
I don't understand the description you gave. Please make a small PHP
script to reproduce the problem and describe what the expected and
actual output are. Also, please explain exactly what is going wrong in
which PHP function.
[2009-10-11 17:13:45] travian dot utils at gmail dot com
Corrected summary.
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/49838
--
Edit this bug report at http://bugs.php.net/?id=49838&edit=1
#49851 [Ver->Fbk]: HTTP breaks on long header line
ID: 49851
Updated by: srina...@php.net
Reported By: sjoerd-php at linuxonly dot nl
-Status: Verified
+Status: Feedback
Bug Type: HTTP related
Operating System: Linux 2.6.28 Ubuntu 9.0.4
PHP Version: 5.3SVN-2009-10-12 (SVN)
New Comment:
php internally does not have any hard coded limit to parse the header
value. the only time, you will see http header in your output is when
the header does not end with \r\n (to mark it as new line).
as per HTTP spec, every HTTP headers need to end with \r\n (CR LF) to
mark the end of the line. php internally checks for this line to
determine if the header is done before proceeding to parse the body of
the request.
if you modify this below test case to reflect that there needs to be
\r\n to mark it as end of line, then you will see the expected output.
http://www.google.nl/');
echo "Foo";
?>
i suggest marking this bug as bogus (or not an issue).
Previous Comments:
[2009-10-12 21:16:11] lbarn...@php.net
Verified, since 5.1.0 at least.
[2009-10-12 20:24:53] sjo...@php.net
See also bug #49847 "exec() confused by a specially crafted string",
which has a similar cause.
>From http_fopen_wrapper.c:
while (!body && !php_stream_eof(stream)) {
size_t http_header_line_length;
if (php_stream_get_line(stream, http_header_line,
HTTP_HEADER_BLOCK_SIZE, &http_header_line_length) && *http_header_line
!= '\n' && *http_header_line != '\r') {
...
} else {
break;
[2009-10-12 20:20:08] sjoerd-php at linuxonly dot nl
Description:
If a HTTP response contains an header of exactly 1024 characters, the
remaining headers are not parsed and are returned in the output.
Reproduce code:
---
http://localhost/a.php');
?>
a.php:
http://www.google.nl/');
echo "Foo";
?>
Expected result:
The homepage of google.nl.
Actual result:
--
Location: http://www.google.nl
Vary: Accept-Encoding
Content-Length: 3
Connection: close
Content-Type: text/html
Foo
--
Edit this bug report at http://bugs.php.net/?id=49851&edit=1
#50001 [Fbk]: gzseek don't working
ID: 50001 Updated by: srina...@php.net Reported By: onzi at ustrem dot org Status: Feedback Bug Type: Zlib Related Operating System: AIX 6.1 PHP Version: 5.2.11 New Comment: long story short, by any chance , your PHP compile flags include -D_FILE_OFFSET_BITS=64 option ? if yes, then the below mentioned error will happen ? Previous Comments: [2009-10-26 22:46:13] j...@php.net Exactly what is the zlib version in your system you linked PHP with? [2009-10-26 15:48:01] onzi at ustrem dot org Read "Expected Result" as "Actual Result" Sorry [2009-10-26 15:45:08] onzi at ustrem dot org Description: OSlevel 6100-02-03-0909 xlc 10.1.0.0 I run ./sapi/cli/php ext/zlib/tests/gzseek_basic.phpt gzopen opens file but gzseek seems to not working. Reproduce code: --- Expected result: resource(5) of type (stream) move to the 50th byte int(-1) tell= string(0) "" move forward to the 100th byte int(-1) tell= string(0) "" move backward to the 20th byte int(-1) tell= string(0) "" Actual result: -- move to the 50th byte int(0) tell=50 string(10) " high abov" move forward to the 100th byte int(0) tell=100 string(10) "Destiny wh" move backward to the 20th byte int(0) tell=20 string(10) "hrough fee" -- Edit this bug report at http://bugs.php.net/?id=50001&edit=1
#50001 [Fbk->Bgs]: gzseek don't working
ID: 50001 Updated by: srina...@php.net Reported By: onzi at ustrem dot org -Status: Feedback +Status: Bogus Bug Type: Zlib Related Operating System: AIX 6.1 PHP Version: 5.2.11 -Assigned To: +Assigned To: srinatar New Comment: you are better off compiling your own zlib for this platform. the zlib rpm that you downloaded does not bundle zlib header within and i am not sure, which version of zlib header your php build is using. this issue typically happens when the underlying dependent library (which in this case is zlib) compiled with different options (like largefiles enabled etc) while php which is using this underlying library is being compiled with a different option. there is no php bug here. compiling php and zlib on this platform works fine. feel free to reopen this bug, if recompiling doesnt help. Previous Comments: [2009-10-27 07:55:05] onzi at ustrem dot org I use for PHP (--with-zlib-dir=/opt/freeware/lib) zlib-1.2.3-5 zlib-devel-1.2.3-5 from here: http://gnome.bullfreeware.com/aixtoolbox/RPMS/ppc/zlib/ My env OBJECT_MODE=32 CC=cc_r CFLAGS=-O2 [2009-10-27 01:28:24] srina...@php.net long story short, by any chance , your PHP compile flags include -D_FILE_OFFSET_BITS=64 option ? if yes, then the below mentioned error will happen ? [2009-10-26 22:46:13] j...@php.net Exactly what is the zlib version in your system you linked PHP with? [2009-10-26 15:48:01] onzi at ustrem dot org Read "Expected Result" as "Actual Result" Sorry [2009-10-26 15:45:08] onzi at ustrem dot org Description: OSlevel 6100-02-03-0909 xlc 10.1.0.0 I run ./sapi/cli/php ext/zlib/tests/gzseek_basic.phpt gzopen opens file but gzseek seems to not working. Reproduce code: --- Expected result: resource(5) of type (stream) move to the 50th byte int(-1) tell= string(0) "" move forward to the 100th byte int(-1) tell= string(0) "" move backward to the 20th byte int(-1) tell= string(0) "" Actual result: -- move to the 50th byte int(0) tell=50 string(10) " high abov" move forward to the 100th byte int(0) tell=100 string(10) "Destiny wh" move backward to the 20th byte int(0) tell=20 string(10) "hrough fee" -- Edit this bug report at http://bugs.php.net/?id=50001&edit=1
#49682 [Asn->Fbk]: Pear broken in php 5.2.11
ID: 49682 Updated by: srina...@php.net Reported By: kr_krack at yahoo dot com -Status: Assigned +Status: Feedback Bug Type: Compile Failure Operating System: Ubuntu 8.04 LTS PHP Version: 5.2.11 Assigned To: dufuz New Comment: see also bug#49578 this issue is not noticed with latest svn snapshot. suggest closing this as not reproducible with recent snapshots. Previous Comments: [2009-10-28 16:37:51] t...@php.net For the sake of completeness: r...@always:~/php-5.2.11# make install Installing PHP SAPI module: cgi Installing PHP CGI binary: /till-test/bin/ Installing PHP CLI binary:/till-test/bin/ Installing PHP CLI man page: /till-test/man/man1/ Installing build environment: /till-test/lib/php/build/ Installing header files: /till-test/include/php/ Installing helper programs: /till-test/bin/ program: phpize program: php-config Installing man pages: /till-test/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /till-test/lib/php/ [PEAR] Archive_Tar- already installed: 1.3.3 [PEAR] Console_Getopt - already installed: 1.2.3 [PEAR] Structures_Graph- already installed: 1.0.2 [PEAR] XML_Util - already installed: 1.2.1 [PEAR] PEAR - already installed: 1.8.0 Wrote PEAR system config file at: /till-test/etc/pear.conf You may want to add: /till-test/lib/php to your php.ini include_path I used php-5.2.11 from php.net. No additional patches (fpm), etc.. [2009-10-28 16:32:01] t...@php.net Hey guys, please confirm the following: ./configure -prefix=/till-test --disable-rpath --disable-ipv6 -- disable-pdo --disable-debug --with-bz2=/usr --with-zlib-dir=/usr -- with-pcre-regex --with-mhash --with-xsl=/usr --with-mcrypt=/usr -- enable-mbstring --enable-inline-optimization --enable-xml --enable- sockets --enable-mbregex --enable-zip --enable-cli make make install It started working when I removed --with-zend-vm=GOTO. Thanks, Till [2009-10-28 16:14:47] saltybea...@php.net Have you tried the latest install-pear-nozlib.phar? Available here: http://pear.php.net/install-pear-nozlib.phar [2009-10-27 12:20:24] cel...@php.net Pierre: I have a newborn, I reassigned this to dufuz because I won't have time to fix this in any reasonable timeframe [2009-10-27 07:14:28] jcua at shaw dot ca I have the same errors compiling php5.2.11 on centos 5.4 with apache 2.2.14 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an arr
#50047 [Opn]: interface binding for fsockopen (like socket_bind)
ID: 50047
Updated by: srina...@php.net
Reported By: naox at o2 dot pl
Status: Open
Bug Type: Feature/Change Request
Operating System: -
PHP Version: 5.2.11
New Comment:
is this some thing what you are looking for ?
$fp = fsockopen("tcp://127.0.0.1", 8080);
or
$fp = fsockopen("unix:///tmp/mysocket", ..);
Previous Comments:
[2009-11-01 00:26:59] naox at o2 dot pl
Description:
PHP really needs interface binding for fsockopen() (like socket_bind())
--
Edit this bug report at http://bugs.php.net/?id=50047&edit=1
#46063 [NoF->Fbk]: SoapFault exception: [HTTP] Error Fetching http headers
ID: 46063
Updated by: srina...@php.net
Reported By: filip_stjernberg at hotmaol dot com
-Status: No Feedback
+Status: Feedback
Bug Type: SOAP related
Operating System: Windows vista
PHP Version: 5.2.6
New Comment:
looking at the truss output, it seems to me the endpoint service is
waiting for some more input to be provided as part of your HelloWorld
request. you might want to check their documentation .
i don't think there is any issue with SoapClient implementation here.
Previous Comments:
[2009-11-04 13:10:25] ucl at mail dot ru
I've solve the problem of "Error Fetching http headers" by adding
ini_set('max_input_time', -1);
before SOAP call.
Problem is that my SOAP server have to think long time after request,
and i'v had timeout in soap.
[2009-03-13 08:53:56] ft20082 at 163 dot com
i have some problem with it.
and my result is :
Fatal error: Uncaught SoapFault exception: [HTTP] Error Fetching http
headers in E:\wwwroot\wsdl.php:41 Stack trace: #0 [internal function]:
SoapClient->__doRequest('http://webservi...', '',
1, 0) #1 E:\wwwroot\wsdl.php(41):
SoapClient->__soapCall('searchFlights', Array) #2 {main} thrown in
E:\wwwroot\wsdl.php on line 41
so, what should i do?
[2009-02-21 01:00:01] 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".
[2009-02-13 23:24:28] fel...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-09-12 07:49:07] filip_stjernberg at hotmaol dot com
Description:
I'm trying to use an existing webservice:
http://testhorizon.gothiagroup.com/AFSServices/AFSService.svc?wsdl
There is a simple test function called "HelloWorld" that returns the
input "myVaule". This function dos not need authentification but its
more advaced one do.
Really need this to work, have tried nuSOAP to but that gives me other
problems.
Reproduce code:
---
This is the code I use:
try{
$wsdl =
'http://testhorizon.gothiagroup.com/AFSServices/AFSService.svc?wsdl';
$client = new SoapClient($wsdl,
array(
'soap_version' => SOAP_1_2,
'trace' => 1,
'exceptions' => 1
));
print($client->HelloWorld(array('myValue' => 'Test')));
} catch (Exception $e) {
printf("Message = %s\n",$e->__toString());
}
print "n";
print "Request :n".htmlspecialchars($client->__getLastRequest())
."n";
print
"Response:n".htmlspecialchars($client->__getLastResponse())."n";
print "";
Expected result:
Hello from AFSService: Test
Actual result:
--
Message = SoapFault exception: [HTTP] Error Fetching http headers in
/customers/veus.se/veus.se/httpd.www/Test/samples/AFSWS1.php:20 Stack
trace: #0 [internal function]: SoapClient->__doRequest('http://testhori...', 'http://tempuri', 2, 0) #1
[internal function]: SoapClient->__call('HelloWorld', Array) #2
/customers/veus.se/veus.se/httpd.www/Test/samples/AFSWS1.php(20):
SoapClient->HelloWorld(Array) #3 {main}
nRequest :n
http://www.w3.org/2003/05/soap-envelope";
xmlns:ns1="http://tempuri.org/";>Exor
nResponse:nn
--
Edit this bug report at http://bugs.php.net/?id=46063&edit=1
#50064 [Opn->Fbk]: SOAP response by is not encoded
ID: 50064 Updated by: srina...@php.net Reported By: ckl at ecw dot de -Status: Open +Status: Feedback Bug Type: SOAP related Operating System: Windows XP SP3 PHP Version: 5.2.11 New Comment: will it be to provide a test case where this problem is reproduced. This would allow us to look further on this issue. the below provided information doesn't seem to be enough to reproduce this problem when I tried your interface.wsdl, I get the below error : Message = SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Missing with name 'tns:findUserResponse' in /export/home/sriramn/scripts/PHP/soap-client-3.php:10 Stack trace: looks like the interface.wsdl is missing some information. to answer your other question, php internally uses libxml2 to parse the xml file. Previous Comments: [2009-11-03 16:28:17] ckl at ecw dot de Description: I developed a Spring-WS webservice which I try to call by PHP. WSDL file: --- http://schemas.xmlsoap.org/wsdl/"; xmlns:sch="http://www.ecw.de/adg/person/schema/beans"; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:tns="http://www.ecw.de/adg/person/schema/beans"; targetNamespace="http://www.ecw.de/adg/person/schema/beans";> http://www.w3.org/2001/XMLSchema"; xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"; xmlns="http://www.ecw.de/adg/person/schema/beans"; xmlns:pb="http://www.ecw.de/adg/person/schema/beans"; xmlns:schemas="http://www.ecw.de/adg/person/schema/beans"; xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"; attributeFormDefault="unqualified" elementFormDefault="unqualified" jaxb:extensionBindingPrefixes="xjc" jaxb:version="1.0" targetNamespace="http://www.ecw.de/adg/person/schema/beans"; xmlns:tns="http://www.ecw.de/adg/person/schema/beans";> http://schemas.xmlsoap.org/soap/http"/> http://localhost:8080/ADG/personService"/> --- Response from Spring-WS (fetched by proxying the request/response): --- http://schemas.xmlsoap.org/soap/envelope/";> http://www.ecw.de/adg/person/schema/beans";> http://www.w3.org/2001/XMLSchema-instance"/> http://www.w3.org/2001/XMLSchema-instance"/> http://www.w3.org/2001/XMLSchema-instance"/> desc
#49098 [Opn->Fbk]: Using custom session handler causes segfault in session_save_state
ID: 49098 Updated by: srina...@php.net Reported By: bugs at timj dot co dot uk -Status: Open +Status: Feedback Bug Type: Session related Operating System: Linux PHP Version: 5.2.10 New Comment: thanks for taking time and trying to reproduce this issue. can u kindly provide / attach stack trace when this issue happens... this would help us identify us as to what is happening at ur end.. u can enable core dump by doing some thing like ulimit -c unlimited now, u can run your program to generate core dump and provide us the stack trace as mentioned in this below link.. http://bugs.php.net/bugs-generating-backtrace.php Previous Comments: [2009-11-08 19:10:35] t...@php.net After spending an enormous amount of time testing endless combinations of compile and runtime options, I have hopefully found the key to solving this obscure bug. The segfault only happens specifically if the following is true: - the mbstring extension is enabled, *AND* - the mssql extension is enabled (particularly weird because the test script does not use mssql in any way) In the hope of making the reproduction scenario more robust, I have pared down the configure line to a minimum and here is the exact environment, from source tarball, which I can reproduce it in: OS: Fedora 11 x86_64 (fully updated as at 2009-11-08) Notable dependencies: mysql-devel-5.1.37-1.fc11.x86_64 freetds-devel-0.82-5.fc11.x86_64 gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC) Download snapshot 200911070930 from snaps.php.net tar -jxf php5.2-200911070930.tar.bz2 cd php5.2-200911070930 ./configure --includedir=/usr/include --libdir=/usr/lib64 --with-libdir=lib64 --without-pear --with-mysqli=shared,/usr/bin/mysql_config --enable-mbstring=shared --enable-mbregex --with-mssql=shared,/usr make -j3 make install # as root create /usr/local/etc/php.ini containing only the following: extension=mbstring.so extension=mssql.so extension=mysqli.so include_path=/path/to/pear/php $ /usr/local/bin/php -c /usr/local/etc/php.ini php-bug49098.php # script posted on 11 Aug Segmentation fault Commenting out EITHER "extension=mbstring.so" or "extension=mssql.so" in /usr/local/etc/php.ini stops the segfault. Can anyone else now reproduce this with the above environment? Is there any other information about the environment that I need to provide? [2009-09-26 10:54:13] t...@php.net 1. Still segfaults for me with the release version of 5.2.11, with MySQLi connection (mysql client libs and server 5.1.37). -> Sriram, I also tried with your test script (just to make sure there wasn't a subtle difference from mine) and it also segfaulted. -> Segfault is still in the same place as originally. 2. snap-200909261030 doesn't build atm (error in mysqli_api) What more info can I give to assist? [2009-09-24 19:32:19] srina...@php.net unable to reproduce with the earlier provided test case. so, need more information to reproduce / investigate this bug . also, would be useful to know if this still happens with either 5.2.11 (or latest svn snapshot) [2009-09-24 17:48:47] srina...@php.net i do have a wordpress running with php 5.2.11 for my site and i don't have any issues. if you do notice with the latest php build, if you can provide a test case to reproduce this bug that would be useful. as i noted earlier, i was not able to reproduce this bug with the provided test case here. [2009-09-18 19:43:06] ulf at ladb dot unm dot edu Hi, Is this bug still under investigation? Just wondering because 5.2.9 is the last version of PHP that works with Wordpress/MySQL without crashing Apache. Thanks. 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/49098 -- Edit this bug report at http://bugs.php.net/?id=49098&edit=1
#50111 [Opn->Fbk]: memory leak when stream_context_create is used
ID: 50111
Updated by: srina...@php.net
Reported By: datib...@php.net
-Status: Open
+Status: Feedback
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.2.11
New Comment:
hmmm.. not sure, why u think there is a leak.
when u write this below code
$c = stream_context_create();
u do understand that underlying php engine need to do some processing
underneath and store the reference of this processing in $c variable.
this does require some memory consumption.
i guess, if u do some thing like and still no
$c = stream_context_create..
unset($c);
$m1 = memory_get_usage();
and still see memory leak , then let us know..
Previous Comments:
[2009-11-08 01:06:54] datib...@php.net
Code to reproduce can be made simpler, since the problem seems to be
with stream_context_create():
$m0 = $m1 = $i = 0;
$c = null;
while ($i<5) {
$m0 = memory_get_usage();
$c = stream_context_create();
$m1 = memory_get_usage();
echo $m1-$m0,PHP_EOL;
++$i;
}
[2009-11-07 09:26:05] datib...@php.net
Description:
When stream_context_create() is used in conjunction with
file_get_contents() or other stream related functions that accept a
context parameter, memory is being leaked.
Reproduce code:
---
for ($i=0;$i<5;++$i){
$m0 = memory_get_usage();
file_get_contents('http://www.google.com', false,
stream_context_create(array()));
$m1 = memory_get_usage();
echo $m1-$m0,PHP_EOL;
}
Expected result:
X (where X is the memory increase for the first iterator)
0
0
0
0
Actual result:
--
X (where X is the memory increase for the first iterator)
384 (or something similar)
420
420
480
--
Edit this bug report at http://bugs.php.net/?id=50111&edit=1
#50145 [Opn]: srinatar
ID: 50145
Updated by: srina...@php.net
Reported By: srina...@php.net
Status: Open
Bug Type: Reproducible crash
Operating System: solaris, linux
PHP Version: 5.3.1RC3
New Comment:
af course, this issue is not reproduced when used with
USE_ZEND_ALLOC=0. this can be a temporary work around until this issue
is further investigated.
Previous Comments:
[2009-11-11 08:26:55] srina...@php.net
Description:
with recent php 5.3.1 RC3, i noticed a crash when compiled with
mbstring and zend-multibyte and running the bug35634.phpt script found
under Zend/tests
Reproduce code:
---
'./configure' \
'--enable-cli' \
'--enable-mbstring' \
'--enable-zend-multibyte'
while running the test script Zend/tests/bug35634.phpt
__construct();
}
}
} else {
function errorHandler($errorNumber, $errorMessage, $fileName,
$lineNumber) {
define("pass3", 1);
include(__FILE__);
die("Error: $errorMessage ($fileName:$lineNumber)\n");
}
set_error_handler('errorHandler');
define("pass2", 1);
include(__FILE__);
}
?>
Expected result:
Error: Redefining already defined constructor for class TestClass
(/tmp/c.php:12)
Actual result:
--
here is the stack trace of this crash..
@1 (l...@1) program terminated by signal SEGV (no mapping at the fault
address)
Current function is _zend_mm_alloc_int
1892 ZEND_MM_CHECK_BLOCK_LINKAGE(best_fit);
(dbx 1) where
current thread: t...@1
=>[1] _zend_mm_alloc_int(heap = 0x8b7f2f0, size = 496U), line 1892 in
"zend_alloc.c"
[2] _emalloc(size = 496U), line 2295 in "zend_alloc.c"
[3] open_file_for_scanning(file_handle = 0x80454f8), line 272 in
"zend_language_scanner.l"
[4] compile_file(file_handle = 0x80454f8, type = 2), line 331 in
"zend_language_scanner.l"
[5] phar_compile_file(file_handle = 0x80454f8, type = 2), line 3390
in "phar.c"
[6] compile_filename(type = 2, filename = 0x8b910b8), line 386 in
"zend_language_scanner.l"
[7] ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER(execute_data =
0x8cd6560), line 1915 in "zend_vm_execute.h"
[8] execute(op_array = 0x8cd4438), line 104 in "zend_vm_execute.h"
[9] zend_call_function(fci = 0x80456a8, fci_cache = 0x8045608), line
942 in "zend_execute_API.c"
[10] call_user_function_ex(function_table = 0x8bbf5a0, object_pp =
(nil), function_name = 0x8b8db78, retval_ptr_ptr = 0x804572c,
param_count = 5U, params = 0x8b906d0, no_separation = 1, symbol_table =
(nil)), line 734 in "zend_execute_API.c"
[11] zend_error(type = 2048, format = 0x8b145e8 "Redefining already
defined constructor for class %s", ... = 0x8b8e730, ...), line 1101 in
"zend.c"
[12] zend_do_begin_function_declaration(function_token = 0x8045b00,
function_name = 0x8045b28, is_method = 1, return_reference = 0,
fn_flags_znode = 0x8045aec), line 1289 in "zend_compile.c"
[13] zendparse(), line 4082 in "zend_language_parser.c"
[14] compile_file(file_handle = 0x8046da8, type = 2), line 343 in
"zend_language_scanner.l"
[15] phar_compile_file(file_handle = 0x8046da8, type = 2), line 3390
in "phar.c"
[16] compile_filename(type = 2, filename = 0x8b8e4b4), line 386 in
"zend_language_scanner.l"
[17] ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER(execute_data =
0x8cd6440), line 1915 in "zend_vm_execute.h"
[18] execute(op_array = 0x8b8d970), line 104 in "zend_vm_execute.h"
[19] zend_execute_scripts(type = 8, retval = (nil), file_count = 3,
... = (nil), ...), line 1194 in "zend.c"
[20] php_execute_script(primary_file = 0x8047850), line 2225 in
"main.c"
[21] main(argc = 2, argv = 0x80478c4), line 1190 in "php_cli.c"
and here looks like best_fit seems to have been corrupted..
(dbx 2) p *best_fit
dbx: cannot access address 0x66690a70
(dbx 3) p *heap
*heap = {
use_zend_alloc = 1
_malloc= (nil)
_free = (nil)
_realloc = (nil)
free_bitmap= 1073741824U
large_free_bitmap = 133376U
block_size = 262144U
compact_size = 2097152U
segments_list = 0x8cd6410
storage= 0x8b7eef0
real_size = 524288U
real_peak = 524288U
limit = 134217728U
size = 341616U
peak = 342120U
reserve_size = 8192U
reserve= 0x8b7f560
overflow = 0
internal = 0
cached = 456U
cache = (0x8b90590, 0x8b90700, 0x8b90718, 0x8b90558,
0x8b90918, (nil), (nil), (nil), (nil), (nil), 0x8b8faa0, (nil), (nil),
(nil), (nil), 0x8b8c1e8, (nil), (nil), (nil), (nil), (nil), (nil),
(nil), (nil), (nil), (nil), (nil), (nil), (nil), (nil), (nil), (nil))
free_buckets = (0x8b7f3b8, 0x8b7f3b8, 0x8b7f3c0, 0x8b7f3c0,
0x8b7f3c8, 0x8b7f3c8, 0x8b7f3d0, 0x8b7f3d0, 0x8b7f3d8, 0x8b7f3d8,
0x8b7f3e0, 0x8
#50145 [Opn]: crash while running bug35634.phpt
ID: 50145 Updated by: srina...@php.net Reported By: srina...@php.net Status: Open Bug Type: Reproducible crash Operating System: solaris, linux PHP Version: 5.3.1RC3 Assigned To: srinatar New Comment: as i expected, this is what valgrind reports.. ==8398== Memcheck, a memory error detector. ==8398== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==8398== Using LibVEX rev 1658, a library for dynamic binary translation. ==8398== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==8398== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==8398== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==8398== For more details, rerun with: -v ==8398== ==8398== Invalid read of size 4 ==8398==at 0x82B0A73: _zend_mm_alloc_int (zend_alloc.c:1892) ==8398==by 0x82A17A7: open_file_for_scanning (zend_language_scanner.l:272) ==8398==by 0x82A1D2B: compile_file (zend_language_scanner.l:331) ==8398==by 0x82A18AD: compile_filename (zend_language_scanner.l:386) ==8398==by 0x830CE73: ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (zend_vm_execute.h:1916) ==8398==by 0x82EEA67: execute (zend_vm_execute.h:104) ==8398==by 0x82C1F35: zend_call_function (zend_execute_API.c:942) ==8398==by 0x82C29B7: call_user_function_ex (zend_execute_API.c:734) ==8398==by 0x82CD76C: zend_error (zend.c:1101) ==8398==by 0x82BC0D3: zend_do_begin_function_declaration (zend_compile.c:1289) ==8398==by 0x829CD59: zendparse (zend_language_parser.y:517) ==8398==by 0x82A1D5E: compile_file (zend_language_scanner.l:343) ==8398== Address 0x66690A70 is not stack'd, malloc'd or (recently) free'd ==8398== ==8398== Process terminating with default action of signal 11 (SIGSEGV) ==8398== Access not within mapped region at address 0x66690A70 ==8398==at 0x82B0A73: _zend_mm_alloc_int (zend_alloc.c:1892) ==8398==by 0x82A17A7: open_file_for_scanning (zend_language_scanner.l:272) ==8398==by 0x82A1D2B: compile_file (zend_language_scanner.l:331) ==8398==by 0x82A18AD: compile_filename (zend_language_scanner.l:386) ==8398==by 0x830CE73: ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (zend_vm_execute.h:1916) ==8398==by 0x82EEA67: execute (zend_vm_execute.h:104) ==8398==by 0x82C1F35: zend_call_function (zend_execute_API.c:942) ==8398==by 0x82C29B7: call_user_function_ex (zend_execute_API.c:734) ==8398==by 0x82CD76C: zend_error (zend.c:1101) ==8398==by 0x82BC0D3: zend_do_begin_function_declaration (zend_compile.c:1289) ==8398==by 0x829CD59: zendparse (zend_language_parser.y:517) ==8398==by 0x82A1D5E: compile_file (zend_language_scanner.l:343) ==8398== ==8398== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 25 from 1) ==8398== malloc/free: in use at exit: 1,475,924 bytes in 11,420 blocks. ==8398== malloc/free: 11,877 allocs, 457 frees, 1,767,115 bytes allocated. ==8398== For counts of detected errors, rerun with: -v ==8398== searching for pointers to 11,420 not-freed blocks. ==8398== checked 903,284 bytes. ==8398== ==8398== LEAK SUMMARY: ==8398==definitely lost: 0 bytes in 0 blocks. ==8398== possibly lost: 0 bytes in 0 blocks. ==8398==still reachable: 1,475,924 bytes in 11,420 blocks. ==8398== suppressed: 0 bytes in 0 blocks. ==8398== Reachable blocks (those to which a pointer was found) are not shown. Previous Comments: [2009-11-16 02:08:53] srina...@php.net looking at the source of the crash and that it happens only when used with --enable-zend-multibyte , i think, this issue has nothing to do with phar is enabled or not. (yes, it happens even if it is disabled). i think, my gut feeling it that this issue has some thing to do how to memory is allocated / reallocated when the file is being parsed with zend-multi-byte mode is enabled. just a theory at this point. i need to debug more though. any useful pointers will be much appreciated .. with respect to the platform,if you notice closely, you will notice that the bug report mentions both solaris and linux. yes, i do luv and Linux and valgrind.. unfortunately, i didn't get time to look into this last thursday and friday as I had to deal with some urgent family matters but i hope to look into this more on monday (it is still sunday for me here .. :-) ) [2009-11-15 21:54:52] ka...@php.net Just wondering, does --disable-phar change anything here? How about on other systems than Solaris? [2009-11-11 08:33:23] srina...@php.net af course, this issue is not reproduced when used with USE_ZEND_ALLOC=0. this can be a temporary work around until
#50212 [Opn]: SEGV by ldap_get_option() with LDAP_OPT_NETWORK_TIMEOUT
ID: 50212
Updated by: srina...@php.net
Reported By: shigeru_kitazaki at cybozu dot co dot jp
Status: Open
Bug Type: LDAP related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
thanks for trying it out and providing us the patch.
i have changed the patch to be some thing like below
Index: ext/ldap/ldap.c
===
--- ext/ldap/ldap.c (revision 290898)
+++ ext/ldap/ldap.c (working copy)
@@ -1592,6 +1592,8 @@
RETURN_FALSE;
}
zval_dtor(retval);
+ if (!timeout)
+ RETURN_FALSE;
ZVAL_LONG(retval, timeout->tv_sec);
ldap_memfree(timeout);
} break;
--- /dev/null 2009-11-15 17:50:37.203856521 -0800
+++ ext/ldap/tests/ldap_get_option_timeout.phpt 2009-11-17
19:58:38.0 -0800
@@ -0,0 +1,20 @@
+--TEST--
+ldap_get_option() - Basic ldap_get_option() operation
+--SKIPIF--
+
+--FILE--
+
+===DONE===
+--EXPECT--
+bool(true)
+int(3)
+===DONE===
I don't have any ldap server running. so, i will hope some one can
verify if this above test is running fine before they can commit it
see also bug #42837 (http://bugs.php.net/bug.php?id=42837).
Previous Comments:
[2009-11-18 01:29:29] shigeru_kitazaki at cybozu dot co dot jp
Description:
NULL pointer access occurs to get option value when no option value is
set on LDAP_OPT_NETWORK_TIMEOUT.
ldap_get_option() of OpenLDAP returns success when no value is set,
which is implemented in libraries/libldap/options.c of OpenLDAP source
tree.
But original PHP source code try to access property value.
Here is the patch to resolve this.
diff -Nrub php-5.3.0/ext/ldap/ldap.c php-5.3.0.ldap/ext/ldap/ldap.c
--- php-5.3.0/ext/ldap/ldap.c 2009-06-26 00:19:29.0 +0900
+++ php-5.3.0.ldap/ext/ldap/ldap.c 2009-11-17 18:19:20.0 +0900
@@ -1619,9 +1619,13 @@
}
RETURN_FALSE;
}
+ if (timeout) {
zval_dtor(retval);
ZVAL_LONG(retval, timeout->tv_sec);
ldap_memfree(timeout);
+ } else {
+ RETURN_FALSE;
+ }
} break;
#elif defined(LDAP_X_OPT_CONNECT_TIMEOUT)
case LDAP_X_OPT_CONNECT_TIMEOUT:
Although manual page of ldap.constants says LDAP_OPT_NETWORK_TIMEOUT is
the option for ldap_set_option(),
the parameter is also available on function.ldap-get-option.
Reproduce code:
---
http://bugs.php.net/?id=50212&edit=1
#50159 [Opn->Fbk]: wrong working directory in symlinked files
ID: 50159
Updated by: srina...@php.net
Reported By: cwei...@php.net
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: *
PHP Version: 5.3.1RC3
New Comment:
hi,
in my quick investigation, i think the issue is we are doing chdir to
the absolute path of given uri (which is a change in behavior compared
to 5.2).
here is a rough draft like patch that seems to alleviate this problem.
[srir...@tim-vm2]'PHP_5_3'>svn diff main/fopen_wrappers.c
Index: main/fopen_wrappers.c
===
--- main/fopen_wrappers.c (revision 290898)
+++ main/fopen_wrappers.c (working copy)
@@ -386,7 +386,7 @@
#ifndef PHP_WIN32
struct stat st;
#endif
- char *path_info, *filename;
+ char *path_info, *filename, *orig_filename;
int length;
filename = SG(request_info).path_translated;
@@ -455,6 +455,7 @@
} /* if doc_root && path_info */
if (filename) {
+ orig_filename = estrdup(filename);
filename = zend_resolve_path(filename,
strlen(filename) TSRMLS_CC);
}
@@ -488,8 +489,15 @@
STR_FREE(SG(request_info).path_translated); /* for same
reason as above */
SG(request_info).path_translated = filename;
- file_handle->filename = SG(request_info).path_translated;
- file_handle->free_filename = 0;
+ if (orig_filename) {
+ file_handle->filename = orig_filename;
+ file_handle->free_filename = 1;
+ }
+ else {
+ file_handle->filename =
SG(request_info).path_translated;
+ file_handle->free_filename = 0;
+ }
+
file_handle->handle.fp = fp;
file_handle->type = ZEND_HANDLE_FP;
applying this patch , seems to work. af course, more thought need to
go on this before this can be committed.
Previous Comments:
[2009-11-13 08:36:53] j...@php.net
So no need to ask Dmitry then. :)
[2009-11-12 22:24:59] cwei...@php.net
I reverted
<@Jani_> svn diff -r263054:263055
with patch -R, but that did not help. I still get the symlink directory
reported when running
[2009-11-12 17:02:06] j...@php.net
Dmitry, I think this patch of yours caused this:
http://svn.php.net/viewvc?view=revision&revision=263055
Any comments?
[2009-11-12 16:44:52] j...@php.net
See also bug #46814 (reported for 5.2.8 actually..)
[2009-11-12 16:44:40] cwei...@php.net
sapi is fastcgi
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/50159
--
Edit this bug report at http://bugs.php.net/?id=50159&edit=1
#50281 [Fbk]: Socket shuts down automatically after X seconds of idling
ID: 50281 Updated by: srina...@php.net Reported By: jiangcat at gmail dot com Status: Feedback Bug Type: Sockets related Operating System: Centos 5.2 PHP Version: 5.2.11 New Comment: cool you are running it on linux. now, to help us debug this issue, provide a strace(1) output (just before the socket timeout happens). say, you see that socket times out at 3 hours or some thing like that, then you could do some thing like start the strace collection output around this time and paste the last few hundred lines some where. this should help us understand why did the socket time out when it happens Previous Comments: [2009-11-24 17:22:29] ka...@php.net Please somehow attach the code to the bug report else theres not really anything we can do to analyze the issue. Try upload a zip somewhere if its many files or use a paste service like Pastie. Also keep the reproduce code as short as possible, when you have attached the code to this report then change the status back to 'Open' [2009-11-24 09:46:07] jiangcat at gmail dot com Description: I've made a chat server using php socket features, and it works pretty well as I've expected. However, the server shuts down automatically after about 3 hours of idling (no connections). I've set the php execution time limit to 0, and running this script from shell in the background. Can't think of any other reason causing this strange behavior. Reproduce code: --- The code is too long to submit. -- Edit this bug report at http://bugs.php.net/?id=50281&edit=1
#50276 [Opn->Fbk]: PHP cache headers do NOT override server headers
ID: 50276
Updated by: srina...@php.net
Reported By: vector dot thorn at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Apache2 related
Operating System: Fedora Linux
PHP Version: 5.3.1
New Comment:
can you kindly rephrase your question. i am not too sure i understand
your question here.
If I understand you correctly, you want to find out a way so that
client (like browser) can request this page with 'If-Modified-Since' in
its header so that the server doesn't have to send it again.
if this is your question, then this is a server configuration issue and
nothing to do with a php engine.
Previous Comments:
[2009-11-24 00:50:29] vector dot thorn at gmail dot com
Description:
If this section is in your httpd.conf:
Header unset Cache-Control
Header unset Expires
Header unset Last-Modified
FileETag None
Header unset Pragma
Then the cache headers here will not be used:
$expires = 60*60*24*365;
$size = filesize("{$client_directory}/{$_GET['did']}");
$last = filemtime("{$client_directory}/{$_GET['did']}");
header("Content-Length: ".$size,true);
header("Etag: ".md5($last),true);
header("Server: Ionisis.com",false);
header("Cache-Control: max-age={$expires}, public,no-transform",true);
header('Expires: ' . gmdate('D, d M Y H:i:s',($last+$expires)) . '
GMT',true);
header('Last-Modified: ' . gmdate('D, d M Y H:i:s', $last) . '
GMT',true);
header("Content-type: audio/example");
header("Content-Disposition: attachment;
filename=\"{$_GET['did']}\"");
readfile("{$client_directory}/{$_GET['did']}");
and even if you remove that section, and these headers are sent, the
client is still not sending a "if-modified-since" header that can be
captured at the server level for the php level.
Firefox 3.5, Apache 2.2, PHP 5.3, Fedora Linux
Reproduce code:
---
Just copy that code, and paste it in an file called download.php, and
set it up so that it grabs an mp3 file, then beat your head into the
desk for 2 days :D
Expected result:
I expected it to send the proper cache headers, despite what the server
was preconfigured to send.
Actual result:
--
Had to remove the server's configuration section pertaining to caching
php output.
--
Edit this bug report at http://bugs.php.net/?id=50276&edit=1
Bug #51183 [Asn]: ext/date/php_date.c fails to compile with Sun Studio and PHP 5.2.13
Edit report at http://bugs.php.net/bug.php?id=51183&edit=1
ID: 51183
Updated by: srina...@php.net
Reported by: markus dot schiegl at lbbw dot de
Summary: ext/date/php_date.c fails to compile with Sun Studio
and PHP 5.2.13
Status: Assigned
Type: Bug
Package: Compile Failure
Operating System: Solaris 10 (Sparc)
PHP Version: 5.2.13
Assigned To: derick
New Comment:
with sun studio 12 update, __inline is now recognized as synonymous for
inline. this patch makes this code compilable on all platforms
[sn123...@bflat]'php-5.3.2'>diff -u ext/date/php_date.c.ORIG
ext/date/php_date.c--- ext/date/php_date.c.ORIGMon May 31 08:38:45
2010
+++ ext/date/php_date.c Mon May 31 08:33:34 2010
@@ -36,7 +36,7 @@
#elif defined(__GNUC__) && __GNUC__ < 3
static __inline __int64_t php_date_llabs( __int64_t i ) { return i >= 0
? i : -i; }
#else
-static __inline long long php_date_llabs( long long i ) { return i >= 0
? i : -i; }
+static inline long long php_date_llabs( long long i ) { return i >= 0 ?
i : -i; }
#endif
(C99 standard does support inline keyword)
I can commit this bug, if no one has any objections to it.
Previous Comments:
[2010-03-15 18:16:17] uklaus at hgb-leipzig dot de
for the records,
Sun Studio 11 compiler on Solaris 10 Sparc: doesn't compile
Sun Studio 12 compiler on Solaris 10 Sparc: doesn't compile
Sun Studio 12 Update 1 compiler on Solaris 10 Sparc: compiles
[2010-03-10 11:02:49] jose-marcio dot martins at mines-paristech dot fr
I submited this patch as it's simple and will work for every combination
of OS and compiler.
But the result is that php_date_llabs function isn't defined as inline.
This may be an important performance issue only if this function is
called very very frequently (I don't know if this hypothesis is true and
I don't believe).
The correct solution could be to redefine this with some other checks in
order to use the correct inline declaration syntax. Another solution, as
this is a really simple function is to declare it as a macro. Something
of the kind :
#define php_date_llabs(i) ((long long) ((i) >= 0 ? (i) : -(i))
[2010-03-08 20:26:07] rcshishe at cord dot edu
This also affects Solaris 10 x86 with Sun Studio compiler.
[2010-03-05 11:42:12] markus dot schiegl at lbbw dot de
Jose Marcio, thanks for the patch. Compiles and works fine now!
[2010-03-02 13:25:22] markus dot schiegl at lbbw dot de
Description:
PHP 5.2.13 doesn't compile with Sun Studio compiler on Solaris 10 Sparc.
Configure works fine (as in 5.2.12), Make fails on ext/date/php_date.c
file with:
/bin/sh /opt/build/php/php-5.2.13/libtool --silent --preserve-dup-deps
--mode=compile cc -Iext/date/lib -Iext/date/
-I/opt/build/php/php-5.2.13/ext/d
ate/ -DPHP_ATOM_INC -I/opt/build/php/php-5.2.13/include
-I/opt/build/php/php-5.2.13/main -I/opt/build/php/php-5.2.13
-I/opt/build/php/php-5.2.13/ext/
date/lib -I/opt/build/php/ext/libxml2/include/libxml2 -I/usr/sfw/include
-I/opt/build/php/ext/curl/include -I/opt/build/php/ext/jpeg/include
-I/opt/b
uild/php/ext/freetype2/include
-I/opt/build/php/ext/freetype2/include/freetype2
-I/opt/build/php/ext/gettext/include -I/opt/build/php/ext/libiconv/in
clude -I/opt/build/php/php-5.2.13/ext/mbstring/oniguruma
-I/opt/build/php/php-5.2.13/ext/mbstring/libmbfl
-I/opt/build/php/php-5.2.13/ext/mbstring/li
bmbfl/mbfl -I/opt/build/php/ext/libmcrypt/include
-I/opt/build/php/ext/freetds/include -I/opt/build/php/ext/mysql/include
-I/opt/build/php/ext/instan
tclient/sdk/include -I/opt/build/php/ext/tidy/include
-I/opt/build/php/ext/xmlrpc-epi/include
-I/opt/build/php/ext/libxslt/include -I/opt/build/php/p
hp-5.2.13/TSRM -I/opt/build/php/php-5.2.13/Zend
-I/opt/build/php/php/ext/libiconv/include
-I/opt/build/php/php/ext/gettext/include -D_POSIX_PTHREAD_
SEMANTICS -I/opt/build/php/ext/libiconv/include -O -xs -xstrconst
-zlazyload -xmemalign=8s -c
/opt/build/php/php-5.2.13/ext/date/php_date.c -o ext/
date/php_date.lo
"/opt/build/php/php-5.2.13/ext/date/php_date.c", line 38: warning: no
explicit type given
"/opt/build/php/php-5.2.13/ext/date/php_date.c", line 38: syntax error
before or at: long
cc: acomp failed for /opt/build/php/php-5.2.13/ext/date/php_date.c
*** Error code 1
make: Fatal error: Command failed for target `ext/date/php_date.lo'
A diff between 5.2.12 and 5.2.13 shows the culprit (php_date_llabs vs.
llabs and/or ifndef HAVE_LLABS, because of bug 50266 and bug 50930)
@@ -30,14 +30,12 @@
#include "lib/timelib.h"
#include
-#ifndef HAVE_LLABS
-#
Req #51869 [Bgs->Dup]: LDAP pagination support
Edit report at http://bugs.php.net/bug.php?id=51869&edit=1
ID: 51869
Updated by: srina...@php.net
Reported by: jeanseb at au-fil-du dot net
Summary: LDAP pagination support
-Status: Bogus
+Status: Duplicate
Type:Feature/Change Request
Package: LDAP related
PHP Version: 5.2.13
New Comment:
- marking this bug as duplicate rather than bogus.
Previous Comments:
[2010-05-21 17:31:34] jeanseb at au-fil-du dot net
Done.
http://bugs.php.net/bug.php?id=42060
Thanks for your answer.
[2010-05-20 15:24:25] paj...@php.net
Duplicate request, see #42060.
Pls keep in mind that 5.2/3 are in bug fixes mode only. If you can
update the patch to make it work against svn's trunk, then I can review,
test and apply it.
Please post any further comments in the bug #42060.
[2010-05-20 11:37:59] jeanseb at au-fil-du dot net
Description:
LDAP protocol v3 add the pagination feature to LDAP search.
Currently PHP doesn't support this.
Pierangelo Masarati and Iñaki Arenaza
made a patch with some other features.
I extracted the pagination feature and add some phpt.
This patch is based on the PHP 5.2 branch (I will produce a trunk & php
5.3 implementation soon).
rfc2696 : http://www.ietf.org/rfc/rfc2696.txt
Original patch :
http://www.eteo.mondragon.edu/descargas/php-ldap/diff-php-src-5-2-12.patch
Test script:
---
$ds = ldap_connect($ldapHost, $ldapPort);
ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_bind($ds, $ldapUser, $ldapPass);
$cookie = '';
do {
ldap_ctrl_paged_results($ds, $pageSize, true, $cookie);
$result = ldap_search($ds, $dn, $filter, $justthese);
$entries = ldap_get_entries($ds, $result);
ldap_ctrl_paged_results_resp($ds, $result, $cookie);
} while($cookie !== null && $cookie != '');
--
Edit this bug report at http://bugs.php.net/bug.php?id=51869&edit=1
Bug #51183 [Asn->Csd]: ext/date/php_date.c fails to compile with Sun Studio and PHP 5.2.13
Edit report at http://bugs.php.net/bug.php?id=51183&edit=1
ID: 51183
Updated by: srina...@php.net
Reported by: markus dot schiegl at lbbw dot de
Summary: ext/date/php_date.c fails to compile with Sun Studio
and PHP 5.2.13
-Status: Assigned
+Status: Closed
Type: Bug
Package: Compile Failure
Operating System: Solaris 10 (Sparc)
PHP Version: 5.2.13
-Assigned To: derick
+Assigned To: srinatar
New Comment:
Committed revision 300294.
- Tested and verified it to compile on linux, mac and solaris.
Previous Comments:
[2010-05-31 17:50:24] srina...@php.net
with sun studio 12 update, __inline is now recognized as synonymous for
inline. this patch makes this code compilable on all platforms
[sn123...@bflat]'php-5.3.2'>diff -u ext/date/php_date.c.ORIG
ext/date/php_date.c--- ext/date/php_date.c.ORIGMon May 31 08:38:45
2010
+++ ext/date/php_date.c Mon May 31 08:33:34 2010
@@ -36,7 +36,7 @@
#elif defined(__GNUC__) && __GNUC__ < 3
static __inline __int64_t php_date_llabs( __int64_t i ) { return i >= 0
? i : -i; }
#else
-static __inline long long php_date_llabs( long long i ) { return i >= 0
? i : -i; }
+static inline long long php_date_llabs( long long i ) { return i >= 0 ?
i : -i; }
#endif
(C99 standard does support inline keyword)
I can commit this bug, if no one has any objections to it.
[2010-03-15 18:16:17] uklaus at hgb-leipzig dot de
for the records,
Sun Studio 11 compiler on Solaris 10 Sparc: doesn't compile
Sun Studio 12 compiler on Solaris 10 Sparc: doesn't compile
Sun Studio 12 Update 1 compiler on Solaris 10 Sparc: compiles
[2010-03-10 11:02:49] jose-marcio dot martins at mines-paristech dot fr
I submited this patch as it's simple and will work for every combination
of OS and compiler.
But the result is that php_date_llabs function isn't defined as inline.
This may be an important performance issue only if this function is
called very very frequently (I don't know if this hypothesis is true and
I don't believe).
The correct solution could be to redefine this with some other checks in
order to use the correct inline declaration syntax. Another solution, as
this is a really simple function is to declare it as a macro. Something
of the kind :
#define php_date_llabs(i) ((long long) ((i) >= 0 ? (i) : -(i))
[2010-03-08 20:26:07] rcshishe at cord dot edu
This also affects Solaris 10 x86 with Sun Studio compiler.
[2010-03-05 11:42:12] markus dot schiegl at lbbw dot de
Jose Marcio, thanks for the patch. Compiles and works fine now!
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/bug.php?id=51183
--
Edit this bug report at http://bugs.php.net/bug.php?id=51183&edit=1
Bug #52035 [Opn]: Header Redirect Fails
Edit report at http://bugs.php.net/bug.php?id=52035&edit=1
ID: 52035
Updated by: srina...@php.net
Reported by: mchotai at fulcrum dot ca
Summary: Header Redirect Fails
Status: Open
Type: Bug
Package: HTTP related
Operating System: Microsoft-IIS/7.0
PHP Version: 5.2.13
New Comment:
most likely not a valid bug. pl. check the log file to see if you have
reached the maximum number of redirects.
Previous Comments:
[2010-06-09 19:45:08] mchotai at fulcrum dot ca
Description:
Hi,
I've encountered a bug in PHP 5.2.13 that doesn't happen in PHP 5.2.10.
My header redirect statement doesn't produce a redirect. No error is
reported.
The line that causes the bug is simply:
header("location:store.php");
In the raw HTTP stream, I can see the redirect information missing
(using ExamDiff on the output shown using LiveHTTPHeaders with Firefox).
I am using two servers which are exactly the same (as they are virtual
machines), both running same IIS, ASP.NET version, etc. The only
difference was the PHP version. When I changed the version back to
5.2.10, both servers worked exactly the same. When I set one to 5.2.13,
it wouldn't do the redirect to the page above.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52035&edit=1
Bug #52035 [Opn->Fbk]: Header Redirect Fails
Edit report at http://bugs.php.net/bug.php?id=52035&edit=1
ID: 52035
Updated by: srina...@php.net
Reported by: mchotai at fulcrum dot ca
Summary: Header Redirect Fails
-Status: Open
+Status: Feedback
Type: Bug
Package: HTTP related
Operating System: Microsoft-IIS/7.0
PHP Version: 5.2.13
Previous Comments:
[2010-06-11 14:00:54] srina...@php.net
most likely not a valid bug. pl. check the log file to see if you have
reached the maximum number of redirects.
[2010-06-09 19:45:08] mchotai at fulcrum dot ca
Description:
Hi,
I've encountered a bug in PHP 5.2.13 that doesn't happen in PHP 5.2.10.
My header redirect statement doesn't produce a redirect. No error is
reported.
The line that causes the bug is simply:
header("location:store.php");
In the raw HTTP stream, I can see the redirect information missing
(using ExamDiff on the output shown using LiveHTTPHeaders with Firefox).
I am using two servers which are exactly the same (as they are virtual
machines), both running same IIS, ASP.NET version, etc. The only
difference was the PHP version. When I changed the version back to
5.2.10, both servers worked exactly the same. When I set one to 5.2.13,
it wouldn't do the redirect to the page above.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52035&edit=1
Bug #52035 [Fbk]: Header Redirect Fails
Edit report at http://bugs.php.net/bug.php?id=52035&edit=1 ID: 52035 Updated by: srina...@php.net Reported by: mchotai at fulcrum dot ca Summary: Header Redirect Fails Status: Feedback Type: Bug Package: HTTP related Operating System: Microsoft-IIS/7.0 PHP Version: 5.2.13 New Comment: I am able to redirect successfully with latest php source snapshot. can u pl. attach the output of live http headers to this ? u could do some thing like below from the command line window (start->run->cmd) telnet localhost 80 GET /http://bugs.php.net/bug.php?id=52035&edit=1
Bug #52081 [Csd->Bgs]: SOAPClient makes calls, throws weird Exception anyway
Edit report at http://bugs.php.net/bug.php?id=52081&edit=1 ID: 52081 Updated by: srina...@php.net Reported by: jeroen at asystance dot nl Summary: SOAPClient makes calls, throws weird Exception anyway -Status: Closed +Status: Bogus Type: Bug Package: SOAP related Operating System: Linux (Debian/Ubuntu) PHP Version: 5.3.2 New Comment: mark the bug as bogus to make it appropriate. Previous Comments: [2010-06-14 15:31:36] jeroen at asystance dot nl sorry, bogus bug report! [2010-06-14 14:38:24] jeroen at asystance dot nl Description: I'm trying to get a SOAPClient call to work which HAS worked (about half a year ago), but which now throws weird Exceptions, even though the call is made. Unzip http://jayvee.nl/soaptest.zip and open soaptest.php. (Note that the WSDL specifies a URL for the service which is on our development environment. You can use this URL if you want.) The script tries to call the same operation four times. The different scenarios are: a) WSDL specifies output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature b) WSDL specifies output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature c) WSDL specifies NO output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature d) WSDL specifies NO output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature In each case, a call IS MADE. However, in cases a-c, I get an Exception: "SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity "implementations/nsure/interface/WizBizzInterface.wsdl" I have no idea where this path comes from. I _have_ used this in the past, but the test case does not use it. It seems this fault description has gotten stuck somewhere. I have disabled APC, checked for cached WSDLs in /tmp and rebooted the (virtual) machine, to no avail. Case d returns NULL, which is correct (WSDL operation specifies NO output). Note that although the SOAPClient uses the same WSDL as in case c, now it is not complaining about an unfindable path. I have tested this on PHP 5.2.13 (Ubuntu) and 5.3.2 (Debian), both using Suhosin patch, on Apache 2.2.x. -- I really hope this gets fixed soon, because I need to take this into production in a month or two. However, since three other SOAP bug reports (49155, 49169, 49278) haven't been addressed for almost a year, I'm left wondering whether I should have spent time creating a fourth bug report instead of looking for an alternative (nuSOAP or something). Test script: --- Download http://jayvee.nl/soaptest.zip and run the php script. Expected result: Web service return parameter Actual result: -- SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity "implementations/nsure/interface/WizBizzInterface.wsdl -- Edit this bug report at http://bugs.php.net/bug.php?id=52081&edit=1
Bug #51988 [Opn->Bgs]: No input file specfied when trying to exec any PHP script from Web Server
Edit report at http://bugs.php.net/bug.php?id=51988&edit=1
ID: 51988
Updated by: srina...@php.net
Reported by: pedro dot galan at cscamaras dot es
Summary: No input file specfied when trying to exec any PHP
script from Web Server
-Status: Open
+Status: Bogus
Type: Bug
Package: CGI related
Operating System: SunOS 5.8 sparc
PHP Version: 5.2.13
New Comment:
This is not a PHP bug but a configuration issue.
Please contact the ariate web server forum in this case
http://forums.sun.com/forum.jspa?forumID=759 and post your question
there.
Previous Comments:
[2010-06-10 21:47:15] pedro dot galan at cscamaras dot es
I've verfied that scripts using PHP Cli executable work fine with my Web
Server but the problem with PHP Cgi executable ramain the same.
So, PHP Cli allows to execute PHP scripts across Sun Java System Web
Server 6.1 but PHP Cgi products "no input file specified".
[2010-06-03 14:03:53] pedro dot galan at cscamaras dot es
Description:
When trying to run any PHP script from my Web Server (Sun Java System
Web Server 6.1) as CGI always get "No input file specified".
Configure options:
./configure --with-curl --with-mysql=/usr/local/mysql
--prefix=/usr/local/php5 --with-config-file-path=/usr/local/php5/lib
-enable-force-cgi-redirect
Changed PUTS("No input file specifiedd.\n"); by
PUTS(zend_printf("%s",file_handle.filename)); at line 1947 in cgi_main.c
and what i can see at the browser is (null) so the problem is with
path_translated for sure.
I've a lot of PHPP4.1 scripts running at the same Web server so the
configurantion is the same. It is not too probalbe that the problem is
at the Web Server.
Thanks a lot.
Test script:
---
matrix /data/web_html/publicado/empresafamiliar/php5 425 #more
phpinfo5.php
#!/usr/local/bin/php5
Expected result:
I expect an HTML page with the result of the phpinfo function.
Actual result:
--
No input file specified
--
Edit this bug report at http://bugs.php.net/bug.php?id=51988&edit=1
Bug #51424 [Asn]: crypt() function hangs after 3rd call
Edit report at http://bugs.php.net/bug.php?id=51424&edit=1
ID: 51424
Updated by: srina...@php.net
Reported by: laacz at laacz dot lv
Summary: crypt() function hangs after 3rd call
Status: Assigned
Type: Bug
Package: Strings related
Operating System: Ubuntu 9.04 x64
PHP Version: 5.3.2
Assigned To: pajoye
New Comment:
hi laacz at laacz dot lv
can u please try with this patch and see if this addresses u r issue
to apply this patch, u will need to save the below contents into a file
and
run
cd php-5.3.2
patch -d . <
gmake clean
gmake
--- ext/standard/php_crypt_r.c.orig Wed Jun 16 05:59:16 2010
+++ ext/standard/php_crypt_r.c Wed Jun 16 06:00:17 2010
@@ -81,9 +81,7 @@
tsrm_mutex_lock(php_crypt_extended_init_lock);
#endif
- if (initialized) {
- return;
- } else {
+ if (!initialized) {
_crypt_extended_init();
initialized = 1;
}
Previous Comments:
[2010-06-15 15:43:34] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300466
Log: - #51424, silent warnings on win
[2010-06-15 11:26:24] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300460
Log: - Fix #51424, crypt() function hangs after 3rd call
[2010-06-15 11:26:10] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300459
Log: - Fix #51424, crypt() function hangs after 3rd call
[2010-06-05 01:18:27] tallyce at gmail dot com
Also confirmed third call hang on Win7/Apache2.2/PHP5.3.2.
Can anyone suggest a workaround until the next release?
[2010-05-27 02:34:10] thbley at gmail dot com
Same problem on windows (5.3.2 binary, php5apache2_2.dll):
Run 2 requests in parallel:
for ($i=0; $i<50; $i++) {
crypt('a', '_');
}
ab -n 1 -c 1 http://localhost/test.php
=> ~1 second, ok
ab -n 2 -c 2 http://localhost/test.php
=> hangs
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/bug.php?id=51424
--
Edit this bug report at http://bugs.php.net/bug.php?id=51424&edit=1
Bug #51424 [Asn]: crypt() function hangs after 3rd call
Edit report at http://bugs.php.net/bug.php?id=51424&edit=1
ID: 51424
Updated by: srina...@php.net
Reported by: laacz at laacz dot lv
Summary: crypt() function hangs after 3rd call
Status: Assigned
Type: Bug
Package: Strings related
Operating System: *
PHP Version: 5.3.2
Assigned To: pajoye
New Comment:
i have attached a patch to add membar functionality for solaris. af
course, this would be more relevant if we want to remove the tsrm lock
around this.
Previous Comments:
[2010-06-16 16:30:30] paj...@php.net
This patch was what I proposed initially, it only reduces the risk but
does not fix all cases.
What I committed is over safe as we could remove the tsrm lock. However
I do need to know how we can do the membar on solaris.
[2010-06-16 15:04:02] srina...@php.net
hi laacz at laacz dot lv
can u please try with this patch and see if this addresses u r issue
to apply this patch, u will need to save the below contents into a file
and
run
cd php-5.3.2
patch -d . <
gmake clean
gmake
--- ext/standard/php_crypt_r.c.orig Wed Jun 16 05:59:16 2010
+++ ext/standard/php_crypt_r.c Wed Jun 16 06:00:17 2010
@@ -81,9 +81,7 @@
tsrm_mutex_lock(php_crypt_extended_init_lock);
#endif
- if (initialized) {
- return;
- } else {
+ if (!initialized) {
_crypt_extended_init();
initialized = 1;
}
[2010-06-15 15:43:34] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300466
Log: - #51424, silent warnings on win
[2010-06-15 11:26:24] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300460
Log: - Fix #51424, crypt() function hangs after 3rd call
[2010-06-15 11:26:10] paj...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=300459
Log: - Fix #51424, crypt() function hangs after 3rd call
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/bug.php?id=51424
--
Edit this bug report at http://bugs.php.net/bug.php?id=51424&edit=1
Bug #52162 [Opn]: custom request header variables with numbers are removed
Edit report at http://bugs.php.net/bug.php?id=52162&edit=1
ID: 52162
Updated by: srina...@php.net
Reported by: srina...@php.net
Summary: custom request header variables with numbers are
removed
Status: Open
Type: Bug
Package: iPlanet related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
here is the suggested patch to address this issue
[sn123...@mbelshe]'PHP_5_3'>svn diff sapi/nsapi/nsapi.c
Index: sapi/nsapi/nsapi.c
===
--- sapi/nsapi/nsapi.c (revision 300702)
+++ sapi/nsapi/nsapi.c (working copy)
@@ -687,7 +687,7 @@
if (value) {
for(p = value + pos; *p; p++) {
*p = toupper(*p);
- if (*p < 'A' || *p >
'Z') {
+ if (!isalnum(*p)) {
*p = '_';
}
}
if no one has any issues, i can commit this patch..
Previous Comments:
[2010-06-23 19:02:30] srina...@php.net
Description:
for example, if u try to request print-header.php (which contains the
following)
$v) {
print " $k = $v\n";
}
print "\n";
?>
by doing some thing like
$ telnet localhost 80
Trying 192.168.20.126...
Connected to s10u7x.
Escape character is '^]'.
GET /print-header.php HTTP/1.0
X-T3crawler: foobar
u get output as
HTTP_X_T_CRAWLER = foobar -> unexpected result
what do u expect is
HTTP_X_T3_CRAWLER = foobar -> expected result
Expected result:
HTTP_X_T3_CRAWLER = foobar -> expected result
Actual result:
--
u get output as
HTTP_X_T_CRAWLER = foobar -> unexpected result
--
Edit this bug report at http://bugs.php.net/bug.php?id=52162&edit=1
Req #51551 [Opn]: Include custom HTTP headers in request
Edit report at http://bugs.php.net/bug.php?id=51551&edit=1
ID: 51551
Updated by: srina...@php.net
Reported by: ed at atl dot org
Summary: Include custom HTTP headers in request
Status: Open
Type: Feature/Change Request
Package: SOAP related
Operating System: ALL
PHP Version: 5.3SVN-2010-04-13 (SVN)
-Assigned To:
+Assigned To: srinatar
New Comment:
I agree, it is very useful. I will look more into this patch. thanks for
the
suggested patch
Previous Comments:
[2010-04-13 18:46:30] ed at atl dot org
Description:
When creating a soap client, I would also like to be able to identify
custom HTTP headers.
See attached patch, please include in next release (which will also
require the documentation to be included)
Test script:
---
$client = new
SoapClient('http://london:8180/testing/headerserver.php?wsdl',
array(
"trace"=>true,
"custom_http_header"=>"New: test header"
));
--
Edit this bug report at http://bugs.php.net/bug.php?id=51551&edit=1
Bug #51216 [Opn->Fbk]: Segmentation fault when compiling PHP with PHAR
Edit report at http://bugs.php.net/bug.php?id=51216&edit=1 ID: 51216 Updated by: srina...@php.net Reported by: dtm2mcs at gmail dot com Summary: Segmentation fault when compiling PHP with PHAR -Status: Open +Status: Feedback Type: Bug Package: PHAR related Operating System: Ubuntu 6.04 + CentOS 5.4 PHP Version: 5.3.2 New Comment: please see if this issue can be reproduced with php 5.3.3 (RC2)- http://qa.php.net/ and if yes, please provide us a stack trace as mentioned here. http://bugs.php.net/bugs-generating-backtrace.php Previous Comments: [2010-07-08 17:00:24] bluefox012 at gmail dot com centos 5.4 have the same problem, [activating module `php5' in /home/services/web/config/httpd.conf] Installing PHP CLI binary:/usr/local/php/bin/ Installing PHP CLI man page: /usr/local/php/man/man1/ Installing build environment: /usr/local/php/lib/php/build/ Installing header files: /usr/local/php/include/php/ Installing helper programs: /usr/local/php/bin/ program: phpize program: php-config Installing man pages: /usr/local/php/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/php/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 [2010-05-08 00:54:01] leonard dot f dot elia at nasa dot gov So, I tried compiling without phar: ./configure --prefix=/usr/local/php532-dist \ --with-curl=/usr/local --enable-exif --with-gd \ --with-nsapi=/usr/local/iplanet7 \ --with-mysql=/usr/local/mysql-client/mysql-5.1.40 \ --with-mysqli=/usr/local/mysql/bin/mysql_config \ --with-oci8=instantclient,/usr/local/oracle \ --with-pdo-mysql=/usr/local/mysql-client/mysql-5.1.40 \ --with-pdo-oci=/usr/local/oracle \ --with-jpeg-dir=/usr/local --with-png-dir=/usr/local \ --enable-libgcc \ --disable-phar The make now completes as expected but make install now throws up: [r...@allegro php5]# make install Installing PHP SAPI module: nsapi Installing PHP CLI binary:/usr/local/php532-dist/bin/ Installing PHP CLI man page: /usr/local/php532-dist/man/man1/ Installing build environment: /usr/local/php532-dist/lib/php/build/ Installing header files: /usr/local/php532-dist/include/php/ Installing helper programs: /usr/local/php532-dist/bin/ program: phpize program: php-config Installing man pages: /usr/local/php532-dist/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/php532-dist/lib/php/ Segmentation Fault make[1]: *** [install-pear-installer] Error 139 make: *** [install-pear] Error 2 And this bug, my friends, isn't in the bug database (that I have found). Any ideas? My system has a working php in the path (5.3.1) and is up to date on patches etc. [2010-05-07 23:52:55] leonard dot f dot elia at nasa dot gov Almost forgot, I am building php 5.3.2 as a NSAPI module for iPlanet 7 using mysql 5.1.40 ./configure --prefix=/usr/local/php532-dist \ --with-curl=/usr/local --enable-exif --with-gd \ --with-nsapi=/usr/local/iplanet7 \ --with-mysql=/usr/local/mysql-client/mysql-5.1.40 \ --with-mysqli=/usr/local/mysql/bin/mysql_config \ --with-oci8=instantclient,/usr/local/oracle \ --with-pdo-mysql=/usr/local/mysql-client/mysql-5.1.40 \ --with-pdo-oci=/usr/local/oracle \ --with-jpeg-dir=/usr/local --with-png-dir=/usr/local \ --enable-libgcc thank you [2010-05-07 23:50:26] leonard dot f dot elia at nasa dot gov I am getting this bug with gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) GNU Make 3.81 built for sparc-sun-solaris2.10 SunOS xxx 5.10 Generic_142900-01 sun4u sparc SUNW,Sun-Fire-480R Solaris Memory: 1024M phys mem, 608M free mem, 2048M total swap, 2018M free swap Any workarounds are gratefully appreciated [2010-04-22 10:24:02] ywliu at hotmail dot com I can confirm this one: 1. On CentOS 5.4 2. Apache Worker MPM. 3. With mysqlnd, it wouldn't trigger segfault. But with external mysql library (my own build of 5.0.81) , it segfaults. So looks like maybe it's the combination of worker MPM with the external mysql library. ywliu 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/bug.php?id=51216 -- Edit this bug report at http://bugs.php.net/bug.php?id=51216&edit=1
Bug #51216 [Fbk->Bgs]: Segmentation fault when compiling PHP with PHAR
Edit report at http://bugs.php.net/bug.php?id=51216&edit=1 ID: 51216 Updated by: srina...@php.net Reported by: dtm2mcs at gmail dot com Summary: Segmentation fault when compiling PHP with PHAR -Status: Feedback +Status: Bogus Type: Bug Package: PHAR related Operating System: Ubuntu 6.04 + CentOS 5.4 PHP Version: 5.3.2 New Comment: closing it as not reproducible with latest release (5.3.3) Previous Comments: [2010-07-14 04:51:15] ywliu at hotmail dot com Just tried 5.3.3RC2. This problem on the latest CentOS 5.5 is gone. [2010-07-13 23:01:20] srina...@php.net please see if this issue can be reproduced with php 5.3.3 (RC2)- http://qa.php.net/ and if yes, please provide us a stack trace as mentioned here. http://bugs.php.net/bugs-generating-backtrace.php [2010-07-08 17:00:24] bluefox012 at gmail dot com centos 5.4 have the same problem, [activating module `php5' in /home/services/web/config/httpd.conf] Installing PHP CLI binary:/usr/local/php/bin/ Installing PHP CLI man page: /usr/local/php/man/man1/ Installing build environment: /usr/local/php/lib/php/build/ Installing header files: /usr/local/php/include/php/ Installing helper programs: /usr/local/php/bin/ program: phpize program: php-config Installing man pages: /usr/local/php/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/php/lib/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 [2010-05-08 00:54:01] leonard dot f dot elia at nasa dot gov So, I tried compiling without phar: ./configure --prefix=/usr/local/php532-dist \ --with-curl=/usr/local --enable-exif --with-gd \ --with-nsapi=/usr/local/iplanet7 \ --with-mysql=/usr/local/mysql-client/mysql-5.1.40 \ --with-mysqli=/usr/local/mysql/bin/mysql_config \ --with-oci8=instantclient,/usr/local/oracle \ --with-pdo-mysql=/usr/local/mysql-client/mysql-5.1.40 \ --with-pdo-oci=/usr/local/oracle \ --with-jpeg-dir=/usr/local --with-png-dir=/usr/local \ --enable-libgcc \ --disable-phar The make now completes as expected but make install now throws up: [r...@allegro php5]# make install Installing PHP SAPI module: nsapi Installing PHP CLI binary:/usr/local/php532-dist/bin/ Installing PHP CLI man page: /usr/local/php532-dist/man/man1/ Installing build environment: /usr/local/php532-dist/lib/php/build/ Installing header files: /usr/local/php532-dist/include/php/ Installing helper programs: /usr/local/php532-dist/bin/ program: phpize program: php-config Installing man pages: /usr/local/php532-dist/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/php532-dist/lib/php/ Segmentation Fault make[1]: *** [install-pear-installer] Error 139 make: *** [install-pear] Error 2 And this bug, my friends, isn't in the bug database (that I have found). Any ideas? My system has a working php in the path (5.3.1) and is up to date on patches etc. [2010-05-07 23:52:55] leonard dot f dot elia at nasa dot gov Almost forgot, I am building php 5.3.2 as a NSAPI module for iPlanet 7 using mysql 5.1.40 ./configure --prefix=/usr/local/php532-dist \ --with-curl=/usr/local --enable-exif --with-gd \ --with-nsapi=/usr/local/iplanet7 \ --with-mysql=/usr/local/mysql-client/mysql-5.1.40 \ --with-mysqli=/usr/local/mysql/bin/mysql_config \ --with-oci8=instantclient,/usr/local/oracle \ --with-pdo-mysql=/usr/local/mysql-client/mysql-5.1.40 \ --with-pdo-oci=/usr/local/oracle \ --with-jpeg-dir=/usr/local --with-png-dir=/usr/local \ --enable-libgcc thank you 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/bug.php?id=51216 -- Edit this bug report at http://bugs.php.net/bug.php?id=51216&edit=1
Bug #52357 [Fbk]: PHP has encountered an Access Violation at 01E8ACB2
Edit report at http://bugs.php.net/bug.php?id=52357&edit=1 ID: 52357 Updated by: srina...@php.net Reported by: novia at reload dot com dot sg Summary: PHP has encountered an Access Violation at 01E8ACB2 Status: Feedback Type:Bug Package: Unknown/Other Function PHP Version: Irrelevant New Comment: this bug reporting system is designed for some one to file a bug against PHP engine . I guess, u need to create a crash dump when this issue happened and find out if this issue is related to u r php application or php engine. Previous Comments: [2010-07-16 10:47:04] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-07-16 10:45:39] novia at reload dot com dot sg Description: I have loaded the files into the hosting server and after 24 hours of propagation, I was able to view the pages successfully. However today when I was accessing the pages, I encountered the following error message: PHP has encountered an Access Violation at 01E8ACB2 Could anyone advice me if this could be coding or server related problems? Thanks -- Edit this bug report at http://bugs.php.net/bug.php?id=52357&edit=1
Bug #52436 [Fbk]: Compile error if systems do not have stdint.h
Edit report at http://bugs.php.net/bug.php?id=52436&edit=1 ID: 52436 Updated by: srina...@php.net Reported by:hiropontepocon at gmail dot com Summary:Compile error if systems do not have stdint.h Status: Feedback Type: Bug Package:Compile Failure Operating System: Solaris8 PHP Version:5.2.14 Block user comment: N New Comment: in quick look, patching pcrelib/pcre_internal.h in this way, seems to help --- ext/pcre/pcrelib/pcre_internal.h.ORIG Wed Jun 2 15:31:21 2010 +++ ext/pcre/pcrelib/pcre_internal.hWed Jun 2 15:38:08 2010 @@ -193,10 +193,10 @@ by "configure". */ #ifdef PHP_WIN32 #include "win32/php_stdint.h" -#elif HAVE_STDINT_H -#include #elif HAVE_INTTYPES_H #include +#elif HAVE_STDINT_H +#include #endif Previous Comments: [2010-07-27 00:46:18] ka...@php.net Does this happen with older versions, or 5.3 for you? [2010-07-25 06:38:13] hiropontepocon at gmail dot com Description: $ ./configure ã»ã»ã» $ grep -i stdint main/php_config.h /* Define if you have the header file. */ /* #undef HAVE_STDINT_H */ $ make ã»ã»ã» /bin/ksh /tmp/php-5.2.14/libtool --silent --preserve-dup-deps --mode=compile gcc -I/tmp/php-5.2.14/ext/pcre/pcrelib -Iext/pcre/ -I/tmp/php-5.2.14/ext/pcre/ -DPHP_ATOM_INC -I/tmp/php-5.2.14/include -I/tmp/php-5.2.14/main -I/tmp/php-5.2.14 -I/tmp/php-5.2.14/ext/date/lib -I/usr/include/libxml2 -I/tmp/php-5.2.14/TSRM -I/tmp/php-5.2.14/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -c /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_chartables.c -o ext/pcre/pcrelib/pcre_chartables.lo In file included from /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_chartables.c:25: /tmp/php-5.2.14/ext/pcre/pcrelib/pcre_internal.h:198:20: stdint.h: No such file or directory make: *** [ext/pcre/pcrelib/pcre_chartables.lo] Error 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=52436&edit=1
Bug #52448 [Opn]: ext/curl/tests/curl_error_basic.phpt fail
Edit report at http://bugs.php.net/bug.php?id=52448&edit=1 ID: 52448 Updated by: srina...@php.net Reported by:glen at delfi dot ee Summary:ext/curl/tests/curl_error_basic.phpt fail Status: Open Type: Bug Package:cURL related Operating System: PLD Linux PHP Version:5.3.3 Block user comment: N New Comment: pl. look at the test script carefully. there is instruction on how to run this test script and also available at http://wiki.php.net/qa/temp/ext/curl if this convinces u ,pl. move this bug to bogus. Previous Comments: [2010-07-26 20:03:16] glen at delfi dot ee Description: the curl library error string has changed, trivial patch fixes that tested with curl version = 7.21.0 DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' Test script: --- $ TEST_PHP_EXECUTABLE=$(which php) php run-tests.php --show-all ext/curl/tests/curl_error_basic.phpt = PHP : /usr/bin/php PHP_SAPI: cli PHP_VERSION : 5.3.3 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux carme-pld-i686 2.6.34.1-3 #1 SMP Tue Jul 6 16:15:11 CEST 2010 i686 INI actual : /etc/php/php-cli.ini More .INIs : /etc/php/conf.d/PCRE.ini,/etc/php/conf.d/SPL.ini,/etc/php/conf.d/bcmath.ini,/etc/php/conf.d/bz2.ini,/etc/php/conf.d/calendar.ini,/etc/php/conf.d/ctype.ini,/etc/php/conf.d/curl.ini,/etc/php/conf.d/dba.ini,/etc/php/conf.d/dom.ini,/etc/php/conf.d/ftp.ini,/etc/php/conf.d/gd.ini,/etc/php/conf.d/gettext.ini,/etc/php/conf.d/iconv.ini,/etc/php/conf.d/imap.ini,/etc/php/conf.d/ldap.ini,/etc/php/conf.d/mbstring.ini,/etc/php/conf.d/mcrypt.ini,/etc/php/conf.d/mysql.ini,/etc/php/conf.d/openssl.ini,/etc/php/conf.d/pgsql.ini,/etc/php/conf.d/posix.ini,/etc/php/conf.d/simplexml.ini,/etc/php/conf.d/soap.ini,/etc/php/conf.d/sockets.ini,/etc/php/conf.d/tidy.ini,/etc/php/conf.d/xml.ini,/etc/php/conf.d/xmlrpc.ini,/etc/php/conf.d/zlib.ini CWD : /home/users/glen/rpm/BUILD.i686-linux/php-5.3.3 Extra dirs : VALGRIND: Not used = Running selected tests. TEST 1/1 [ext/curl/tests/curl_error_basic.phpt] SKIP DONE TEST http://wiki.php.net/qa/temp/ext/curl */ // Fake URL to trigger an error $url = "fakeURL"; echo "== Testing curl_error with a fake URL ==\n"; // cURL handler $ch = curl_init($url); ob_start(); // start output buffering curl_exec($ch); echo "Error: " . curl_error($ch); curl_close($ch); ?> DONE OUT == Testing curl_error with a fake URL == Error: Could not resolve host: fakeURL (Domain name not found) DONE EXP == Testing curl_error with a fake URL == Error: Couldn't resolve host 'fakeURL' DONE DIFF 002+ Error: Could not resolve host: fakeURL (Domain name not found) 002- Error: Couldn't resolve host 'fakeURL' DONE FAIL curl_error() function - basic test for curl_error using a fake url [ext/curl/tests/curl_error_basic.phpt] = Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed:0 ( 0.0%) ( 0.0%) - Time taken :0 seconds = = FAILED TEST SUMMARY - curl_error() function - basic test for curl_error using a fake url [ext/curl/tests/curl_error_basic.phpt] = -- Edit this bug report at http://bugs.php.net/bug.php?id=52448&edit=1
Bug #29520 [Csd]: php mysql compile fail
Edit report at http://bugs.php.net/bug.php?id=29520&edit=1 ID: 29520 Updated by: srina...@php.net Reported by:martinkuria at hotmail dot com Summary:php mysql compile fail Status: Closed Type: Bug Package:Compile Failure Operating System: Solaris9 PHP Version:5.0.0 -Assigned To: +Assigned To:srinatar Block user comment: N New Comment: well, most likely what's happening is you have installed the 64-bit version of mysql package. i would suggest removing this package (using pkgrm) and then installing the 32-bit version of mysql package. this is a configuration issue and not a php bug this should give you the clue - which is telling you that the configurator is unable to compile 32-bit php with 64-bit mysql client: ld: warning: file /usr/local/mysql//lib/libmysqlclient.a(libmysql.o): wrong ELF class: ELFCLASS64 Undefined first referenced symbol in file mysql_close /var/tmp//ccYGWfaf.o Previous Comments: [2010-07-27 02:52:00] nazd at webmail dot co dot za Description: Hi there Guys, Im relatively new to Linux. Im having the same problem, difference is that I am using RedHat as my platform. I was able to install Apache 2.2.11 using RPM. This a virtual server I have created using VMware I created the MySQL server using an app called Webmin. When I attempt to install PHP5.2.13 using the command ./configure --prefix=/usr/lib/php --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/var/lib/mysql I get the errors below: Configuring extensions checking size of long... (cached) 4 checking size of int... (cached) 4 checking for int32_t... yes checking for uint32_t... yes checking for sys/types.h... (cached) yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking for string.h... (cached) yes checking for stdlib.h... (cached) yes checking for strtoll... yes checking for atoll... yes checking for strftime... (cached) yes checking whether to enable LIBXML support... yes checking libxml2 install dir... no checking for xml2-config path... /usr/bin/xml2-config checking whether libxml build works... yes checking for OpenSSL support... no checking for Kerberos support... no checking for PCRE support... yes checking for ZLIB support... no checking if the location of ZLIB install directory is defined... no checking whether to enable bc style precision math functions... no checking for BZip2 support... no checking whether to enable calendar conversion support... no checking whether to enable ctype functions... yes checking for cURL support... no checking if we should use cURL for url streams... no checking for QDBM support... no checking for GDBM support... no checking for NDBM support... no checking for Berkeley DB4 support... no checking for Berkeley DB3 support... no checking for Berkeley DB2 support... no checking for DB1 support... no checking for DBM support... no checking for CDB support... no checking for INI File support... no checking for FlatFile support... no checking whether to enable DBA interface... no checking whether to enable dbase support... no checking whether to enable DOM support... yes checking for xml2-config path... (cached) /usr/bin/xml2-config checking whether libxml build works... (cached) yes checking whether to enable EXIF (metadata from images) support... no checking for FrontBase SQL92 (fbsql) support... no checking for FDF support... no checking whether to enable input filter support... yes checking pcre install prefix... no checking whether to enable FTP support... no checking OpenSSL dir for FTP... no checking for GD support... no checking for the location of libjpeg... no checking for the location of libpng... no checking for the location of libXpm... no checking for FreeType 1.x support... no checking for FreeType 2... no checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no checking for GNU gettext support... no checking for GNU MP support... no checking whether to enable hash support... yes checking whether byte ordering is bigendian... (cached) no checking size of short... 2 checking size of int... (cached) 4 checking size of long... (cached) 4 checking size of long long... (cached) 8 checking for iconv support... yes checking for iconv... yes checking if iconv is glibc's... yes checking if iconv supports errno... yes checking if your cpp allows macro usage in include lines... yes checking for IMAP support... no checking for IMAP Kerberos support... no checking for IMAP SSL support... no checking for InterBase support... no checking whe
Bug #52284 [Bgs->Ver]: Reproducible crash using curl_multi functions with FTP
Edit report at http://bugs.php.net/bug.php?id=52284&edit=1 ID: 52284 Updated by: srina...@php.net Reported by:ahar...@php.net Summary:Reproducible crash using curl_multi functions with FTP -Status: Bogus +Status: Verified Type: Bug Package:cURL related Operating System: Ubuntu 10.04 (and others) PHP Version:5.3SVN-2010-07-08 (SVN) Block user comment: N New Comment: able to reproduce this issue. here is the stack trace: (gdb) where #0 0x00520a58 in curl_write_header (data=0x18d3b78 "221 Goodbye.\r\nomplete.\r", size=1, nmemb=14, ctx=0x1876e58) at /home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/interface.c:1123 #1 0x7f106e187c26 in ?? () from /usr/lib/libcurl.so.4 #2 0x7f106e1885ad in ?? () from /usr/lib/libcurl.so.4 #3 0x7f106e18b2ed in ?? () from /usr/lib/libcurl.so.4 #4 0x7f106e18c64f in ?? () from /usr/lib/libcurl.so.4 #5 0x7f106e18c792 in ?? () from /usr/lib/libcurl.so.4 #6 0x7f106e18e9b2 in ?? () from /usr/lib/libcurl.so.4 #7 0x7f106e1a4813 in curl_multi_cleanup () from /usr/lib/libcurl.so.4 #8 0x00527208 in _php_curl_multi_close (rsrc=0x1871970) at /home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/multi.c:327 #9 0x007f246e in list_entry_destructor (ptr=0x1871970) at /home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_list.c:184 #10 0x007efa3b in zend_hash_del_key_or_index (ht=0xe1eaf0, arKey=0x0, nKeyLength=0, h=4, flag=1) at /home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_hash.c:497 #11 0x007f1fa0 in _zend_list_delete (id=4) at /home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_list.c:58 #12 0x005271d5 in zif_curl_multi_close (ht=1, return_value=0x187a140, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/multi.c:319 Previous Comments: [2010-07-21 13:11:10] profy dot net at gmail dot com Sorry for bothering you, but I see now that bug still exists. My code already had a workaround for that issue and I not disabled it when testing against latest version (5.3.3RC3 and libcurl 7.21.0). Now I've tested again with truly parallel 5 ftp requests and it is still failing as it was with PHP 5.2.13 on Win XP SP3 [2010-07-21 12:39:00] paj...@php.net Was a libCurl issue, fixed in latest release. [2010-07-21 12:31:14] profy dot net at gmail dot com I've tested with latest PHP5.3.3RC3 downloaded from http://windows.php.net/qa/ and it works fine now with 5 FTP and 3 HTTP parallel requests using curl_multi_* functions. This request failed before. cURL version is 7.21.0. It seems bug is fixed in latest curl. [2010-07-21 11:07:25] profy dot net at gmail dot com Curl version: libcurl/7.20.0 OpenSSL/0.9.8h zlib/1.2.3 [2010-07-21 10:55:26] paj...@php.net Please copy the CURL's phpinfo block only, and using text only :) 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/bug.php?id=52284 -- Edit this bug report at http://bugs.php.net/bug.php?id=52284&edit=1
Bug #52411 [Fbk->Dup]: segfault: curl_multi_* + 2 or more FTP urls
Edit report at http://bugs.php.net/bug.php?id=52411&edit=1
ID: 52411
Updated by: srina...@php.net
Reported by:profy dot net at gmail dot com
Summary:segfault: curl_multi_* + 2 or more FTP urls
-Status: Feedback
+Status: Duplicate
Type: Bug
Package:cURL related
Operating System: win xp, ubuntu 9.10, others
PHP Version:5.3.3
Block user comment: N
New Comment:
closing this bug as duplicate of bug #52284
Previous Comments:
[2010-07-27 01:06:39] ka...@php.net
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.
[2010-07-23 08:16:59] profy dot net at gmail dot com
Description:
segfault when requesting 2 or more FTP urls with curl_multi_*
Appears both under WIN XP SP3, ubuntu 8.10, 9.10
segfault when calling test script from command line, for example:
d:/www4/php5/php -q -c d:/www4/php.ini -f curl_ftp_bug_test.php
and also as apache2 module:
http://localhost/curl_ftp_bug_test.php
php.ini used is default from distribution (php.ini-production) wit only
curl extension enabled:
extension=php_curl.dll
Reproduced every time when call test script.
This bug first reported here:
http://bugs.php.net/bug.php?id=52284
But was set to "Bogus" by mistake.
Test script:
---
$url) {
$curly[$id] = curl_init();
curl_setopt($curly[$id], CURLOPT_URL, $url);
curl_setopt($curly[$id], CURLOPT_RETURNTRANSFER, true);
// I've add this opt to speed up request, bug appearing with or
without this line
curl_setopt($curly[$id], CURLOPT_NOBODY, true);
curl_multi_add_handle($mh, $curly[$id]);
}
$running = null;
do {
$status = curl_multi_exec($mh, $running);
usleep(1000);
} while($status == CURLM_CALL_MULTI_PERFORM || $running);
foreach ($curly as $id => $c) {
$result[$id] = curl_multi_getcontent($c);
curl_multi_remove_handle($mh, $c);
curl_close($c);
}
curl_multi_close($mh);
return $result;
}
$urls = array(
"4358521" =>
"ftp://ftp.ea.com/pub/ea/patches/nfs-underground/pc/en-uk/NFSU_EUROPE_PATCH_4.exe";,
"7458288" =>
"ftp://ftp.nero.com/software/plugins/WMAPlugin20937.exe";,
);
echo "";
print_R(multi_request($urls));
echo "";
Expected result:
No segfault :)
Actual result:
--
segmentation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=52411&edit=1
Bug #29520 [Csd->ReO]: php mysql compile fail
Edit report at http://bugs.php.net/bug.php?id=29520&edit=1 ID: 29520 Updated by: srina...@php.net Reported by:martinkuria at hotmail dot com Summary:php mysql compile fail -Status: Closed +Status: Re-Opened Type: Bug Package:Compile Failure Operating System: Solaris9 PHP Version:5.0.0 Assigned To:srinatar Block user comment: N New Comment: marking it as "bogus" Previous Comments: [2010-07-27 04:40:30] srina...@php.net well, most likely what's happening is you have installed the 64-bit version of mysql package. i would suggest removing this package (using pkgrm) and then installing the 32-bit version of mysql package. this is a configuration issue and not a php bug this should give you the clue - which is telling you that the configurator is unable to compile 32-bit php with 64-bit mysql client: ld: warning: file /usr/local/mysql//lib/libmysqlclient.a(libmysql.o): wrong ELF class: ELFCLASS64 Undefined first referenced symbol in file mysql_close /var/tmp//ccYGWfaf.o [2010-07-27 02:52:00] nazd at webmail dot co dot za Description: Hi there Guys, Im relatively new to Linux. Im having the same problem, difference is that I am using RedHat as my platform. I was able to install Apache 2.2.11 using RPM. This a virtual server I have created using VMware I created the MySQL server using an app called Webmin. When I attempt to install PHP5.2.13 using the command ./configure --prefix=/usr/lib/php --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/var/lib/mysql I get the errors below: Configuring extensions checking size of long... (cached) 4 checking size of int... (cached) 4 checking for int32_t... yes checking for uint32_t... yes checking for sys/types.h... (cached) yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking for string.h... (cached) yes checking for stdlib.h... (cached) yes checking for strtoll... yes checking for atoll... yes checking for strftime... (cached) yes checking whether to enable LIBXML support... yes checking libxml2 install dir... no checking for xml2-config path... /usr/bin/xml2-config checking whether libxml build works... yes checking for OpenSSL support... no checking for Kerberos support... no checking for PCRE support... yes checking for ZLIB support... no checking if the location of ZLIB install directory is defined... no checking whether to enable bc style precision math functions... no checking for BZip2 support... no checking whether to enable calendar conversion support... no checking whether to enable ctype functions... yes checking for cURL support... no checking if we should use cURL for url streams... no checking for QDBM support... no checking for GDBM support... no checking for NDBM support... no checking for Berkeley DB4 support... no checking for Berkeley DB3 support... no checking for Berkeley DB2 support... no checking for DB1 support... no checking for DBM support... no checking for CDB support... no checking for INI File support... no checking for FlatFile support... no checking whether to enable DBA interface... no checking whether to enable dbase support... no checking whether to enable DOM support... yes checking for xml2-config path... (cached) /usr/bin/xml2-config checking whether libxml build works... (cached) yes checking whether to enable EXIF (metadata from images) support... no checking for FrontBase SQL92 (fbsql) support... no checking for FDF support... no checking whether to enable input filter support... yes checking pcre install prefix... no checking whether to enable FTP support... no checking OpenSSL dir for FTP... no checking for GD support... no checking for the location of libjpeg... no checking for the location of libpng... no checking for the location of libXpm... no checking for FreeType 1.x support... no checking for FreeType 2... no checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no checking for GNU gettext support... no checking for GNU MP support... no checking whether to enable hash support... yes checking whether byte ordering is bigendian... (cached) no checking size of short... 2 checking size of int... (cached) 4 checking size of long... (cached) 4 checking size of long long... (cached) 8 checking for iconv support... yes checking for iconv... yes checking if iconv is glibc's... yes checking if iconv supports errno... yes checking if your cpp allows macro usage in include lines... yes checkin
Bug #29520 [ReO->Bgs]: php mysql compile fail
Edit report at http://bugs.php.net/bug.php?id=29520&edit=1 ID: 29520 Updated by: srina...@php.net Reported by:martinkuria at hotmail dot com Summary:php mysql compile fail -Status: Re-Opened +Status: Bogus Type: Bug Package:Compile Failure Operating System: Solaris9 PHP Version:5.0.0 Assigned To:srinatar Block user comment: N New Comment: "marking it as bogus for completeness" Previous Comments: [2010-07-27 05:13:28] srina...@php.net marking it as "bogus" [2010-07-27 04:40:30] srina...@php.net well, most likely what's happening is you have installed the 64-bit version of mysql package. i would suggest removing this package (using pkgrm) and then installing the 32-bit version of mysql package. this is a configuration issue and not a php bug this should give you the clue - which is telling you that the configurator is unable to compile 32-bit php with 64-bit mysql client: ld: warning: file /usr/local/mysql//lib/libmysqlclient.a(libmysql.o): wrong ELF class: ELFCLASS64 Undefined first referenced symbol in file mysql_close /var/tmp//ccYGWfaf.o [2010-07-27 02:52:00] nazd at webmail dot co dot za Description: Hi there Guys, Im relatively new to Linux. Im having the same problem, difference is that I am using RedHat as my platform. I was able to install Apache 2.2.11 using RPM. This a virtual server I have created using VMware I created the MySQL server using an app called Webmin. When I attempt to install PHP5.2.13 using the command ./configure --prefix=/usr/lib/php --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/var/lib/mysql I get the errors below: Configuring extensions checking size of long... (cached) 4 checking size of int... (cached) 4 checking for int32_t... yes checking for uint32_t... yes checking for sys/types.h... (cached) yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking for string.h... (cached) yes checking for stdlib.h... (cached) yes checking for strtoll... yes checking for atoll... yes checking for strftime... (cached) yes checking whether to enable LIBXML support... yes checking libxml2 install dir... no checking for xml2-config path... /usr/bin/xml2-config checking whether libxml build works... yes checking for OpenSSL support... no checking for Kerberos support... no checking for PCRE support... yes checking for ZLIB support... no checking if the location of ZLIB install directory is defined... no checking whether to enable bc style precision math functions... no checking for BZip2 support... no checking whether to enable calendar conversion support... no checking whether to enable ctype functions... yes checking for cURL support... no checking if we should use cURL for url streams... no checking for QDBM support... no checking for GDBM support... no checking for NDBM support... no checking for Berkeley DB4 support... no checking for Berkeley DB3 support... no checking for Berkeley DB2 support... no checking for DB1 support... no checking for DBM support... no checking for CDB support... no checking for INI File support... no checking for FlatFile support... no checking whether to enable DBA interface... no checking whether to enable dbase support... no checking whether to enable DOM support... yes checking for xml2-config path... (cached) /usr/bin/xml2-config checking whether libxml build works... (cached) yes checking whether to enable EXIF (metadata from images) support... no checking for FrontBase SQL92 (fbsql) support... no checking for FDF support... no checking whether to enable input filter support... yes checking pcre install prefix... no checking whether to enable FTP support... no checking OpenSSL dir for FTP... no checking for GD support... no checking for the location of libjpeg... no checking for the location of libpng... no checking for the location of libXpm... no checking for FreeType 1.x support... no checking for FreeType 2... no checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no checking for GNU gettext support... no checking for GNU MP support... no checking whether to enable hash support... yes checking whether byte ordering is bigendian... (cached) no checking size of short... 2 checking size of int... (cached) 4 checking size of long... (cached) 4 checking size of long long... (cached) 8 checking for iconv support... yes checking for iconv
Bug #52284 [Ver]: Reproducible crash using curl_multi functions with FTP
Edit report at http://bugs.php.net/bug.php?id=52284&edit=1
ID: 52284
Updated by: srina...@php.net
Reported by:ahar...@php.net
Summary:Reproducible crash using curl_multi functions with
FTP
Status: Verified
Type: Bug
Package:cURL related
Operating System: Ubuntu 10.04 (and others)
PHP Version:5.3SVN-2010-07-08 (SVN)
Block user comment: N
New Comment:
Ok, been debugging this since morning for fun. As Pierre mentioned
earlier, this
bug turns out to be a libcurl bug and a recent commit within libcurl
fixes the
underlying multi handler issue.
now, ubuntu has not shipped with recent versions of libcurl yet. so, you
will
need to manually download libcurl from below: and install to say
/usr/local
http://curl.haxx.se/snapshots/
once this new curl is installed, you will need to recompile php with
--with-
curl=/usr/local
if this satisfies ur concern, then we can close this bug.
hope this helps.
Previous Comments:
[2010-07-27 07:48:00] profy dot net at gmail dot com
Reproduced every time when call test script.
Test script:
---
$url) {
$curly[$id] = curl_init();
curl_setopt($curly[$id], CURLOPT_URL, $url);
curl_setopt($curly[$id], CURLOPT_RETURNTRANSFER, true);
// I've add this opt to speed up request, bug appearing
with or
without this line
curl_setopt($curly[$id], CURLOPT_NOBODY, true);
curl_multi_add_handle($mh, $curly[$id]);
}
$running = null;
do {
$status = curl_multi_exec($mh, $running);
usleep(1000);
} while($status == CURLM_CALL_MULTI_PERFORM || $running);
foreach ($curly as $id => $c) {
$result[$id] = curl_multi_getcontent($c);
curl_multi_remove_handle($mh, $c);
curl_close($c);
}
curl_multi_close($mh);
return $result;
}
$urls = array(
"4358521" =>
"ftp://ftp.ea.com/pub/ea/patches/nfs-underground/pc/en-uk/NFSU_EUROPE_PATCH_4.exe";,
"7458288" =>
"ftp://ftp.nero.com/software/plugins/WMAPlugin20937.exe";,
);
echo "";
print_R(multi_request($urls));
echo "";
[2010-07-27 04:57:11] srina...@php.net
able to reproduce this issue. here is the stack trace:
(gdb) where
#0 0x00520a58 in curl_write_header (data=0x18d3b78 "221
Goodbye.\r\nomplete.\r", size=1, nmemb=14, ctx=0x1876e58)
at
/home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/interface.c:1123
#1 0x7f106e187c26 in ?? () from /usr/lib/libcurl.so.4
#2 0x7f106e1885ad in ?? () from /usr/lib/libcurl.so.4
#3 0x7f106e18b2ed in ?? () from /usr/lib/libcurl.so.4
#4 0x7f106e18c64f in ?? () from /usr/lib/libcurl.so.4
#5 0x7f106e18c792 in ?? () from /usr/lib/libcurl.so.4
#6 0x7f106e18e9b2 in ?? () from /usr/lib/libcurl.so.4
#7 0x7f106e1a4813 in curl_multi_cleanup () from
/usr/lib/libcurl.so.4
#8 0x00527208 in _php_curl_multi_close (rsrc=0x1871970) at
/home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/multi.c:327
#9 0x007f246e in list_entry_destructor (ptr=0x1871970) at
/home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_list.c:184
#10 0x007efa3b in zend_hash_del_key_or_index (ht=0xe1eaf0,
arKey=0x0, nKeyLength=0, h=4, flag=1) at
/home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_hash.c:497
#11 0x007f1fa0 in _zend_list_delete (id=4) at
/home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_list.c:58
#12 0x005271d5 in zif_curl_multi_close (ht=1,
return_value=0x187a140, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=0)
at /home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/multi.c:319
[2010-07-21 13:11:10] profy dot net at gmail dot com
Sorry for bothering you, but I see now that bug still exists. My code
already had a workaround for that issue and I not disabled it when
testing against latest version (5.3.3RC3 and libcurl 7.21.0). Now
I've tested again with truly parallel 5 ftp requests and it is still
failing as it was with PHP 5.2.13 on Win XP SP3
[2010-07-21 12:39:00] paj...@php.net
Was a libCurl issue, fixed in latest release.
[2010-07-21 12:31:14] profy dot net at gmail dot com
I've tested with latest PHP5.3.3RC3 downloaded from
http://windows.php.net/qa/ and it works fine now with 5 FTP and 3 HTTP
parallel requests using curl_multi_* functions. This request failed
before. cURL version is 7.21.0. It seems bug is fixed in latest curl.
Bug #52436 [Asn->Csd]: Compile error if systems do not have stdint.h
Edit report at http://bugs.php.net/bug.php?id=52436&edit=1 ID: 52436 Updated by: srina...@php.net Reported by:hiropontepocon at gmail dot com Summary:Compile error if systems do not have stdint.h -Status: Assigned +Status: Closed Type: Bug Package:Compile Failure Operating System: Solaris8 PHP Version:5.2.14 Assigned To:srinatar Block user comment: N Previous Comments: [2010-07-27 23:42:24] srina...@php.net Automatic comment from SVN on behalf of srinatar Revision: http://svn.php.net/viewvc/?view=revision&revision=301625 Log: - Fixed bug #52436 (Compile error in pcre if systems do not have stdint.h) # PCRE's config.h can very well reuse the definitions made available from # PHP's configure script output available within php_config.h [2010-07-27 19:13:39] hiropontepocon at gmail dot com > in quick look, patching pcrelib/pcre_internal.h in this way, seems to help Patch works fine. Thanks! By the way, Is the following code correct? ext/pcre/pcrelib/config.h: ã»ã»ã» /* Define to 1 if you have the header file. */ #ifndef HAVE_STDINT_H #define HAVE_STDINT_H 1 #endif [2010-07-27 17:42:22] paj...@php.net Pls apply it as long as it works on linux too :) [2010-07-27 17:39:24] hiropontepocon at gmail dot com php-5.2.13 â OK php-5.2.14 â Compile Failed php-5.3.2 â OK php-5.3.3 â Compile Failed [2010-07-27 04:32:04] srina...@php.net in quick look, patching pcrelib/pcre_internal.h in this way, seems to help --- ext/pcre/pcrelib/pcre_internal.h.ORIG Wed Jun 2 15:31:21 2010 +++ ext/pcre/pcrelib/pcre_internal.hWed Jun 2 15:38:08 2010 @@ -193,10 +193,10 @@ by "configure". */ #ifdef PHP_WIN32 #include "win32/php_stdint.h" -#elif HAVE_STDINT_H -#include #elif HAVE_INTTYPES_H #include +#elif HAVE_STDINT_H +#include #endif 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/bug.php?id=52436 -- Edit this bug report at http://bugs.php.net/bug.php?id=52436&edit=1
#50359 [Fbk]: Random crash on new SoapServer
ID: 50359 Updated by: srina...@php.net Reported By: datacompboy at call2ru dot com Status: Feedback Bug Type: SOAP related Operating System: Linux 2.6.31-1-amd64 PHP Version: 5.2.11 New Comment: pl. refer to this link on how to generate a backtrace for developers to use http://bugs.php.net/bugs-generating-backtrace.php [ you will need to also set ulimit -c unlimited in your shell before starting apache] Previous Comments: [2009-12-02 15:03:16] datacompboy at call2ru dot com Rebuilding without suhosin with latest tarball. Will post bt as soon, as crash reproduced again. [2009-12-02 13:58:41] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And do not add any 3rd party patches (Suhosin) or load any zend extensions (apc, etc.) when you produce the backtrace. Also, simple backtrace is usually quite enough, just bt.. [2009-12-02 12:16:00] datacompboy at call2ru dot com Description: Sometimes (from 1-2-3 times in a day to 1 time at 3-4 days) every-minute cron, that fetches from WS, written via SoapServer gets "Bad Gateway" reply. On server-side there an [notice] child pid 1892 exit signal Segmentation fault (11) in error.log and one of: kernel: [3878097.399362] php[23893]: segfault at 7fa3e51aded0 ip 7fa3e51aded0 sp 7fa3e35f0128 error 14 in librt-2.9.so[7fa3e9822000+7000] kernel: [3879416.960444] php[24282]: segfault at 7ff7addc9edb ip 7ff7ab8024d7 sp 7ff7ac20bca0 error 4 in libgcc_s.so.1[7ff7ab7f1000+1a000] in dmesg. After suhosin enabled in sumulation mode, there [error] [client 87.106.137.135] ALERT-SIMULATION - canary mismatch on efree() - heap overflow detected (attacker '87.106.137.135', file '/var/www/yii/framework/web/services/CWebService.php', line 154) messages. Same request executed right after error works fine. So, i have enabled buffer overflow coredump in suhosin, and here an coredump attached. Can't post full reproduce code, since crash very random. System is dual-core Opteron. PHP 5.2.11-1 with Suhosin-Patch 0.9.7 (cli) (built: Sep 20 2009 11:41:46) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH Reproduce code: --- Dies every time on $server=new SoapServer($this->wsdlUrl,$this->getOptions()); where $this->wsdlUrl = "http://dev-eworld.direktbill.de/y/wsdl/quote";; Expected result: Always works Actual result: -- #0 0x7f699b9c566b in suhosin_log () from /usr/lib/php5/20060613/suhosin.so No symbol table info available. #1 0x7f69a402e1dd in _zend_mm_free_int (heap=0xf3eb40, p=0x1374360) at /tmp/buildd/php5-5.2.11.dfsg.1/Zend/zend_alloc.c:2036 check = 18433888 mm_block = 0x1374338 next_block = 0x7f69a4537e40 size = 0 #2 0x7f69a401927b in php_stream_tidy_wrapper_error_log (wrapper=0x7f69a4537e40) at /tmp/buildd/php5-5.2.11.dfsg.1/main/streams/streams.c:195 i = 1 #3 0x7f69a401aae5 in _php_stream_open_wrapper_ex (path=0x1194760 "http://dev-eworld.direktbill.de/y/wsdl/quote";, mode=0x7f69a25c51a0 "\220\066\350\246i\177", options=12, opened_path=0x0, context=0x131ec40) at /tmp/buildd/php5-5.2.11.dfsg.1/main/streams/streams.c:1899 stream = 0x131ec40 wrapper = 0x7f69a4537e40 path_to_open = 0x10814a8 "@~S\
#50382 [Opn]: Upgrading to php 5.3 > Application works but apache segfaults
ID: 50382 Updated by: srina...@php.net Reported By: dirk at bean-it dot nl Status: Open Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3.1 New Comment: from the bt, I guess, there is memory corruption within Zend engine. if you are able to reproduce this crash by running a modified version of your script from the command line, then , to help us more understand the problem, will it be possible for you to run it with valgrind --num- callers=15 --error-limit=no ./sapi/cli/php alternatively, if you export USE_ZEND_ALLOC=0 in your apachectl script, your server might run successfully albeit at decreased performance. thanks for your help Previous Comments: [2009-12-04 12:56:47] dirk at bean-it dot nl Up till now, I haven't been able to exactly pinpoint the problem. As mentioned below, our application works as expected, it looks likes Apache crashes -after- php has compiled the page. Very strange. The application is quite large, a lot of code. Tried to debug with Zend Debugger, but than things work as expected, no segfault. As much as I would like to give some example code, I cannot at this moment, since I have no clue where things go wrong (the app works fine!). Any suggestions on how to proceed are highly appreciated. [2009-12-04 12:39:33] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2009-12-04 12:25:42] dirk at bean-it dot nl I've compiled the snapshot, gives the same segfaults. [2009-12-04 12:11:54] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-12-04 11:08:43] dirk at bean-it dot nl Description: Upgrading to php 5.3 > Application works but apache segfaults I've upgraded from 5.2.11 to 5.3.1. Our application works fine when accessed from a browser, however the apache error log fills with messages like: [Fri Dec 04 11:24:59 2009] [notice] child pid 28025 exit signal Segmentation fault (11) Each request causes a message like this. This is not happening when using 5.2.11. I've tried to locate the problem by stepping through the code with the Zend debugger. Unfortunately, the problem does not occur when doing this. I've followed the instructions and created a backtrace (see below). The weird thing is, PHP compiled with --enable-debug, does not crash. I does give tons of "Memory leak" messages in the apache error.log. I'm not very in to this, so I hope this information gives somebody a clue. I've also tried a snapshot (5.3-200912040930), this doesn't work either, same segfaults. I'm more than happy to provide more info, test things, change things... Just let me know. ./configure options (I cannot reduce this set, the application will stop working) './configure' \ '--with-config-file-path=/etc' \ '--with-apxs2=/usr/bin/apxs2' \ '--with-gettext' \ '--with-libxml-dir=/usr/local' \ '--with-mysqli=/usr/bin/mysql_config' \ '--with-mcrypt' \ '--with-iconv' \ '--enable-mbstring' \ '--with-zlib=/usr' \ '--with-xsl' \ '--with-curl' \ '--with-gd' \ '--with-jpeg-dir=/usr/include' \ '--with-png-dir=/usr/include' \ '--with-openssl' \ '--with-freetype-dir' \ '--enable-gd-native-ttf' \ "$@" Actual result: -- Backtrace (created running the snapshot, without debug): (gdb) bt #0 0xb6e63777 in zval_mark_grey (pz=0x9fd0cf8) at /root/php5.3-200912040930/Zend/zend_gc.c:360 #1 0xb6e63d35 in gc_collect_cycles () at /root/php5.3-200912040930/Zend/zend_gc.c:417 #2 0xb6e48285 in zend_deactivate () at /root/php5.3-200912040930/Zend/zend.c:900 #3 0xb6df767f in php_request_shutdown (dummy=0x0) at /root/php5.3-200912040930/main/main.c:1606 #4 0xb6ec8aa9 in php_handler (r=0x9bc31d0) at /root/php5.3-200912040930/sapi/apache2handler/sapi_apache2.c:493 #5 0x0807a1c9 in ap_run_handler () #6 0x0807d5e1 in ap_invoke_handler () #7 0x0808af00 in ap_internal_redirect () #8 0xb73356c3 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #9 0x09bc31a0 in ?? () #10 0x09bb8d38 in ?? () #11 0xb7339bb7 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #12 0x09bc3138 in ?? () #13 0x in ?? ()
#50382 [Fbk]: Upgrading to php 5.3 > Application works but apache segfaults
ID: 50382 Updated by: srina...@php.net Reported By: dirk at bean-it dot nl Status: Feedback Bug Type: Reproducible crash Operating System: Debian 5.0 PHP Version: 5.3.1 New Comment: alternatively, you can also set "zend.enable_gc=Off" within your php.ini and this should make the crash go away as well. Previous Comments: [2009-12-05 16:14:38] srina...@php.net from the bt, I guess, there is memory corruption within Zend engine. if you are able to reproduce this crash by running a modified version of your script from the command line, then , to help us more understand the problem, will it be possible for you to run it with valgrind --num- callers=15 --error-limit=no ./sapi/cli/php alternatively, if you export USE_ZEND_ALLOC=0 in your apachectl script, your server might run successfully albeit at decreased performance. thanks for your help [2009-12-04 12:56:47] dirk at bean-it dot nl Up till now, I haven't been able to exactly pinpoint the problem. As mentioned below, our application works as expected, it looks likes Apache crashes -after- php has compiled the page. Very strange. The application is quite large, a lot of code. Tried to debug with Zend Debugger, but than things work as expected, no segfault. As much as I would like to give some example code, I cannot at this moment, since I have no clue where things go wrong (the app works fine!). Any suggestions on how to proceed are highly appreciated. [2009-12-04 12:39:33] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2009-12-04 12:25:42] dirk at bean-it dot nl I've compiled the snapshot, gives the same segfaults. [2009-12-04 12:11:54] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50382 -- Edit this bug report at http://bugs.php.net/?id=50382&edit=1
#48752 [Csd->Opn]: SIGSEGV during date parsing with new timelib
ID: 48752
Updated by: srina...@php.net
Reported By: theta...@php.net
-Status: Closed
+Status: Open
Bug Type: Date/time related
Operating System: * (ZTS build only!)
PHP Version: 5.*, 6
Assigned To: pajoye
New Comment:
the fix for this issue has been rolled back.
http://svn.php.net/viewvc/?view=revision&revision=289991
[srir...@sriramn]'PHP_5_2'>svn diff -r 289982:289991
ext/date/php_date.c
Index: ext/date/php_date.c
===
--- ext/date/php_date.c (revision 289982)
+++ ext/date/php_date.c (revision 289991)
@@ -371,7 +371,6 @@
}
DATEG(timezone) = NULL;
DATEG(tzcache) = NULL;
- DATEG(last_errors) = NULL;
return SUCCESS;
}
@@ -389,10 +388,6 @@
FREE_HASHTABLE(DATEG(tzcache));
DATEG(tzcache) = NULL;
}
- if (DATEG(last_errors)) {
- timelib_error_container_dtor(DATEG(last_errors));
- DATEG(last_errors) = NULL;
- }
return SUCCESS;
}
accordingly, this bug has been moved to open status.
The corresponding NEWS entry for this bug will also need to be rolled
back as well.
Previous Comments:
[2009-10-27 10:45:19] paj...@php.net
This bug has been fixed in SVN.
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.
[2009-10-27 10:44:12] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=289982
Log: - #48752
[2009-10-27 10:41:45] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=289981
Log: - #48752, crash during date parsing with invalid date
[2009-10-24 23:36:59] paj...@php.net
here is a patch: http://pastie.org/668460
It makes the last_errors request specific as well as it should be.
However the problem is not completely solved as we need a lock before
the 1st operation on last_errors until we are done. It is not sufficent
to lock it before calling a function or setting it a value. Other
threads may affect it during two calls.
I consider this last_errors as a design mistake, but if you like to
keep it this way then we will need this global lock.
[2009-10-24 22:52:41] paj...@php.net
Simply script:
$datetime_object = date_create("d");
with the timezone set in php.ini.
The crashes occur only with an invalid date. For some reason the global
last_errors is not NULL anymore (but it is set to NULL during MINIT) but
freed somewhere.
By the way, I do not understand the need to store the warning in a
GLOBALS (for all applications running on the same server) when we work
with object. That's a design flaw as other applications using the same
API at the same time may generate warnings, defeating the whole point of
the warnings (if they did not crash php before). That could affect NTS
server as well.
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/48752
--
Edit this bug report at http://bugs.php.net/?id=48752&edit=1
#49295 [Asn->Opn]: stream_socket_client() fails on SSL+async
ID: 49295 Updated by: srina...@php.net Reported By: frase at cs dot wisc dot edu -Status: Assigned +Status: Open Bug Type: OpenSSL related Operating System: win32 only - Win 2000 Pro SP4 PHP Version: 5.2.11RC2 Assigned To: srinatar Previous Comments: [2009-09-16 18:22:57] srina...@php.net as i mentioned to you last time, our openssl implementation is incorrectly using file based sockets instead of openssl provided 'BIO' for underlying communication. this will require re-implementation of some of php's openssl implementation. this should be an issue only on windows. [2009-09-04 13:21:10] frase at cs dot wisc dot edu I'm sure this is expected, but the bug remains in 5.2.11RC2. I also noticed another clue: I mentioned previously that SSL+ASYNC works once (but not asynchronously) after starting Apache, and then fails and throws warnings. It turns out any SSL socket connection will cause future SSL+ASYNC attempts to do this, even if the first one was SYNC. So to get SSL+ASYNC to connect, it must be the very first SSL socket opened since Apache started. [2009-09-02 14:17:18] frase at cs dot wisc dot edu Commenting the stream_set_blocking() doesn't change anything for me on Windows. SSL+ASYNC still works exactly once (but doesn't actually connect asynchronously) and then gives the warnings; SSL+SYNC still works fine, as does TCP+ASYNC. Thanks for your work on this. I get complaints about it every week because if the remote server doesn't respond then our software gets stuck in the connection phase, and since the connection phase cannot be made asynchronous, the user is unable to abort it and just has to wait. [2009-09-02 08:38:01] srina...@php.net just a follow up note, this issue (async not working consistently with openssl on windows) has always been the case and this issue has nothing to do with the fix that went in for bug:48182. [2009-09-02 08:09:22] srina...@php.net ok, i was looking into this issue today. the issue is that , especially on windows -where sockets are not file descriptors unlike in unix, async sockets and openssl works together only if we use BIO wrappers provided by openssl module instead of directly accessing underlying sockets as file descriptors. the possible right way to do this would be to use to socket wrappers provided by SSL module (known as BIO wrappers which makes it work properly on windows). this will require some amount of fiddling our openssl module. i don't think, 5.2 is a good place to do this change. for now, commenting this below code should help you to run your script properly on windows. stream_set_blocking($socket, 0); i will spend more time on this and investigate on the best way to use BIO wrappers within existing openssl module say within php 5.3 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/49295 -- Edit this bug report at http://bugs.php.net/?id=49295&edit=1
#50496 [Fbk]: Use of is valid only in a c99 compilation environment.
ID: 50496 Updated by: srina...@php.net Reported By: alexander at skwar dot name Status: Feedback Bug Type: Compile Failure Operating System: Solaris 10, Sparc PHP Version: 5.3SVN-2009-12-16 (snap) Assigned To: srinatar New Comment: yup, will look into this today. Previous Comments: [2009-12-16 18:09:30] paj...@php.net That code is new in 5.3.1, it adds (or restore when SHA-512/256 was available on the system) features to crypt. Ah, that could be the problem. I tested using OpenSolaris on a t2000 box. I have no solaris to test. @srinatar, can you take a look at this issue please? That would be very helpful :) [2009-12-16 17:30:09] alexander at skwar dot name Hm. That's strange. It shouldn't be depending on the version of Solaris. In /usr/include/stdbool.h, there is: #else /* _STDC_C99 */ #error "Use of is valid only in a c99 compilation environment." #endif /* _STDC_C99 */ So, for some reason or the other, you had _STDC_C99 defined. This should only be defined if compiling in C99 mode. I'm right now downloading Solaris 10 U8 to install it in a Virtual Box together with Sun Studio 12.1. I expect it to error out. Out of curiosity: Which version of Solaris 10 are you using? U8? I'm *NOT* using OpenSolaris, BTW. And I find it quite curious that php-5.3.0 compiles and php-5.3.1+ does not. The only difference is the source code of PHP. This kinda leads me to think, that the problem is related to PHP. [2009-12-16 15:47:50] paj...@php.net It builds just fine on the test solaris system provided by Sun. If you have a patch fixing this issue on your platform without breaking other then please post a link to it here. [2009-12-16 15:24:19] alexander at skwar dot name I added -xc99=all to the beginning of my CFLAGS (see http://bash.pastebin.com/pastebin.php?diff=f14d9a4ab) and this allowed me to compile (it's still compiling but I'm past that step which error out earlier). [2009-12-16 15:09:42] j...@php.net Assigned to Pierre who broke this. 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/50496 -- Edit this bug report at http://bugs.php.net/?id=50496&edit=1
#50496 [Asn]: Use of is valid only in a c99 compilation environment.
ID: 50496 Updated by: srina...@php.net Reported By: alexander at skwar dot name Status: Assigned Bug Type: Compile Failure Operating System: Solaris 10, Sparc PHP Version: 5.3SVN-2009-12-16 (snap) Assigned To: srinatar New Comment: Sun Studio compiler does not by default enable ANSIC C99 standard and its extensions and need to be explicitly enabled. ! this patch addresses this patch by enabling ANSIC99 standard. [srir...@chilidev]'PHP_5_3'>svn diff acinclude.m4 Index: acinclude.m4 === --- acinclude.m4(revision 292219) +++ acinclude.m4(working copy) @@ -2780,7 +2780,7 @@ AC_MSG_RESULT([no]), SUNCC="yes" GCC="no" -test -n "$auto_cflags" && CFLAGS="-O -xs -xstrconst -zlazyload" +test -n "$auto_cflags" && CFLAGS="-O -xc99=all -xs -xstrconst - zlazyload" GCC="" AC_MSG_RESULT([yes]) ) if no one has any objections, i will commit this patch here is the complete patch Index: trunk/acinclude.m4 === --- trunk/acinclude.m4 (revision 292220) +++ trunk/acinclude.m4 (working copy) @@ -2780,7 +2780,7 @@ AC_MSG_RESULT([no]), SUNCC="yes" GCC="no" -test -n "$auto_cflags" && CFLAGS="-O -xs -xstrconst -zlazyload" +test -n "$auto_cflags" && CFLAGS="-O -xc99=all -xs -xstrconst - zlazyload" GCC="" AC_MSG_RESULT([yes]) ) Index: branches/PHP_5_3/acinclude.m4 === --- branches/PHP_5_3/acinclude.m4 (revision 292219) +++ branches/PHP_5_3/acinclude.m4 (working copy) @@ -2780,7 +2780,7 @@ AC_MSG_RESULT([no]), SUNCC="yes" GCC="no" -test -n "$auto_cflags" && CFLAGS="-O -xs -xstrconst -zlazyload" +test -n "$auto_cflags" && CFLAGS="-O -xc99=all -xs -xstrconst - zlazyload" GCC="" AC_MSG_RESULT([yes]) ) Index: branches/PHP_5_3/NEWS === --- branches/PHP_5_3/NEWS (revision 292219) +++ branches/PHP_5_3/NEWS (working copy) @@ -9,6 +9,8 @@ - Changed "post_max_size" php.ini directive to allow unlimited post size by setting it to 0. (Rasmus) +- Fixed bug #50496 (Use of is valid only in a c99 compilation + environment. (Sriram) - Added support for SHA-256 and SHA-512 to php's crypt. (Pierre) - Added realpath_cache_size() and realpath_cache_get() functions. (Stas) - Added FILTER_FLAG_STRIP_BACKTICK option to the filter extension. (Ilia) I will enable xc99=all option in php 5.2 branch after 5.2.12 is released. Previous Comments: [2009-12-16 18:25:36] srina...@php.net yup, will look into this today. ---- [2009-12-16 18:09:30] paj...@php.net That code is new in 5.3.1, it adds (or restore when SHA-512/256 was available on the system) features to crypt. Ah, that could be the problem. I tested using OpenSolaris on a t2000 box. I have no solaris to test. @srinatar, can you take a look at this issue please? That would be very helpful :) [2009-12-16 17:30:09] alexander at skwar dot name Hm. That's strange. It shouldn't be depending on the version of Solaris. In /usr/include/stdbool.h, there is: #else /* _STDC_C99 */ #error "Use of is valid only in a c99 compilation environment." #endif /* _STDC_C99 */ So, for some reason or the other, you had _STDC_C99 defined. This should only be defined if compiling in C99 mode. I'm right now downloading Solaris 10 U8 to install it in a Virtual Box together with Sun Studio 12.1. I expect it to error out. Out of curiosity: Which version of Solaris 10 are you using? U8? I'm *NOT* using OpenSolaris, BTW. And I find it quite curious that php-5.3.0 compiles and php-5.3.1+ does not. The only difference is the source code of PHP. This kinda leads me to think, that the problem is related to PHP. [2009-12-16 15:47:50] paj...@php.net It builds just fine on the test solaris system provided by Sun. If you have a patch fixing this issue on your platform without breaking other then please post a link to it here. [2009-12-16 15:24:19] alexander at skwar do
#50496 [Asn->Csd]: Use of is valid only in a c99 compilation environment.
ID: 50496 Updated by: srina...@php.net Reported By: alexander at skwar dot name -Status: Assigned +Status: Closed Bug Type: Compile Failure Operating System: Solaris 10, Sparc PHP Version: 5.3SVN-2009-12-16 (snap) Assigned To: srinatar New Comment: [ see also bug #50497 ] thanks for taking time to report this issue. the fix for this issue is now integrated. mean while, your suggested work around (export CFLAGS=- xc99=all) should be acceptable. - Sriram Previous Comments: [2009-12-16 20:49:08] s...@php.net Automatic comment from SVN on behalf of srinatar Revision: http://svn.php.net/viewvc/?view=revision&revision=29 Log: - Fixed bug #50496 (Use of is valid only in a c99 compilation environment.) [2009-12-16 20:45:51] johan...@php.net This is changing it globally, no? - Might this have negative effects (I don't know if C99 breaks C89 code in anyway, while in general I'd like to move to C99 due to the types and some other stuff it offers) And might we have trouble with other non-gcc platforms? [2009-12-16 20:12:39] paj...@php.net hi, Thanks for the quick work :) As long as it affects only Solaris/OpenSolaris, go ahead with the commit. It is not necessary to backport this fix to 5.2 as the crypt addition has been done only in 5.3+. [2009-12-16 20:10:09] srina...@php.net Sun Studio compiler does not by default enable ANSIC C99 standard and its extensions and need to be explicitly enabled. ! this patch addresses this patch by enabling ANSIC99 standard. [srir...@chilidev]'PHP_5_3'>svn diff acinclude.m4 Index: acinclude.m4 === --- acinclude.m4(revision 292219) +++ acinclude.m4(working copy) @@ -2780,7 +2780,7 @@ AC_MSG_RESULT([no]), SUNCC="yes" GCC="no" -test -n "$auto_cflags" && CFLAGS="-O -xs -xstrconst -zlazyload" +test -n "$auto_cflags" && CFLAGS="-O -xc99=all -xs -xstrconst - zlazyload" GCC="" AC_MSG_RESULT([yes]) ) if no one has any objections, i will commit this patch here is the complete patch Index: trunk/acinclude.m4 === --- trunk/acinclude.m4 (revision 292220) +++ trunk/acinclude.m4 (working copy) @@ -2780,7 +2780,7 @@ AC_MSG_RESULT([no]), SUNCC="yes" GCC="no" -test -n "$auto_cflags" && CFLAGS="-O -xs -xstrconst -zlazyload" +test -n "$auto_cflags" && CFLAGS="-O -xc99=all -xs -xstrconst - zlazyload" GCC="" AC_MSG_RESULT([yes]) ) Index: branches/PHP_5_3/acinclude.m4 === --- branches/PHP_5_3/acinclude.m4 (revision 292219) +++ branches/PHP_5_3/acinclude.m4 (working copy) @@ -2780,7 +2780,7 @@ AC_MSG_RESULT([no]), SUNCC="yes" GCC="no" -test -n "$auto_cflags" && CFLAGS="-O -xs -xstrconst -zlazyload" +test -n "$auto_cflags" && CFLAGS="-O -xc99=all -xs -xstrconst - zlazyload" GCC="" AC_MSG_RESULT([yes]) ) Index: branches/PHP_5_3/NEWS === --- branches/PHP_5_3/NEWS (revision 292219) +++ branches/PHP_5_3/NEWS (working copy) @@ -9,6 +9,8 @@ - Changed "post_max_size" php.ini directive to allow unlimited post size by setting it to 0. (Rasmus) +- Fixed bug #50496 (Use of is valid only in a c99 compilation + environment. (Sriram) - Added support for SHA-256 and SHA-512 to php's crypt. (Pierre) - Added realpath_cache_size() and realpath_cache_get() functions. (Stas) - Added FILTER_FLAG_STRIP_BACKTICK option to the filter extension. (Ilia) I will enable xc99=all option in php 5.2 branch after 5.2.12 is released. [2009-12-16 18:25:36] srina...@php.net yup, will look into this today. 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/50496 -- Edit this bug report at http://bugs.php.net/?id=50496&edit=1
#50496 [Asn->Csd]: Use of is valid only in a c99 compilation environment.
ID: 50496 Updated by: srina...@php.net Reported By: alexander at skwar dot name -Status: Assigned +Status: Closed Bug Type: Compile Failure Operating System: Solaris 10, Sparc PHP Version: 5.3SVN-2009-12-16 (snap) Assigned To: srinatar New Comment: on other platforms like HP-UX and AIX as well as gcc, these types (bool, true,false) are defined by simply including the header file. these platforms do not require c99 standard to be defined as pre-requisite to define these macros. at this moment, this seems to be solaris sun studio compiler only issue. Previous Comments: [2009-12-16 21:33:21] s...@php.net Automatic comment from SVN on behalf of srinatar Revision: http://svn.php.net/viewvc/?view=revision&revision=292223 Log: - Fix NEWS for bug #50496 # Update NEWS to keep resolved bugs in decreasing order (Christopher Jones) [2009-12-16 21:10:11] paj...@php.net Pls don't open another bug for the exact same problem. If the header is only available in c99 and c99 can have bad side effects, why not define manually on Solaris what is necessary for the code to work and be done with this problem? [2009-12-16 20:50:29] srina...@php.net [ see also bug #50497 ] thanks for taking time to report this issue. the fix for this issue is now integrated. mean while, your suggested work around (export CFLAGS=- xc99=all) should be acceptable. - Sriram [2009-12-16 20:49:08] s...@php.net Automatic comment from SVN on behalf of srinatar Revision: http://svn.php.net/viewvc/?view=revision&revision=29 Log: - Fixed bug #50496 (Use of is valid only in a c99 compilation environment.) [2009-12-16 20:45:51] johan...@php.net This is changing it globally, no? - Might this have negative effects (I don't know if C99 breaks C89 code in anyway, while in general I'd like to move to C99 due to the types and some other stuff it offers) And might we have trouble with other non-gcc platforms? 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/50496 -- Edit this bug report at http://bugs.php.net/?id=50496&edit=1
