Bug #65936 [Asn-Csd]: dangling context pointer causes crash
Edit report at https://bugs.php.net/bug.php?id=65936edit=1
ID: 65936
Updated by: tony2...@php.net
Reported by:tony2...@php.net
Summary:dangling context pointer causes crash
-Status: Assigned
+Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: *
PHP Version:5.5Git-2013-10-21 (Git)
Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of tony2001
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=b636c03426193ecf0b7e166126a14b70ce8185e9
Log: fix bug #65936 (dangling context pointer causes crash)
Previous Comments:
[2013-10-21 10:52:54] tony2...@php.net
Description:
Pointer to stream context is not cleared in persistent stream struct, which
results in a crash when re-using that stream.
Test script:
---
?php
function connect($host, $port, $timeout = 1) {
$conn_str = tcp://{$host}:{$port};
$opts = STREAM_CLIENT_CONNECT | STREAM_CLIENT_ASYNC_CONNECT |
STREAM_CLIENT_PERSISTENT;
$sock = stream_socket_client($conn_str, $errno, $errstr, $timeout,
$opts);
return $sock;
}
$sock = connect(google.com, 80);
$req = GET / HTTP/1.0\r\nHost: www.google.com\r\nAccept: */*\r\n\r\n;
$len = fwrite($sock, $req);
$data = stream_get_contents($sock);
echo $data;
Expected result:
No crash.
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x00764140 in php_stream_context_get_option (context=0x7fd70dd833f8,
wrappername=0xbe6fae socket, optionname=0xbe6fa7 bindto,
optionvalue=0x7fff2c7b1680) at
/local/git/php-src/main/streams/streams.c:2219
2219if (FAILURE == zend_hash_find(Z_ARRVAL_P(context-options),
(char*)wrappername, strlen(wrappername)+1, (void**)wrapperhash)) {
(gdb) bt
#0 0x00764140 in php_stream_context_get_option
(context=0x7fd70dd833f8, wrappername=0xbe6fae socket, optionname=0xbe6fa7
bindto,
optionvalue=0x7fff2c7b1680) at
/local/git/php-src/main/streams/streams.c:2219
#1 0x00773725 in php_tcp_sockop_connect (stream=0x10e2840,
sock=0x10e08b0, xparam=0x7fff2c7b1780)
at /local/git/php-src/main/streams/xp_socket.c:656
#2 0x00773bc4 in php_tcp_sockop_set_option (stream=0x10e2840,
option=7, value=0, ptrparam=0x7fff2c7b1780)
at /local/git/php-src/main/streams/xp_socket.c:757
#3 0x00761a76 in _php_stream_set_option (stream=0x10e2840, option=7,
value=0, ptrparam=0x7fff2c7b1780)
at /local/git/php-src/main/streams/streams.c:1353
#4 0x0077196e in php_stream_xport_connect (stream=0x10e2840,
name=0x7fd70dd7fc9e google.com:80, namelen=13, asynchronous=1,
timeout=0x7fff2c7b19e0, error_text=0x7fff2c7b18e0,
error_code=0x7fff2c7b19d4) at /local/git/php-src/main/streams/transports.c:243
#5 0x007713fb in _php_stream_xport_create (name=0x7fd70dd7fc9e
google.com:80, namelen=13, options=8, flags=18,
persistent_id=0x7fd70dd82da8 stream_socket_client__tcp://google.com:80,
timeout=0x7fff2c7b19e0, context=0x7fd70dd833f8, error_string=0x7fff2c7b19c0,
error_code=0x7fff2c7b19d4, __php_stream_call_depth=0,
__zend_filename=0xbdf140 /local/git/php-src/ext/standard/streamsfuncs.c,
__zend_lineno=134,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/local/git/php-src/main/streams/transports.c:143
#6 0x00726d3b in zif_stream_socket_client (ht=5,
return_value=0x7fd70dd81690, return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1)
at /local/git/php-src/ext/standard/streamsfuncs.c:131
#7 0x00816f6e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fd70dd4f078) at /local/git/php-src/Zend/zend_vm_execute.h:550
#8 0x0081b868 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fd70dd4f078) at /local/git/php-src/Zend/zend_vm_execute.h:2329
#9 0x0081665f in execute_ex (execute_data=0x7fd70dd4f078) at
/local/git/php-src/Zend/zend_vm_execute.h:363
#10 0x008166e7 in zend_execute (op_array=0x7fd70dd7fd78) at
/local/git/php-src/Zend/zend_vm_execute.h:388
#11 0x007d8554 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /local/git/php-src/Zend/zend.c:1320
#12 0x007452fe in php_execute_script (primary_file=0x7fff2c7b61a0) at
/local/git/php-src/main/main.c:2489
#13 0x00892bcf in main (argc=1, argv=0x7fff2c7b63c8) at
/local/git/php-src/sapi/fpm/fpm/fpm_main.c:1933
--
Edit this bug report at https://bugs.php.net/bug.php?id=65936edit=1
Bug #54054 [Opn-Nab]: Autoload not called in user-defined error handler function in case of E_STRICT
Edit report at https://bugs.php.net/bug.php?id=54054edit=1
ID: 54054
Updated by: tony2...@php.net
Reported by:morpika at vipmail dot hu
Summary:Autoload not called in user-defined error handler
function in case of E_STRICT
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: FreeBSD 8.0
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Here's how it looks:
1) PHP tries to compile a file
2) an error is found and the error handler is triggered (but we're still in
compilation
phase)
3) since we're already in compiler, we can't call the compiler again - the
compiler is
not reentrant, so autoload is skipped.
4) class not found.
This behaviour is by design and isn't going to change without complete rewrite
of
the compiler (if ever).
Previous Comments:
[2013-08-22 09:07:24] ota dot mares at gmail dot com
I have the same issue with a more complex setup using monolog, the custom
monolog
error handler and gelf as logger.
Instead of logging the message Warning: The use statement with non-compound
name
'UnexpectedValueException' has no effect in ...IndexController.php on line 11
the
php error handling hickups, resulting in following error: Fatal error: Class
'Gelf\Message' not found in ...IndexController.php on line 11. Please note
that
the above warning is never shown or logged in this case. All you get is a
confusing fatal message.
In all other scenarios the logging works, which leads to the assumption that
the
autoloading never happens in the given case.
[2012-12-27 09:41:18] nicolas dot grekas+php at gmail dot com
This bug is a duplicate of bug #42098.
[2011-09-14 12:41:59] web at darrengordon dot net
The use of opcoding caching can cause this issue to not be reproducable.
Test steps:
1. Enable opcode caching (APC), restart your httpd to ensure the opcode cache
is clean.
2. Request testa.php to trigger the E_STRICT.
Result:
---
*error_handler(): Declaration of Bar::baz() should be compatible with that of
Foo::baz()
Fatal error: Class 'Error' not found in /path/trigger_e_strict.php on line 3
3. Uncomment line #25: include('doesntexist'); and re-request testa.php to
trigger the E_WARNING.
Result:
---
*error_handler(): include(doesntexist): failed to open stream: No such file or
directory
*__autoload(): Error
*Error::output()
*error_handler(): include(): Failed opening 'doesntexist' for inclusion
(include_path='.:/path:/usr/share/php')
*Error::output()
*error_handler(): Declaration of Bar::baz() should be compatible with that of
Foo::baz()
*Error::output()
4. Recomment line #25: include('doesntexist'); and re-request testa.php to
trigger the E_STRICT.
Result:
---
*error_handler(): Declaration of Bar::baz() should be compatible with that of
Foo::baz()
*_autoload(): Error
*Error::output()
Expected result:
Steps 2. and 4. should output the same result as the code is identical.
Actual result:
Steps 2. and 4. output different results.
Step 2. behaves according to the Actual result of bug #54054.
Step 4. behaves according to the Expected result of bug #54054.
Notes:
This behaviour should be noted when reproducing bug #54054 as it will cause the
issue to not be reproducable.
Environment:
PHP 5.3.2
Apache/2.2.14
Ubuntu 10.04.3 LTS
Code:
testa.php
-
?php
error_reporting(-1);
// Set error handler
set_error_handler('error_handler');
// Error handler
function error_handler($severity, $message)
{
echo *error_handler(): \$message\\n;
return Error::output();
}
// Autoloader
function __autoload($class)
{
echo *__autoload(): \$class\\n;
// Load class 'Error'
eval(class $class {
public static function output() { echo '*' . __CLASS__ .
'::output()\n'; }
});
}
// Trigger E_WARNING - Uncomment to alter opcode cache
//include('doesntexist');
// Trigger E_STRICT
include('testb.php');
?
testb.php
-
?php
// Trigger E_STRICT
class Foo { public function baz($var){} }
class Bar extends Foo { public function baz() {} }
?
[2011-09-14 11:43:03] phil at propcom dot co dot uk
This is still an issue.
The 2 test cases below should hopefully sum this up for you.
Case 1...
include() call fails and generates an E_WARNING
E_WARNING is caught by the error handler
Error handler attempts to use \Error class and calls the autoloader because it
is not currently loaded
...Case 2
The included file (http://codepad.viper-7.com/xyCn8C) generates an E_STRICT
E_STRICT is caught
Bug #60149 [Opn-Nab]: SPL autoloader not called in error handler triggered by private __call
Edit report at https://bugs.php.net/bug.php?id=60149edit=1
ID: 60149
Updated by: tony2...@php.net
Reported by:gedrox at gmail dot com
Summary:SPL autoloader not called in error handler triggered
by private __call
-Status: Open
+Status: Not a bug
Type: Bug
Package:SPL related
Operating System: Ubuntu 11.10
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This is by design, autoload cannot be triggered from compiler.
See my explanation in bug 54054.
Previous Comments:
[2012-01-26 09:30:29] phil at propcom dot co dot uk
This is similar to https://bugs.php.net/bug.php?id=54054. The two may be
related.
[2011-10-27 15:18:57] gedrox at gmail dot com
Description:
No SPL registered autoloader is called inside custom error handler if it has
been
triggered by private __call() magic function what should be public instead.
Test script:
---
http://gedrox.eu/php_spl_autoloader_error_handler_private_call.tar
Run run.php file.
Expected result:
Tried to load class 'DoesNotExist_1'
Caught error 'The magic method __call() must have public visibility and cannot
be
static'
Tried to load class 'DoesNotExist_2'
Done
Actual result:
--
Tried to load class 'DoesNotExist_1'
Caught error 'The magic method __call() must have public visibility and cannot
be static'
Fatal error: Uncaught exception 'RuntimeException' with message 'Assertion
failed on line '66' in LoaderTest.php on line 45
RuntimeException: Assertion failed on line '66'
in LoaderTest.php on line 45
Call Stack:
0.0001 635080 1. {main}() run.php:0
0.0003 665536 2. LoaderTest-testFailure() run.php:6
0.0004 670584 3. assert() LoaderTest.php:66
0.0004 671144 4. LoaderTest-assertionFail() LoaderTest.php:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=60149edit=1
Bug #42098 [Nab]: E_STRICT doesn't trigger __autoload()
Edit report at https://bugs.php.net/bug.php?id=42098edit=1 ID: 42098 Updated by: tony2...@php.net Reported by:nicolas dot grekas+php at gmail dot com Summary:E_STRICT doesn't trigger __autoload() Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.2.3 Block user comment: N Private report: N New Comment: See detailed answer in bug #54054. Previous Comments: [2012-12-28 10:55:04] nicolas dot grekas+php at gmail dot com The error codes concerned by this bug are the ones used in Zend/zend_compile.c: E_STRICT, E_DEPRECATED, E_NOTICE, E_WARNING, E_ERROR, E_CORE_ERROR, E_COMPILE_ERROR and E_COMPILE_WARNING. So virtually no error code is safe. A workaround strategy at source code level would be to stack errors at compile time, then trigger them just when compile time is over. Is it possible? Anyone as a better idea? [2012-12-27 09:41:18] nicolas dot grekas+php at gmail dot com Related To: Bug #54054 [2011-09-14 11:51:47] phil at propcom dot co dot uk This is related to https://bugs.php.net/bug.php?id=54054edit=2 which I have just commented on proving some, hopefully, sane example code. [2010-05-25 11:12:20] i at walkinraven dot name I think autoload will not work in exception_handler or error_handler, that is the problem. [2007-08-17 23:08:16] tony2...@php.net Ah ah ! You play with words :) No, he just said the same thing in other words. The first time, you said : - Only execute time errors can be caught with user error handler., and now: - during compile - autoload wont be triggered There are two stages: 1) compile; 2) execute. Compile-time errors cannot be caught, only execute-time errors can be. But that's still a bug for me in this case. My workaround does exactily what PHP internals should do automagically, nothing more ! This is how the things work. 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 https://bugs.php.net/bug.php?id=42098 -- Edit this bug report at https://bugs.php.net/bug.php?id=42098edit=1
Bug #62172 [Opn-Asn]: FPM not working with Apache httpd 2.4 balancer/fcgi setup
Edit report at https://bugs.php.net/bug.php?id=62172edit=1 ID: 62172 Updated by: tony2...@php.net Reported by:jdr at alexanderinteractive dot com Summary:FPM not working with Apache httpd 2.4 balancer/fcgi setup -Status: Open +Status: Assigned Type: Bug Package:FPM related Operating System: CentOs 6 PHP Version:5.4.3 -Assigned To: +Assigned To:tony2001 Block user comment: N Private report: N Previous Comments: [2012-05-28 01:09:30] jdr at alexanderinteractive dot com I added a quick patch that just duplicates some of the committed proxy:fcgi code. It seemed to work for me. Unfortunately there still seems to be at least 1 issue on the apache side. When adding query strings to a php page, I get 404s. This works fine without the balancer set up. It could be related to this bug https://issues.apache.org/bugzilla/show_bug.cgi?id=51077 [2012-05-27 22:27:00] jdr at alexanderinteractive dot com Description: See bug https://bugs.php.net/bug.php?id=54152 for a description of almost the exact same problem. PHP now does recognize the proxy:fcgi Apache httpd 2.4 adds to the SCRIPT_FILENAME but it does not recognize proxy:balancer Test script: --- Example of working apache 2.4 config RewriteRule ^/?(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/usr/local/home/magento/app/current/$1 [P,L] Example of non-working apache 2.4 config Proxy balancer://magento/ BalancerMember fcgi://localhost:9000/ /Proxy # Serve PHP through php-fpm: RewriteRule ^/?(.*\.php(/.*)?)$ balancer://magento/usr/local/home/magento/app/current/$1 [P,L] Expected result: I expect the same results from both apache configurations Actual result: -- I get a 404 on all php pages when using balancer -- Edit this bug report at https://bugs.php.net/bug.php?id=62172edit=1
Bug #61285 [Opn]: SSL connections do not timeout
Edit report at https://bugs.php.net/bug.php?id=61285edit=1
ID: 61285
Updated by: tony2...@php.net
Reported by:tony2...@php.net
Summary:SSL connections do not timeout
Status: Open
Type: Bug
Package:OpenSSL related
PHP Version:5.4SVN-2012-03-05 (SVN)
Block user comment: N
Private report: N
New Comment:
Uhm.. for some reason Github shows a lot of whitespace changes there.
Could you try to rewrite the patch to avoid them?
Previous Comments:
[2013-01-20 18:38:01] bbroerman at bbroerman dot net
I have a proposed fix on my Github repo: https://github.com/bbroerman30/php-src
I have tested timeouts of various amounts with blocking sockets, but haven't
tried to check other side-effects as of yet.
How it works is within the read/write methods themselves, if the socket is
blocking and has a timeout set, it will change the socket (temporarily) to
non-blocking, and check the response from the attempted read/write with
SSL_get_error and then wait/retry based on the response from SSL_get_error and
using php_pollfd_for.
When I get a chance (probably next week or so) I'll try to test the below bug,
and test with non-blocking streams.
Please feel free to test as you need, and let me know if you find any bugs.
[2012-03-05 12:37:02] paj...@php.net
I am not sure anymore that this patch is correct as it looks as it will
reintroduce the issue introduced by a previous attempt to fix that, which was
reverted here:
http://svn.php.net/viewvc?view=revisionrevision=315310
[2012-03-05 12:08:40] tony2...@php.net
The following patch has been added/updated:
Patch Name: ssl_timeout.diff
Revision: 1330949320
URL:
https://bugs.php.net/patch-display.php?bug=61285patch=ssl_timeout.diffrevision=1330949320
[2012-03-05 12:08:11] tony2...@php.net
Description:
SSL connections never timeout because poll() isn't even used in ext/openssl.
Test script:
---
server.php:
?php sleep(20); ?
client.php:
?php ini_set('default_socket_timeout',1);
var_dump(file_get_contents(https://localhost/server.php;)); ?
Expected result:
# time php client.php
Warning: file_get_contents(https://localhost/server.php): failed to open
stream: HTTP request failed! in /tmp/client.php on line 1
bool(false)
real0m2.024s
user0m0.012s
sys 0m0.003s
Actual result:
--
# time php client.php
string(0)
real0m20.063s
user0m0.012s
sys 0m0.005s
--
Edit this bug report at https://bugs.php.net/bug.php?id=61285edit=1
Bug #63992 [Opn-Asn]: php not use default openSSH confing
Edit report at https://bugs.php.net/bug.php?id=63992edit=1 ID: 63992 Updated by: tony2...@php.net Reported by:mikhail dot v dot gavrilov at gmail dot com Summary:php not use default openSSH confing -Status: Open +Status: Assigned Type: Bug Package:OpenSSL related Operating System: RHEL/Fedora PHP Version:5.4.11RC1 -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N Previous Comments: [2013-01-15 14:51:34] mikhail dot v dot gavrilov at gmail dot com Description: For using GOST encryption engine: 1. i compiled openSSH with GOST support 2. added the following lines in openssl.cnf openssl_conf = openssl_def [openssl_def] engines = engine_section [engine_section] gost = gost_section [gost_section] engine_id = gost default_algorithms = ALL dynamic_path = /usr/lib/openssl/engines/libgost.so CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet But when I use curl PHP still get error: 'Cannot communicate securely with peer: no common encryption algorithm(s).' Than I search I find this solution: http://stackoverflow.com/questions/10959771/openssl-and-gost-engine-issue- statically-linked So I create patch *** 111/openssl.c 2012-12-19 12:55:19.0 +0600 --- openssl.c 2013-01-15 18:43:22.0 +0600 *** *** 1038,1043 --- 1038,1046 le_x509 = zend_register_list_destructors_ex(php_x509_free, NULL, OpenSSL X.509, module_number); le_csr = zend_register_list_destructors_ex(php_csr_free, NULL, OpenSSL X.509 CSR, module_number); + /* needed for use default config */ + OPENSSL_config(NULL); + SSL_library_init(); OpenSSL_add_all_ciphers(); OpenSSL_add_all_digests(); and my script became work. Test script: --- $address=https://icrs.nbki.ru/products/B2BRequestServlet;; // $proxy = '10.10.4.24:3128'; $xml = ''; $ch = curl_init($address); $page = Xml.php; $headers = array( POST .$page. HTTP/1.0, content-type:application/octet-stream;charset=\windows-1251\, ); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_POSTFIELDS, $xml); if(isset($proxy)) curl_setopt($ch, CURLOPT_PROXY, $proxy); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); $response = curl_exec($ch);if ($response === false) throw new Exception(curl_error($ch)); curl_close($ch); -- Edit this bug report at https://bugs.php.net/bug.php?id=63992edit=1
Bug #36103 [NoF]: ftp ssl connection fails during login
Edit report at https://bugs.php.net/bug.php?id=36103edit=1
ID: 36103
Updated by: tony2...@php.net
Reported by:rebe at unit01 dot net
Summary:ftp ssl connection fails during login
Status: No Feedback
Type: Bug
Package:FTP related
Operating System: linux
PHP Version:5.1.2
Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
@erez dot h at zend dot com
I guess it would be better to create a new bug report and add an up to date
reproduce case while you're at it.
Adding some more explanations to the patch would be a good idea, too.
You can also go an other way and send your patch directly to Dmitry for review,
dmi...@zend.com/dmi...@php.net I mean.
Previous Comments:
[2012-12-11 15:15:58] erez dot h at zend dot com
we still have this issue on windows php build 5.3.19 and 5.4.9 so we
implemented
this patch which solve the issue. please see if you can add to future versions.
diff -ruN php-5.3.19.orig/ext/ftp/ftp.c php-5.3.19/ext/ftp/ftp.c
--- php-5.3.19.orig/ext/ftp/ftp.c 2012-11-21 22:07:23.0 +0200
+++ php-5.3.19/ext/ftp/ftp.c2012-12-11 16:49:21.359682714 +0200
@@ -241,6 +241,7 @@
int
ftp_login(ftpbuf_t *ftp, const char *user, const char *pass TSRMLS_DC)
{
+ int errcode;
#if HAVE_OPENSSL_EXT
SSL_CTX *ctx = NULL;
#endif
@@ -289,13 +290,27 @@
}
SSL_set_fd(ftp-ssl_handle, ftp-fd);
-
- if (SSL_connect(ftp-ssl_handle) = 0) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING, SSL/TLS
handshake failed);
- SSL_shutdown(ftp-ssl_handle);
- return 0;
- }
-
+
+ do {
+ errcode = SSL_connect(ftp-ssl_handle);
+ switch (SSL_get_error (ftp-ssl_handle,
errcode)) {
+ case SSL_ERROR_NONE:
+ errcode = 1;
+ break;
+ case SSL_ERROR_WANT_WRITE:
+ case SSL_ERROR_WANT_READ:
+ case SSL_ERROR_WANT_X509_LOOKUP:
+ errcode = 0;
+ break;
+ default:
+ /* true error happened */
+ php_error_docref(NULL
TSRMLS_CC,
E_WARNING, SSL/TLS handshake failed);
+ SSL_shutdown(ftp-ssl_handle);
+ return 0;
+ break;
+ }
+ } while(errcode == 0 !SSL_is_init_finished(ftp-
ssl_handle));
+
ftp-ssl_active = 1;
if (!ftp-old_ssl) {
@@ -1493,6 +1508,7 @@
php_sockaddr_storage addr;
socklen_t size;
+ int errcode;
#if HAVE_OPENSSL_EXT
SSL_CTX *ctx;
#endif
@@ -1537,11 +1553,26 @@
SSL_copy_session_id(data-ssl_handle, ftp-ssl_handle);
}
- if (SSL_connect(data-ssl_handle) = 0) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING,
data_accept: SSL/TLS handshake failed);
- SSL_shutdown(data-ssl_handle);
- return 0;
- }
+
+ do {
+ errcode = SSL_connect(data-ssl_handle);
+ switch (SSL_get_error (data-ssl_handle, errcode)) {
+ case SSL_ERROR_NONE:
+ errcode = 1;
+ break;
+ case SSL_ERROR_WANT_WRITE:
+ case SSL_ERROR_WANT_READ:
+ case SSL_ERROR_WANT_X509_LOOKUP:
+ errcode = 0;
+ break;
+ default:
+ /* true error happened */
+ php_error_docref(NULL TSRMLS_CC,
E_WARNING, data_accept: SSL/TLS handshake failed);
+ SSL_shutdown(data-ssl_handle);
+ return 0;
+ break;
+ }
+ } while(errcode == 0 !SSL_is_init_finished(data-
ssl_handle));
data-ssl_active = 1
Bug #63455 [Opn-Nab]: SIGSEGV
Edit report at https://bugs.php.net/bug.php?id=63455edit=1
ID: 63455
Updated by: tony2...@php.net
Reported by:jakub dot galczyk at gmail dot com
Summary:SIGSEGV
-Status: Open
+Status: Not a bug
Type: Bug
-Package:*Math Functions
+Package:PCRE related
Operating System: Ubuntu
PHP Version:5.4.8
Block user comment: N
Private report: N
New Comment:
This is PCRE overflowing the stack due to an (endless?) recursion in your
regular
expression.
It's a well known PCRE problem and solutions to it are described here:
http://manpages.courier-mta.org/htmlman3/pcrestack.3.html
and here:
http://pcre.org/pcre.txt (look for STACK USAGE)
Previous Comments:
[2012-11-07 14:34:49] jakub dot galczyk at gmail dot com
More info:
(gdb) bt
(...)
#21790 0x080b8f3b in php_pcre_exec (argument_re=0x4657380,
extra_data=0xbe9e6ed4,
subject=0x43c3abc HTTP/1.1 302 Found\r\nDate: Wed, 07 Nov 2012 13:14:24
GMT\r\nServer: Apache/2.2.22 (Ubuntu)\r\nX-Powered-By:
PHP/5.3.10-1ubuntu3.4\r\nCache-Control: no-cache, must-revalidate\r\nExpires:
Sat, 26 Jul 1997 05:00:..., length=11527, start_offset=0, options=0,
offsets=0x43bad0c, offsetcount=6)
at /home/kuba/src/php-5.4.8/ext/pcre/pcrelib/pcre_exec.c:6098
#21791 0x080bd6cd in php_pcre_match_impl (pce=0x46574d8,
subject=0x43c3abc HTTP/1.1 302 Found\r\nDate: Wed, 07 Nov 2012 13:14:24
GMT\r\nServer: Apache/2.2.22 (Ubuntu)\r\nX-Powered-By:
PHP/5.3.10-1ubuntu3.4\r\nCache-Control: ---Type return to continue, or q
return to quit---
no-cache, must-revalidate\r\nExpires: Sat, 26 Jul 1997 05:00:...,
subject_len=11527, return_value=0x43c20a4, subpats=0x43bd784, global=0,
use_flags=0, flags=0,
start_offset=0) at /home/kuba/src/php-5.4.8/ext/pcre/php_pcre.c:634
#21792 0x080be13d in php_do_pcre_match (ht=3, return_value=0x43c20a4, global=0,
return_value_ptr=optimized out, this_ptr=optimized out,
return_value_used=optimized out) at
/home/kuba/src/php-5.4.8/ext/pcre/php_pcre.c:528
#21793 0x08374d58 in zend_do_fcall_common_helper_SPEC (execute_data=optimized
out) at /home/kuba/src/php-5.4.8/Zend/zend_vm_execute.h:642
#21794 0x08337ced in execute (op_array=optimized out) at
/home/kuba/src/php-5.4.8/Zend/zend_vm_execute.h:410
#21795 0x082d9a93 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/kuba/src/php-5.4.8/Zend/zend.c:1309
#21796 0x0827a6b2 in php_execute_script (primary_file=0xbe9e93dc) at
/home/kuba/src/php-5.4.8/main/main.c:2482
#21797 0x0837749e in do_cli (argc=4, argv=0xbe9ea664) at
/home/kuba/src/php-5.4.8/sapi/cli/php_cli.c:988
#21798 0x08067254 in main (argc=4, argv=0xbe9ea664) at
/home/kuba/src/php-5.4.8/sapi/cli/php_cli.c:1364
(gdb)
(gdb)
(gdb) x/10i 0x80a99bb
= 0x80a99bb match+5787: mov%edi,0x8(%esp)
0x80a99bf match+5791: mov%ebp,0x14(%esp)
0x80a99c3 match+5795: mov0x40(%esp),%ebp
0x80a99c7 match+5799: movzbl 0x83e2dc0(%eax),%eax
0x80a99ce match+5806: mov%ebp,0x10(%esp)
0x80a99d2 match+5810: mov0x3c(%esp),%ebp
0x80a99d6 match+5814: lea(%esi,%eax,1),%edx
0x80a99d9 match+5817: mov0x30(%esp),%eax
0x80a99dd match+5821: mov%ebp,0xc(%esp)
0x80a99e1 match+5825: mov0x184(%esp),%ebp
(gdb) p $1
History has not yet reached $1.
(gdb) p $eip
$1 = (void (*)()) 0x80a99bb match+5787
(gdb) i r
eax0x43bad2071019808
ecx0x43c3abc71056060
edx0x2a8e 10894
ebx0x43c654a71066954
esp0xbe1ebfd0 0xbe1ebfd0
ebp0x0 0x0
esi0x46573ac73757612
edi0xbe9e6d80 -1096913536
eip0x80a99bb0x80a99bb match+5787
eflags 0x4 [ PF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x0 0
fs 0x0 0
gs 0xb 11
(gdb) list
817 (int)(eptr - md-start_subject);
818
819 flags = (op == OP_SCBRA)? match_cbegroup : 0;
820 do
821 {
822 RMATCH(eptr, ecode + _pcre_OP_lengths[*ecode], offset_top, md,
823 ims, eptrb, flags, RM1);
824 if (rrc != MATCH_NOMATCH
825 (rrc != MATCH_THEN || md-start_match_ptr != ecode))
826 RRETURN(rrc);
(gdb)
827 md-capture_last = save_capture_last;
828 ecode += GET(ecode, 1);
829 }
830 while (*ecode == OP_ALT);
831
832 DPRINTF((bracket %d failed\n, number));
833
834 md-offset_vector[offset] = save_offset1;
835 md-offset_vector[offset+1] = save_offset2;
836 md-offset_vector[md-offset_end - number] = save_offset3;
(gdb) \q
kuba@box:~/src/php-5.4.8$ grep -n -r -e
Bug #63369 [Opn-Csd]: (un)serialize() leaves dangling pointers, causes crashes
Edit report at https://bugs.php.net/bug.php?id=63369edit=1
ID: 63369
Updated by: tony2...@php.net
Reported by:tony2...@php.net
Summary:(un)serialize() leaves dangling pointers, causes
crashes
-Status: Open
+Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: *
PHP Version:5.4Git-2012-10-26 (Git)
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of tony2001
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=f2bffdc2e48174e38a059d425953e8b1c08dd4bf
Log: fix bug #63369
Previous Comments:
[2012-10-26 12:24:03] tony2...@php.net
The following patch has been added/updated:
Patch Name: the-patch
Revision: 1351254242
URL:
https://bugs.php.net/patch-display.php?bug=63369patch=the-patchrevision=1351254242
[2012-10-26 12:23:16] tony2...@php.net
Description:
When a fatal error happens in a __sleep/__wakeup function, BG(serialize) and
BG(unserialize) contents is left intact and the next request will get those
pointers
again, even though at that moment they are already freed by Zend memory manager
during request shutdown.
If you're lucky, there is a chance you'll reuse them, which causes immediate
crash.
The attached scripts demonstrates the problem with serialize() and I'm kinda
lazy to
do the same for unserialize(), especially taking into account that the patch is
extremely simple.
Test script:
---
class bar1 {
function __sleep() {
foo();
}
}
class foo1 {
function __sleep() {
var_dump(serialize(array(test, 1, 234)));
var_dump(serialize(new bar1));
}
}
$o = new foo1;
var_dump(unserialize('O:8:stdclass:0:{}')); //to clear BG(serialize_lock)
var_dump(serialize($o));
Expected result:
.
Actual result:
--
.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63369edit=1
Bug #63369 [Csd]: (un)serialize() leaves dangling pointers, causes crashes
Edit report at https://bugs.php.net/bug.php?id=63369edit=1
ID: 63369
Updated by: tony2...@php.net
Reported by:tony2...@php.net
Summary:(un)serialize() leaves dangling pointers, causes
crashes
Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: *
PHP Version:5.4Git-2012-10-26 (Git)
-Assigned To:
+Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
Merged patches f2bffdc and 01dee2c.
Previous Comments:
[2012-10-26 12:43:29] tony2...@php.net
Automatic comment on behalf of tony2001
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=01dee2c4b009d052f0fdfa07f35c181a1ac4aca0
Log: fix bug #63369
[2012-10-26 12:43:08] tony2...@php.net
Automatic comment on behalf of tony2001
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=f2bffdc2e48174e38a059d425953e8b1c08dd4bf
Log: fix bug #63369
[2012-10-26 12:24:03] tony2...@php.net
The following patch has been added/updated:
Patch Name: the-patch
Revision: 1351254242
URL:
https://bugs.php.net/patch-display.php?bug=63369patch=the-patchrevision=1351254242
[2012-10-26 12:23:16] tony2...@php.net
Description:
When a fatal error happens in a __sleep/__wakeup function, BG(serialize) and
BG(unserialize) contents is left intact and the next request will get those
pointers
again, even though at that moment they are already freed by Zend memory manager
during request shutdown.
If you're lucky, there is a chance you'll reuse them, which causes immediate
crash.
The attached scripts demonstrates the problem with serialize() and I'm kinda
lazy to
do the same for unserialize(), especially taking into account that the patch is
extremely simple.
Test script:
---
class bar1 {
function __sleep() {
foo();
}
}
class foo1 {
function __sleep() {
var_dump(serialize(array(test, 1, 234)));
var_dump(serialize(new bar1));
}
}
$o = new foo1;
var_dump(unserialize('O:8:stdclass:0:{}')); //to clear BG(serialize_lock)
var_dump(serialize($o));
Expected result:
.
Actual result:
--
.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63369edit=1
Req #63085 [Opn-Asn]: Systemd integration and daemonize
Edit report at https://bugs.php.net/bug.php?id=63085edit=1 ID: 63085 Updated by: tony2...@php.net Reported by:r...@php.net Summary:Systemd integration and daemonize -Status: Open +Status: Assigned Type: Feature/Change Request Package:FPM related Operating System: GNU/Linux (Fedora 17) PHP Version:5.4.7 -Assigned To: +Assigned To:fat Block user comment: N Private report: N Previous Comments: [2012-09-19 15:03:37] r...@php.net In the proposed php-fpm-systemd.patch: - add --daemonize option, and update init.d to use it - add --nodaemonize option - update --help output - update man page for new options and systemd use - add systemd unit file, which use --nodaemonize [2012-09-19 15:00:17] r...@php.net The following patch has been added/updated: Patch Name: php-fpm-systemd.patch Revision: 1348066817 URL: https://bugs.php.net/patch-display.php?bug=63085patch=php-fpm-systemd.patchrevision=1348066817 [2012-09-14 05:43:02] r...@php.net I have join the systemd unit file used in Fedora. Note : type=Forking is not present, so this rely on daemonize=no in config file. It could be great to have this unit file (made more generic if needed) provided in php distribution. [2012-09-14 05:41:08] r...@php.net The following patch has been added/updated: Patch Name: php-fpm.service Revision: 1347601268 URL: https://bugs.php.net/patch-display.php?bug=63085patch=php-fpm.servicerevision=1347601268 [2012-09-14 05:40:12] r...@php.net Description: Currently daemonize is a option taken from configuration file. I think is is quite ugly to have a starting script of systemd unit file to rely on a external configuration file. I think a command line option will be more robust. For ex, - in init script we could launch php-fpm --daemonize - in systemd unit, we could launch php-fpm --nodaemonize Without command line option, I propose to keep reading option from the config file (to not break existing configuration). We could also imagine another option (--debug) which run in foreground and log everything need thing to screen (for interactive run). What do you think ? I could propose a patch -- Edit this bug report at https://bugs.php.net/bug.php?id=63085edit=1
Bug #62954 [Fbk]: startup problems fpm / php-fpm
Edit report at https://bugs.php.net/bug.php?id=62954edit=1 ID: 62954 Updated by: tony2...@php.net Reported by:jonas at brachium-system dot net Summary:startup problems fpm / php-fpm Status: Feedback Type: Bug Package:FPM related Operating System: Linux PHP Version:5.3Git-2012-08-27 (Git) Assigned To:fat Block user comment: N Private report: N New Comment: jonas@ Then I start it without debugger it hangs. :( then attach to the freezed process after that. just `gdb attach pid`, then `bt full` and post the result here. per@ Great, so you have a core file. Now type: gdb /usr/sbin/php-fpm /var/spool/abrt/ccpp-2012-09-13-09:45:51-10923 bt full and post the result here. Previous Comments: [2012-09-13 14:50:24] per at techspot dot com Upgraded to PHP v5.4.7 but the issue remains: [root@dev01 ~]# service php-fpm stop Stopping php-fpm: [ OK ] [root@dev01 ~]# ps aux | grep php root 10912 0.0 0.0 103244 840 pts/0S+ 09:45 0:00 grep php [root@dev01 ~]# service php-fpm start Starting php-fpm: /bin/bash: line 1: 10923 Segmentation fault (core dumped) php-fpm [FAILED] [root@dev01 ~]# ps aux | grep php root 10924 0.0 0.1 516912 5096 ?Ss 09:45 0:00 php-fpm: master process (/etc/php-fpm.conf) nginx10926 0.0 0.1 516912 4256 ?S09:45 0:00 php-fpm: pool www nginx10927 0.0 0.1 516912 4256 ?S09:45 0:00 php-fpm: pool www nginx10928 0.0 0.1 516912 4256 ?S09:45 0:00 php-fpm: pool www nginx10929 0.0 0.1 516912 4256 ?S09:45 0:00 php-fpm: pool www nginx10930 0.0 0.1 516912 4256 ?S09:45 0:00 php-fpm: pool www /var/log/messages: Sep 13 09:45:51 dev01 kernel: php-fpm[10923]: segfault at 3b25051598 ip 003b1ca0eb83 sp 7fffe9cace00 error 4 in ld-2.12.so[3b1ca0+2] Sep 13 09:45:51 dev01 abrt[10925]: Saved core dump of pid 10923 (/usr/sbin/php-fpm) to /var/spool/abrt/ccpp-2012-09-13-09:45:51-10923 (5709824 bytes) Sep 13 09:45:51 dev01 abrtd: Directory 'ccpp-2012-09-13-09:45:51-10923' creation detected Sep 13 09:45:51 dev01 abrtd: Package 'php-fpm' isn't signed with proper key Sep 13 09:45:51 dev01 abrtd: 'post-create' on '/var/spool/abrt/ccpp-2012-09-13-09:45:51-10923' exited with 1 Sep 13 09:45:51 dev01 abrtd: Corrupted or bad directory /var/spool/abrt/ccpp-2012-09-13-09:45:51-10923, deleting [2012-09-13 10:54:57] jonas at brachium-system dot net This only shows us that FPM has successfully forked to detach from the console. It didn't hang, crash or exit, it's still running and you can see it yourself: `ps afx | grep php` yep. every time I start php-fpm with gdb it forks and detach the process correctly. Then I start it without debugger it hangs. :( [2012-09-12 09:17:54] tony2...@php.net Program received signal SIGUSR1, User defined signal 1 This only shows us that FPM has successfully forked to detach from the console. It didn't hang, crash or exit, it's still running and you can see it yourself: `ps afx | grep php` [2012-09-10 19:32:56] jonas at brachium-system dot net I have pulled the current PHP-5.3 branch and compile it with: ./configure --prefix=/usr --enable-fpm --enable-bcmath --with-bz2 --enable-calendar --with-curl --enable-dba --enable-exif --enable-ftp --enable-gd-native-ttf --with-jpeg-dir --with-png-dir --with-t1lib --with-freetype-dir --with-gettext --enable-mbstring --with-mcrypt --with-mhash --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --enable-mysqlnd --with-openssl --with-pcre-regex --with-pspell --enable-shmop --enable-soap --enable-sockets --enable-sysvmsg --enable-wddx --with-xsl --enable-zip --with-zlib --with-tcadb --with-openssl-dir --with-gd --enable-debug I have started PHP with gdb: - root@testm64:/home/jonas/php-src# gdb sapi/fpm/php-fpm GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/jonas/php-src/sapi/fpm/php-fpm...done. warning: not using untrusted file /home/jonas/php-src/.gdbinit (gdb) run Starting program:
Bug #62954 [Fbk]: startup problems fpm / php-fpm
Edit report at https://bugs.php.net/bug.php?id=62954edit=1 ID: 62954 Updated by: tony2...@php.net Reported by:jonas at brachium-system dot net Summary:startup problems fpm / php-fpm Status: Feedback Type: Bug Package:FPM related Operating System: Linux PHP Version:5.3Git-2012-08-27 (Git) Assigned To:fat Block user comment: N Private report: N New Comment: Program received signal SIGUSR1, User defined signal 1 This only shows us that FPM has successfully forked to detach from the console. It didn't hang, crash or exit, it's still running and you can see it yourself: `ps afx | grep php` Previous Comments: [2012-09-10 19:32:56] jonas at brachium-system dot net I have pulled the current PHP-5.3 branch and compile it with: ./configure --prefix=/usr --enable-fpm --enable-bcmath --with-bz2 --enable-calendar --with-curl --enable-dba --enable-exif --enable-ftp --enable-gd-native-ttf --with-jpeg-dir --with-png-dir --with-t1lib --with-freetype-dir --with-gettext --enable-mbstring --with-mcrypt --with-mhash --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --enable-mysqlnd --with-openssl --with-pcre-regex --with-pspell --enable-shmop --enable-soap --enable-sockets --enable-sysvmsg --enable-wddx --with-xsl --enable-zip --with-zlib --with-tcadb --with-openssl-dir --with-gd --enable-debug I have started PHP with gdb: - root@testm64:/home/jonas/php-src# gdb sapi/fpm/php-fpm GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/jonas/php-src/sapi/fpm/php-fpm...done. warning: not using untrusted file /home/jonas/php-src/.gdbinit (gdb) run Starting program: /home/jonas/php-src/sapi/fpm/php-fpm [Thread debugging using libthread_db enabled] Program received signal SIGUSR1, User defined signal 1. 0x749c8380 in ?? () from /lib/libc.so.6 (gdb) bt #0 0x749c8380 in ?? () from /lib/libc.so.6 #1 0x749cb94c in free () from /lib/libc.so.6 #2 0x009d416e in zend_hash_destroy (ht=0x132c170) at /home/jonas/php-src/Zend/zend_hash.c:532 #3 0x009c2cd3 in zend_shutdown () at /home/jonas/php-src/Zend/zend.c:773 #4 0x0094b6a3 in php_module_shutdown () at /home/jonas/php-src/main/main.c:2186 #5 0x00abb116 in fpm_php_cleanup (which=2, arg=0x0) at /home/jonas/php-src/sapi/fpm/fpm/fpm_php.c:199 #6 0x00ab009d in fpm_cleanups_run (type=2) at /home/jonas/php-src/sapi/fpm/fpm/fpm_cleanup.c:45 #7 0x00ac2109 in fpm_unix_init_main () at /home/jonas/php-src/sapi/fpm/fpm/fpm_unix.c:312 #8 0x00aaed7b in fpm_init (argc=1, argv=0x7fffe788, config=0x0, prefix=0x0, pid=0x0, test_conf=0, run_as_root=0) at /home/jonas/php-src/sapi/fpm/fpm/fpm.c:59 #9 0x00aba69c in main (argc=1, argv=0x7fffe788) at /home/jonas/php-src/sapi/fpm/fpm/fpm_main.c:1805 [2012-09-10 13:18:31] tony2...@php.net #4 0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0 #5 0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0 This looks like a problem of your system's PCRE library. No idea why would you use it instead of the bundled, but can you just try a plain PHP version provided from php.net and see if you still can reproduce the problem? Preferably a recent snapshot, preferable without any external libs and opcode caches. This'll help us to understand if this is a genuine FPM problem or something different. [2012-09-05 17:06:39] rainer-phpbugs at 7val dot com I can reproduce this problem with php 5.3.16 on SLES 11.2 x86_64 (after about 20 attempts on average), but not on Ubuntu 12.04.1 x86_64 or Centos (RHEL) 6.3 (no problem after more than 2000 restarts each). remove_usr1_usr2_fpm_unix.patch reliably fixes this problem for me. gdb backtraces of the hanging process always look like this (taken on opensuse 11 i386): #0 0xe424 in __kernel_vsyscall () #1 0xb4fe3e53 in __lll_lock_wait_private () from /lib/libc.so.6 #2 0xb4f762fb in _L_lock_10372 () from /lib/libc.so.6 #3 0xb4f74a66 in free () from /lib/libc.so.6 #4 0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0 #5 0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0 #6 0xb4f3089f in __run_exit_handlers () from /lib/libc.so.6
Bug #62954 [Fbk]: startup problems fpm / php-fpm
Edit report at https://bugs.php.net/bug.php?id=62954edit=1
ID: 62954
Updated by: tony2...@php.net
Reported by:jonas at brachium-system dot net
Summary:startup problems fpm / php-fpm
Status: Feedback
Type: Bug
Package:FPM related
Operating System: Linux
PHP Version:5.3Git-2012-08-27 (Git)
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
#4 0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0
#5 0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0
This looks like a problem of your system's PCRE library.
No idea why would you use it instead of the bundled, but can you just try a
plain PHP version provided from php.net and see if you still can reproduce the
problem? Preferably a recent snapshot, preferable without any external libs and
opcode caches.
This'll help us to understand if this is a genuine FPM problem or something
different.
Previous Comments:
[2012-09-05 17:06:39] rainer-phpbugs at 7val dot com
I can reproduce this problem with php 5.3.16 on SLES 11.2 x86_64 (after about
20 attempts on average), but not on Ubuntu 12.04.1 x86_64 or Centos (RHEL) 6.3
(no problem after more than 2000 restarts each).
remove_usr1_usr2_fpm_unix.patch reliably fixes this problem for me.
gdb backtraces of the hanging process always look like this (taken on opensuse
11 i386):
#0 0xe424 in __kernel_vsyscall ()
#1 0xb4fe3e53 in __lll_lock_wait_private () from /lib/libc.so.6
#2 0xb4f762fb in _L_lock_10372 () from /lib/libc.so.6
#3 0xb4f74a66 in free () from /lib/libc.so.6
#4 0xb42fcd66 in pcrecpp::RE::Cleanup() () from /usr/lib/libpcrecpp.so.0
#5 0xb42fce02 in pcrecpp::RE::~RE() () from /usr/lib/libpcrecpp.so.0
#6 0xb4f3089f in __run_exit_handlers () from /lib/libc.so.6
#7 0xb4f308fd in exit () from /lib/libc.so.6
#8 0x084c382f in fpm_signals_sighandler_exit_ok (pid=10) at
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_signals.c:254
#9 signal handler called
#10 0xb4f70701 in _int_free () from /lib/libc.so.6
#11 0xb4f74a6d in free () from /lib/libc.so.6
#12 0x08426de0 in zend_hash_destroy (ht=0x891088c) at
build/src/external/php-5.3.16/Zend/zend_hash.c:532
#13 0x08404762 in destroy_zend_class (pce=0x8911cb4) at
build/src/external/php-5.3.16/Zend/zend_opcode.c:206
#14 0x08426dc8 in zend_hash_destroy (ht=0x87aa490) at
build/src/external/php-5.3.16/Zend/zend_hash.c:529
#15 0x08414ed7 in zend_shutdown () at
build/src/external/php-5.3.16/Zend/zend.c:762
#16 0x083a84da in php_module_shutdown () at
build/src/external/php-5.3.16/main/main.c:2210
#17 0x084bf608 in fpm_php_cleanup (which=2, arg=0x0) at
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_php.c:199
#18 0x084b5f0c in fpm_cleanups_run (type=2) at
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_cleanup.c:45
#19 0x084c6c73 in fpm_unix_init_main () at
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_unix.c:340
#20 0x084b4fe8 in fpm_init (argc=3, argv=0xbffb2fe4, config=0xbffb50a5
conf/php-fpm.conf, prefix=0x0, pid=0x0, test_conf=0,
run_as_root=0) at build/src/external/php-5.3.16/sapi/fpm/fpm/fpm.c:59
#21 0x084be0f5 in main (argc=3, argv=0xbffb2fe4) at
build/src/external/php-5.3.16/sapi/fpm/fpm/fpm_main.c:1805
[2012-09-05 07:25:26] jonas at brachium-system dot net
@David: Can you please explain, why an NGINX configuration option will solve
that startup problem?
[2012-09-02 19:47:46] david at appliedautonomics dot com
Fixed on Debian Squeez via adding to fastcgi params:
fastcgi_buffer_size 16k;
fastcgi_buffers 4 16k;
[2012-09-02 16:43:24] per at techspot dot com
This bug occurs more frequently on heavily loaded websites.
On my testserver it is difficult to reproduce with a low load.
But on my live server doing a service php-fpm restart makes it fail most
times.
For some reason the problem occurs less frequently in php-fpm 5.4.6 vs 5.3.16
opcode cachers also makes it occur more frequently, but it's possible to
reproduce with no opcode cacher loaded aswell, same rules as above for
frequency still apply (5.3 vs 5.4)
Output from testserver below running CentOS v6.3 with all patches applied and
php v5.4 via the remi repository:
http://rpms.famillecollet.com/enterprise/6/test/x86_64/
# php -v
PHP 5.4.6 (cli) (built: Aug 16 2012 14:26:39)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
with XCache v2.0.1, Copyright (c) 2005-2012, by mOo
# DAEMON_COREFILE_LIMIT=unlimited strace -s1024 -f /etc/init.d/php-fpm restart
21 | grep -i SEGV
[pid 3017] rt_sigaction(SIGSEGV, {0x7fddd5050730, [SEGV],
Bug #62954 [Asn-Fbk]: startup problems fpm / php-fpm
Edit report at https://bugs.php.net/bug.php?id=62954edit=1
ID: 62954
Updated by: tony2...@php.net
Reported by:jonas at brachium-system dot net
Summary:startup problems fpm / php-fpm
-Status: Assigned
+Status: Feedback
Type: Bug
Package:FPM related
Operating System: Linux
PHP Version:5.3Git-2012-08-27 (Git)
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
I can't reproduce it here:
# /tmp/fpm/sbin/php-fpm -v
PHP 5.4.8-dev (fpm-fcgi) (built: Sep 1 2012 23:36:17) (DEBUG)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
It starts, spawns its children and detaches from terminal with no problem at
all.
Can you try the latest snapshot and check if you still can reproduce the issue?
Previous Comments:
[2012-08-27 22:54:12] al-php at none dot at
same problem here.
./configure --prefix=/prefix/ --enable-fpm --enable-bcmath --with-bz2
--enable-calendar --with-curl --enable-dba --enable-exif --enable-ftp
--enable-gd-native-ttf --with-jpeg-dir --with-png-dir --with-t1lib
--with-freetype-dir --with-gettext --enable-mbstring --with-mcrypt --with-mhash
--with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd
--enable-mysqlnd --with-openssl --with-pcre-regex --with-pspell --enable-shmop
--enable-soap --enable-sockets --enable-sysvmsg --enable-wddx --with-xsl
--enable-zip --with-zlib --with-tcadb --with-openssl-dir --with-gd
###
bin/php -v
PHP 5.4.5 (cli) (built: Aug 8 2012 01:03:00)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
###
root@Ubuntu-1204-precise-64-minimal ~ # strace -fveall -p 2590 -p 2589
Process 2590 attached - interrupt to quit
Process 2589 attached - interrupt to quit
[pid 2589] wait4(-1, unfinished ...
[pid 2590] futex(0x7fc2a4d73720, FUTEX_WAIT_PRIVATE, 2, NULL
###
[2012-08-27 19:50:31] jonas at brachium-system dot net
Description:
PHP 5.3.14 with FPM on Debian Squeze works without any problems.
The PHP Version 5.3.15 / 5.3.16 and current Git branch PHP 5.3 is affected.
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
All pools are started and working, but the php5-fpm does not detach:
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
and here it hangs. ctrl +c does not work.
strace tells me:
Process 15949 attached - interrupt to quit
futex(0x7fb923e8ce40, FUTEX_WAIT_PRIVATE, 2, NULL
If I switch the configuration option daemonize to no php-fpm starts up
normal and can be aborted with ctrl+c.
If I copy sapi/fpm from 5.3.14 to the current php-src from git and compile it
again my configuration and php-fpm works and starts normal.
If I remove the USR1/USR2 handling from sapi/fpm/fpm/fpm_unix.c ( see patch )
php-fpm starts normal and detach correctly.
I think (See:
http://groups.google.com/group/highload-php-en/browse_thread/thread/fa6b16d533411f42)
PHP 5.4 branch is also affected.
PHP-FPM Configration:
-
[global]
pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
daemonize = yes
[cust-websrv]
listen = /tmp/cust-webserv.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 130
pm.start_servers = 15
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500
chdir = /
env[APPLICATION_ENV] = prod
[is-tracking]
listen = /tmp/is-tracking.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 130
pm.start_servers = 15
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 5000
chdir = /
env[APPLICATION_ENV] = prod
[limesurvey]
listen = /tmp/limesurvey.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 40
pm.start_servers = 5
pm.min_spare_servers = 4
pm.max_spare_servers = 5
pm.max_requests = 500
chdir = /
env[APPLICATION_ENV] = prod
Actual result:
--
strace, with the problem:
open(/var/log/php5-fpm.log, O_WRONLY|O_CREAT|O_APPEND, 0600) = 3
fcntl(3, F_GETFD) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
stat(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
geteuid()
rt_sigaction(SIGUSR1, {0x858300, ~[RTMIN RT_1], SA_RESTORER, 0x7fb98d4b5230},
{0x84ad50, [], SA_RESTORER, 0x7fb98d4b5230}, 8) = 0
rt_sigaction(SIGUSR2, {0x8582f0, ~[RTMIN RT_1], SA_RESTORER, 0x7fb98d4b5230},
{SIG_DFL, [], 0}, 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fb990b0da10) = 4037
--- SIGUSR1 (User defined signal 1) @ 0 (0) ---
futex(0x7fb98d7e0e40, FUTEX_WAIT_PRIVATE, 2, NULL
Bug #62954 [Opn-Asn]: startup problems fpm / php-fpm
Edit report at https://bugs.php.net/bug.php?id=62954edit=1
ID: 62954
Updated by: tony2...@php.net
Reported by:jonas at brachium-system dot net
Summary:startup problems fpm / php-fpm
-Status: Open
+Status: Assigned
Type: Bug
Package:FPM related
Operating System: Linux
PHP Version:5.3Git-2012-08-27 (Git)
-Assigned To:
+Assigned To:fat
Block user comment: N
Private report: N
Previous Comments:
[2012-08-27 19:50:31] jonas at brachium-system dot net
Description:
PHP 5.3.14 with FPM on Debian Squeze works without any problems.
The PHP Version 5.3.15 / 5.3.16 and current Git branch PHP 5.3 is affected.
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
All pools are started and working, but the php5-fpm does not detach:
/usr/sbin/php5-fpm --fpm-config /etc/php5/fpm/php-fpm.conf
and here it hangs. ctrl +c does not work.
strace tells me:
Process 15949 attached - interrupt to quit
futex(0x7fb923e8ce40, FUTEX_WAIT_PRIVATE, 2, NULL
If I switch the configuration option daemonize to no php-fpm starts up
normal and can be aborted with ctrl+c.
If I copy sapi/fpm from 5.3.14 to the current php-src from git and compile it
again my configuration and php-fpm works and starts normal.
If I remove the USR1/USR2 handling from sapi/fpm/fpm/fpm_unix.c ( see patch )
php-fpm starts normal and detach correctly.
I think (See:
http://groups.google.com/group/highload-php-en/browse_thread/thread/fa6b16d533411f42)
PHP 5.4 branch is also affected.
PHP-FPM Configration:
-
[global]
pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
daemonize = yes
[cust-websrv]
listen = /tmp/cust-webserv.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 130
pm.start_servers = 15
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500
chdir = /
env[APPLICATION_ENV] = prod
[is-tracking]
listen = /tmp/is-tracking.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 130
pm.start_servers = 15
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 5000
chdir = /
env[APPLICATION_ENV] = prod
[limesurvey]
listen = /tmp/limesurvey.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 40
pm.start_servers = 5
pm.min_spare_servers = 4
pm.max_spare_servers = 5
pm.max_requests = 500
chdir = /
env[APPLICATION_ENV] = prod
Actual result:
--
strace, with the problem:
open(/var/log/php5-fpm.log, O_WRONLY|O_CREAT|O_APPEND, 0600) = 3
fcntl(3, F_GETFD) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
stat(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat(/, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
geteuid()
rt_sigaction(SIGUSR1, {0x858300, ~[RTMIN RT_1], SA_RESTORER, 0x7fb98d4b5230},
{0x84ad50, [], SA_RESTORER, 0x7fb98d4b5230}, 8) = 0
rt_sigaction(SIGUSR2, {0x8582f0, ~[RTMIN RT_1], SA_RESTORER, 0x7fb98d4b5230},
{SIG_DFL, [], 0}, 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7fb990b0da10) = 4037
--- SIGUSR1 (User defined signal 1) @ 0 (0) ---
futex(0x7fb98d7e0e40, FUTEX_WAIT_PRIVATE, 2, NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=62954edit=1
Bug #62838 [Opn-Asn]: enchant_dict_quick_check() destroys zval, but fails to initialized it
Edit report at https://bugs.php.net/bug.php?id=62838edit=1 ID: 62838 Updated by: tony2...@php.net Reported by:tony2...@php.net Summary:enchant_dict_quick_check() destroys zval, but fails to initialized it -Status: Open +Status: Assigned Type: Bug Package:Enchant related PHP Version:5.4Git-2012-08-16 (Git) -Assigned To: +Assigned To:tony2001 Block user comment: N Private report: N Previous Comments: [2012-08-16 10:28:36] tony2...@php.net Description: enchant_dict_quick_check() destroys zval, but doesn't initialize it when passing invalid enchant resource. Initially reported by Mateusz Goik. Test script: --- ? $a = array(); enchant_dict_quick_check(STDIN, 0, $a); array_splice($a,0, 0,0); ? Actual result: -- /local/qa/5_4_ZTS/Zend/zend_hash.c(1055) : ht=0x7f6745191038 is inconsistent -- Edit this bug report at https://bugs.php.net/bug.php?id=62838edit=1
Bug #62838 [Asn-Csd]: enchant_dict_quick_check() destroys zval, but fails to initialized it
Edit report at https://bugs.php.net/bug.php?id=62838edit=1 ID: 62838 Updated by: tony2...@php.net Reported by:tony2...@php.net Summary:enchant_dict_quick_check() destroys zval, but fails to initialized it -Status: Assigned +Status: Closed Type: Bug Package:Enchant related PHP Version:5.4Git-2012-08-16 (Git) Assigned To:tony2001 Block user comment: N Private report: N 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-08-16 10:41:21] tony2...@php.net Automatic comment on behalf of tony2001 Revision: http://git.php.net/?p=php-src.git;a=commit;h=8649e4236b12ce9b90356a5804be96bd1f67bcd6 Log: Fixed bug #62838 [2012-08-16 10:40:59] tony2...@php.net Automatic comment on behalf of tony2001 Revision: http://git.php.net/?p=php-src.git;a=commit;h=8649e4236b12ce9b90356a5804be96bd1f67bcd6 Log: Fixed bug #62838 [2012-08-16 10:40:34] tony2...@php.net Automatic comment on behalf of tony2001 Revision: http://git.php.net/?p=php-src.git;a=commit;h=8649e4236b12ce9b90356a5804be96bd1f67bcd6 Log: Fixed bug #62838 [2012-08-16 10:28:36] tony2...@php.net Description: enchant_dict_quick_check() destroys zval, but doesn't initialize it when passing invalid enchant resource. Initially reported by Mateusz Goik. Test script: --- ? $a = array(); enchant_dict_quick_check(STDIN, 0, $a); array_splice($a,0, 0,0); ? Actual result: -- /local/qa/5_4_ZTS/Zend/zend_hash.c(1055) : ht=0x7f6745191038 is inconsistent -- Edit this bug report at https://bugs.php.net/bug.php?id=62838edit=1
Bug #62495 [Opn-Nab]: Pinba extension compile errors
Edit report at https://bugs.php.net/bug.php?id=62495edit=1 ID: 62495 Updated by: tony2...@php.net Reported by:maksim at woyager dot ru Summary:Pinba extension compile errors -Status: Open +Status: Not a bug Type: Bug Package:Compile Failure Operating System: Linux Debian PHP Version:5.4.4 Block user comment: N Private report: N New Comment: Pinba was never an officially supported extension, so use other channels to report bugs. Previous Comments: [2012-07-06 13:39:54] maksim at woyager dot ru Description: PHP Version 5.4.4 Linux localhost 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 Configure Command './configure' '--disable-all' '--enable-xmlwriter' '--enable-libxml' '--enable-simplexml' '--enable-xml' '--enable-xmlreader' '--enable-json' '--enable-session' '--enable-zip' '--with-curl' '--enable-ftp' '--with-openssl' '--with-iconv' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-freetype-dir' '--with-zlib' '--enable-mbstring' '--enable-sockets' '--enable-ctype' '--enable-hash' '--enable-dom' '--enable-pcntl' '--with-ldap' '--enable-fpm' '--with-mssql' '--enable-soap' '--with-mysql' Trouble with compiling pinba.org's pinba php extension. localhost:/home/woyager/pinba_extension-201112281455# make /bin/bash /home/woyager/pinba_extension-201112281455/libtool --mode=compile g++ -DNDEBUG -I. -I/home/woyager/pinba_extension-201112281455 -DPHP_ATOM_INC -I/home/woyager/pinba_extension-201112281455/include -I/home/woyager/pinba_extension-201112281455/main -I/home/woyager/pinba_extension-201112281455 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c /home/woyager/pinba_extension-201112281455/pinba.cc -o pinba.lo mkdir .libs g++ -DNDEBUG -I. -I/home/woyager/pinba_extension-201112281455 -DPHP_ATOM_INC -I/home/woyager/pinba_extension-201112281455/include -I/home/woyager/pinba_extension-201112281455/main -I/home/woyager/pinba_extension-201112281455 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c /home/woyager/pinba_extension-201112281455/pinba.cc -fPIC -DPIC -o .libs/pinba.o /home/woyager/pinba_extension-201112281455/pinba.cc: In function âint php_pinba_key_compare(const void*, const void*)â: /home/woyager/pinba_extension-201112281455/pinba.cc:585: error: invalid conversion from âconst char*â to âchar*â /home/woyager/pinba_extension-201112281455/pinba.cc:594: error: invalid conversion from âconst char*â to âchar*â /home/woyager/pinba_extension-201112281455/pinba.cc: In function âvoid zif_pinba_get_info(int, zval*, zval**, zval*, int)â: /home/woyager/pinba_extension-201112281455/pinba.cc:1146: warning: deprecated conversion from string constant to âchar*â /home/woyager/pinba_extension-201112281455/pinba.cc:1152: warning: deprecated conversion from string constant to âchar*â /home/woyager/pinba_extension-201112281455/pinba.cc: At global scope: /home/woyager/pinba_extension-201112281455/pinba.cc:1262: error: âfunction_entryâ does not name a type /home/woyager/pinba_extension-201112281455/pinba.cc:1367: warning: deprecated conversion from string constant to âchar*â /home/woyager/pinba_extension-201112281455/pinba.cc:1367: warning: deprecated conversion from string constant to âchar*â /home/woyager/pinba_extension-201112281455/pinba.cc:1367: warning: deprecated conversion from string constant to âchar*â /home/woyager/pinba_extension-201112281455/pinba.cc: In function âint zm_activate_pinba(int, int)â: /home/woyager/pinba_extension-201112281455/pinba.cc:1461: error: âoutput_globalsâ was not declared in this scope /home/woyager/pinba_extension-201112281455/pinba.cc: In function âint zm_deactivate_pinba(int, int)â: /home/woyager/pinba_extension-201112281455/pinba.cc:1475: error: âoutput_globalsâ was not declared in this scope /home/woyager/pinba_extension-201112281455/pinba.cc: At global scope: /home/woyager/pinba_extension-201112281455/pinba.cc:1512: error: âpinba_functionsâ was not declared in this scope /home/woyager/pinba_extension-201112281455/pinba.cc:1522: error: too many initializers for âzend_module_entryâ make: *** [pinba.lo] ÐÑибка 1 Configure out localhost:/home/woyager/pinba_extension-201112281455# ./configure --with-pinba=/usr --with-php-config=/usr/local/bin/php-config checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for a sed that does not truncate output... /bin/sed
Bug #48724 [Opn-Asn]: getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR
Edit report at https://bugs.php.net/bug.php?id=48724edit=1 ID: 48724 Updated by: tony2...@php.net Reported by:an0nym at narod dot ru Summary:getColumnMeta() doesn't return native_type for BIT, TINYINT and YEAR -Status: Open +Status: Assigned Type: Bug Package:PDO related Operating System: * PHP Version:5.3.0 Block user comment: N Private report: N New Comment: Ulf, could you pls check if the attached patch is correct? Thanks. Previous Comments: [2012-04-13 12:06:15] tony2...@php.net The following patch has been added/updated: Patch Name: fix-bug-48724.patch Revision: 1334318775 URL: https://bugs.php.net/patch-display.php?bug=48724patch=fix-bug-48724.patchrevision=1334318775 [2009-07-03 16:57:28] u...@php.net You are free to patch it. Bye. [2009-07-03 16:30:12] an0nym at narod dot ru Poor MySQLi developers... they've managed to solve this problem without specification. Poor you... you've spent sooo many time for nothing developing this function, which works in 35 of 38 cases - this stuff has no specification! Wait for a specification - you have a good excuse! Bye. [2009-07-03 16:17:20] u...@php.net You are free to write a patch. I refuse to work on stuff that has no specification and which may go into any direction. That typically ends up in a backwards compatibility nightmare, which in particular for an abstraction like PDO makes no sense to me. The patch may be rather simple. But watch out for different values returned by different MySQL versions. [2009-07-03 15:39:20] an0nym at narod dot ru libmysql and mysqlnd behave the same way. If this is decided to be considered as a bug it is not a mysqlnd bug. I agree. This is not a libmysql or mysqlnd bug. This is a PDO (or PDO_MySQL) bug. 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 https://bugs.php.net/bug.php?id=48724 -- Edit this bug report at https://bugs.php.net/bug.php?id=48724edit=1
Bug #61362 [Opn-Asn]: Exception::getTraceAsString, Exception::__toString not able to handle unicode
Edit report at https://bugs.php.net/bug.php?id=61362edit=1
ID: 61362
Updated by: tony2...@php.net
Reported by:sam at rmcreative dot ru
Summary:Exception::getTraceAsString, Exception::__toString
not able to handle unicode
-Status: Open
+Status: Assigned
Type: Bug
Package:Unicode Engine related
Operating System: All
PHP Version:5.4.0
-Assigned To:
+Assigned To:johannes
Block user comment: N
Private report: N
Previous Comments:
[2012-03-14 17:20:50] tony2...@php.net
The problem is here:
http://lxr.php.net/opengrok/xref/PHP_5_4/Zend/zend_exceptions.c#391
Dunno what to do in this case: either add to the docs that the result of
getTraceAsString() is perfectly safe from binary symbols or drop that code
completely and allow any chars there.
[2012-03-14 15:16:42] sam at rmcreative dot ru
It's UTF8 already.
[2012-03-14 15:14:58] tony2...@php.net
Nevermind, I see the problem.
[2012-03-14 12:20:41] tony2...@php.net
What if you try to switch your browser encoding to UTF8 from whatever it is by
default?
[2012-03-12 15:44:18] sam at rmcreative dot ru
Description:
Exception::getTraceAsString, Exception::__toString are not able to properly
handle unicode in stack trace. Instead of showing actual argument values it's
giving in case value is unicode.
Tested on PHP 5.3 and PHP 5.4.
Test script:
---
?php
function test($arg){
throw new Exception();
}
try {
test('ÑеÑÑ');
}
catch(Exception $e) {
echo $e-getTraceAsString();
echo (string)$e;
}
Expected result:
d:\web\usr\local\php54php.exe d:\src\exception_wrong_trace\test.php
#0 D:\src\exception_wrong_trace\test.php(7): test('ÑеÑÑ')
#1 {main}exception 'Exception' in D:\src\exception_wrong_trace\test.php:3
Stack trace:
#0 D:\src\exception_wrong_trace\test.php(7): test('ÑеÑÑ')
#1 {main}
Actual result:
--
d:\web\usr\local\php54php.exe d:\src\exception_wrong_trace\test.php
#0 D:\src\exception_wrong_trace\test.php(7): test('')
#1 {main}exception 'Exception' in D:\src\exception_wrong_trace\test.php:3
Stack trace:
#0 D:\src\exception_wrong_trace\test.php(7): test('')
#1 {main}
--
Edit this bug report at https://bugs.php.net/bug.php?id=61362edit=1
Bug #61362 [Opn-Fbk]: Exception::getTraceAsString, Exception::__toString not able to handle unicode
Edit report at https://bugs.php.net/bug.php?id=61362edit=1
ID: 61362
Updated by: tony2...@php.net
Reported by:sam at rmcreative dot ru
Summary:Exception::getTraceAsString, Exception::__toString
not able to handle unicode
-Status: Open
+Status: Feedback
Type: Bug
Package:Unicode Engine related
Operating System: All
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
What if you try to switch your browser encoding to UTF8 from whatever it is by
default?
Previous Comments:
[2012-03-12 15:44:18] sam at rmcreative dot ru
Description:
Exception::getTraceAsString, Exception::__toString are not able to properly
handle unicode in stack trace. Instead of showing actual argument values it's
giving in case value is unicode.
Tested on PHP 5.3 and PHP 5.4.
Test script:
---
?php
function test($arg){
throw new Exception();
}
try {
test('ÑеÑÑ');
}
catch(Exception $e) {
echo $e-getTraceAsString();
echo (string)$e;
}
Expected result:
d:\web\usr\local\php54php.exe d:\src\exception_wrong_trace\test.php
#0 D:\src\exception_wrong_trace\test.php(7): test('ÑеÑÑ')
#1 {main}exception 'Exception' in D:\src\exception_wrong_trace\test.php:3
Stack trace:
#0 D:\src\exception_wrong_trace\test.php(7): test('ÑеÑÑ')
#1 {main}
Actual result:
--
d:\web\usr\local\php54php.exe d:\src\exception_wrong_trace\test.php
#0 D:\src\exception_wrong_trace\test.php(7): test('')
#1 {main}exception 'Exception' in D:\src\exception_wrong_trace\test.php:3
Stack trace:
#0 D:\src\exception_wrong_trace\test.php(7): test('')
#1 {main}
--
Edit this bug report at https://bugs.php.net/bug.php?id=61362edit=1
Bug #61362 [Fbk-Opn]: Exception::getTraceAsString, Exception::__toString not able to handle unicode
Edit report at https://bugs.php.net/bug.php?id=61362edit=1
ID: 61362
Updated by: tony2...@php.net
Reported by:sam at rmcreative dot ru
Summary:Exception::getTraceAsString, Exception::__toString
not able to handle unicode
-Status: Feedback
+Status: Open
Type: Bug
Package:Unicode Engine related
Operating System: All
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Nevermind, I see the problem.
Previous Comments:
[2012-03-14 12:20:41] tony2...@php.net
What if you try to switch your browser encoding to UTF8 from whatever it is by
default?
[2012-03-12 15:44:18] sam at rmcreative dot ru
Description:
Exception::getTraceAsString, Exception::__toString are not able to properly
handle unicode in stack trace. Instead of showing actual argument values it's
giving in case value is unicode.
Tested on PHP 5.3 and PHP 5.4.
Test script:
---
?php
function test($arg){
throw new Exception();
}
try {
test('ÑеÑÑ');
}
catch(Exception $e) {
echo $e-getTraceAsString();
echo (string)$e;
}
Expected result:
d:\web\usr\local\php54php.exe d:\src\exception_wrong_trace\test.php
#0 D:\src\exception_wrong_trace\test.php(7): test('ÑеÑÑ')
#1 {main}exception 'Exception' in D:\src\exception_wrong_trace\test.php:3
Stack trace:
#0 D:\src\exception_wrong_trace\test.php(7): test('ÑеÑÑ')
#1 {main}
Actual result:
--
d:\web\usr\local\php54php.exe d:\src\exception_wrong_trace\test.php
#0 D:\src\exception_wrong_trace\test.php(7): test('')
#1 {main}exception 'Exception' in D:\src\exception_wrong_trace\test.php:3
Stack trace:
#0 D:\src\exception_wrong_trace\test.php(7): test('')
#1 {main}
--
Edit this bug report at https://bugs.php.net/bug.php?id=61362edit=1
Bug #61362 [Opn]: Exception::getTraceAsString, Exception::__toString not able to handle unicode
Edit report at https://bugs.php.net/bug.php?id=61362edit=1
ID: 61362
Updated by: tony2...@php.net
Reported by:sam at rmcreative dot ru
Summary:Exception::getTraceAsString, Exception::__toString
not able to handle unicode
Status: Open
Type: Bug
Package:Unicode Engine related
Operating System: All
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
The problem is here:
http://lxr.php.net/opengrok/xref/PHP_5_4/Zend/zend_exceptions.c#391
Dunno what to do in this case: either add to the docs that the result of
getTraceAsString() is perfectly safe from binary symbols or drop that code
completely and allow any chars there.
Previous Comments:
[2012-03-14 15:16:42] sam at rmcreative dot ru
It's UTF8 already.
[2012-03-14 15:14:58] tony2...@php.net
Nevermind, I see the problem.
[2012-03-14 12:20:41] tony2...@php.net
What if you try to switch your browser encoding to UTF8 from whatever it is by
default?
[2012-03-12 15:44:18] sam at rmcreative dot ru
Description:
Exception::getTraceAsString, Exception::__toString are not able to properly
handle unicode in stack trace. Instead of showing actual argument values it's
giving in case value is unicode.
Tested on PHP 5.3 and PHP 5.4.
Test script:
---
?php
function test($arg){
throw new Exception();
}
try {
test('ÑеÑÑ');
}
catch(Exception $e) {
echo $e-getTraceAsString();
echo (string)$e;
}
Expected result:
d:\web\usr\local\php54php.exe d:\src\exception_wrong_trace\test.php
#0 D:\src\exception_wrong_trace\test.php(7): test('ÑеÑÑ')
#1 {main}exception 'Exception' in D:\src\exception_wrong_trace\test.php:3
Stack trace:
#0 D:\src\exception_wrong_trace\test.php(7): test('ÑеÑÑ')
#1 {main}
Actual result:
--
d:\web\usr\local\php54php.exe d:\src\exception_wrong_trace\test.php
#0 D:\src\exception_wrong_trace\test.php(7): test('')
#1 {main}exception 'Exception' in D:\src\exception_wrong_trace\test.php:3
Stack trace:
#0 D:\src\exception_wrong_trace\test.php(7): test('')
#1 {main}
--
Edit this bug report at https://bugs.php.net/bug.php?id=61362edit=1
Bug #61045 [Opn-Asn]: fpm don't send error log to fastcgi clients(nginx)
Edit report at https://bugs.php.net/bug.php?id=61045edit=1 ID: 61045 Updated by: tony2...@php.net Reported by:lxlight at gmail dot com Summary:fpm don't send error log to fastcgi clients(nginx) -Status: Open +Status: Assigned Type: Bug Package:FPM related Operating System: Linux PHP Version:5.3.10 -Assigned To: +Assigned To:fat Block user comment: N Private report: N Previous Comments: [2012-03-04 18:19:04] ewgraf at gmail dot com Add patch for 5.3.10. It simple, not so right, because I think this functionality need move to zlog_ex, but it works for me. If anybody can review it and test, would be nice. [2012-02-13 19:43:05] me at nicholassavilerobinson dot com I confirm this deficiency: php5-fpm 5.3.9+ prevents fpm passing error_log output to the web server's error log via SAPI. I encounter this issue using nginx 1.0.11, but it is also present with older nginx releases. The problem is encountered even with 777 permissions on the logs. If I roll back to php5-fpm_5.3.8 (keeping the same configs), it starts working again. I would like fpm STDERR to output to the virtual host's error log (this was the default behavior before). A sample php.ini/php-fpm.conf is attached: /etc/php5/fpm/php.ini [PHP] engine = On short_open_tag = Off asp_tags = Off precision = 14 y2k_compliance = On output_buffering = 4096 zlib.output_compression = Off implicit_flush = Off unserialize_callback_func = serialize_precision = 17 allow_call_time_pass_reference = Off safe_mode = Off safe_mode_gid = Off safe_mode_include_dir = safe_mode_exec_dir = safe_mode_allowed_env_vars = PHP_ safe_mode_protected_env_vars = LD_LIBRARY_PATH disable_functions = disable_classes = expose_php = On max_execution_time = 30 max_input_time = 60 memory_limit = 128M error_reporting = E_ALL ~E_DEPRECATED display_errors = Off display_startup_errors = Off log_errors = On log_errors_max_len = 1024 ignore_repeated_errors = Off ignore_repeated_source = Off report_memleaks = On track_errors = Off html_errors = Off variables_order = GPCS request_order = GP register_globals = Off register_long_arrays = Off register_argc_argv = Off auto_globals_jit = On post_max_size = 8M magic_quotes_gpc = Off magic_quotes_runtime = Off magic_quotes_sybase = Off auto_prepend_file = auto_append_file = default_mimetype = text/html doc_root = user_dir = enable_dl = Off file_uploads = On upload_max_filesize = 2M max_file_uploads = 20 allow_url_fopen = On allow_url_include = Off default_socket_timeout = 60 /etc/php5/fpm/php-fpm.conf: [global] pid = /var/run/php5-fpm.pid error_log = /var/log/php5-fpm.log [www] listen = /tmp/fcgi.socket user = www-data group = www-data pm = dynamic pm.max_children = 50 pm.start_servers = 25 pm.min_spare_servers = 5 pm.max_spare_servers = 35 pm.max_requests = 500 pm.status_path = /status ping.path = /ping ping.response = Ok slowlog = log/$pool.log.slow chdir = / [2012-02-10 14:27:29] lxlight at gmail dot com Description: Since php 5.3.9 released with any variation of config parameters php-fpm don't send php script errors/warnings to nginx. Reading logs on one frontend which contains get request, referrer, backend host is very simply. Pleas add the ability to send stderr to frontend when error_log is undefined. -- Edit this bug report at https://bugs.php.net/bug.php?id=61045edit=1
Bug #61124 [Opn-Asn]: Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61124edit=1
ID: 61124
Updated by: tony2...@php.net
Reported by:mangirdas at impresspages dot org
Summary:Segmentation fault
-Status: Open
+Status: Assigned
Type: Bug
Package:OpenSSL related
Operating System: CentOS release 5.7 (Final)
PHP Version:5.3.10
-Assigned To:
+Assigned To:pajoye
Block user comment: N
Private report: N
Previous Comments:
[2012-02-18 04:39:27] me at ktamura dot com
I think I know why. Basically, when the input data is malformed but $raw_input
is set to false, we get a null pointer. Here is a suggested patch (Also
available at https://gist.github.com/1857431)
Index: ext/openssl/openssl.c
===
--- ext/openssl/openssl.c (revision 323312)
+++ ext/openssl/openssl.c (working copy)
@@ -4801,6 +4801,11 @@
base64_str = (char*)php_base64_decode((unsigned char*)data, data_len,
base64_str_len);
data_len = base64_str_len;
data = base64_str;
+
+if (data == NULL) {
+php_error_docref(NULL TSRMLS_CC, E_WARNING, Failed to decode the
base64 input);
+RETURN_FALSE;
+}
}
keylen = EVP_CIPHER_key_length(cipher_type);
[2012-02-18 01:02:48] me at ktamura dot com
I feel that the real issue is that there is no input check on the first
argument of
openssl_decrypt. Looking at http://linux.die.net/man/3/evp_decryptupdate it is
unclear what the expected behavior is if you feed invalid input into
EVP_DecryptUpdate. Perhaps we can do input validation?
[2012-02-18 00:53:01] me at ktamura dot com
FYI...the said hacky patch of adding 16 as opposed to 1 bytes do not solve
the
problem for PHP 5.3.8 built with --enable-debug and --with-openssl
--without-iconv
options on snow leopard.
[2012-02-17 17:35:53] ras...@php.net
Confirmed
It would help to mention that this gives this warning:
Warning: openssl_decrypt(): IV passed is only 4 bytes long, cipher expects an
IV
of precisely 16 bytes, padding with \0
which is probably the cause here. The buffer we pass in is not large enough to
fit the IV.
A quick hack which fixes the segfault:
--- ext/openssl/openssl.c (revision 323261)
+++ ext/openssl/openssl.c (working copy)
@@ -4819,7 +4819,7 @@
free_iv = php_openssl_validate_iv(iv, iv_len,
EVP_CIPHER_iv_length(cipher_type) TSRMLS_CC);
outlen = data_len + EVP_CIPHER_block_size(cipher_type);
- outbuf = emalloc(outlen + 1);
+ outbuf = emalloc(outlen + 16);
EVP_DecryptInit(cipher_ctx, cipher_type, NULL, NULL);
if (password_len keylen) {
but it obviously isn't the right solution.
[2012-02-17 17:11:09] mangirdas at impresspages dot org
Description:
This function throws a segmentation fault:
openssl_decrypt ('kzo w2RMExUTYQXW2Xzxmg==', 'aes-128-cbc', 'pass', $rawOutput,
'pass');
Test script:
---
?php
openssl_decrypt ('kzo w2RMExUTYQXW2Xzxmg==', 'aes-128-cbc', 'pass', $rawOutput,
'pass');
Expected result:
FALSE, because encrypted string is incorrect.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61124edit=1
Bug #50489 [Opn-Asn]: SoapClient + HTTPs + Proxy = SSL errors
Edit report at https://bugs.php.net/bug.php?id=50489edit=1 ID: 50489 Updated by: tony2...@php.net Reported by:zamolxero at gmail dot com Summary:SoapClient + HTTPs + Proxy = SSL errors -Status: Open +Status: Assigned Type: Bug Package:Streams related Operating System: Linux, Windows PHP Version:5.2.11 -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N Previous Comments: [2010-11-22 11:51:59] bruno dot premont at restena dot lu This bug also applies to php-5.3.3 for which my patch php-5.3.3_fopen_https_proxy_auth_fix does the trick. [2010-08-13 11:01:40] bruno dot premont at restena dot lu It looks like php_stream_url_wrap_http_ex() from ext/standard/http_fopen_wrapper.c should pick the proxy-authentication header and send it with CONNECT method for proxy authentication to work with SOAP WSDL fetching (and at same time probably fixing quite a few other bugs) [2010-04-25 17:56:23] hello at gmail dot com The proxy's creditentials set through SoapClient options are ignored when the underlying target is HTTPS, and then the proxy reply with a 407 error code. [2009-12-16 10:21:07] zamolxero at gmail dot com Description: Apache 2.x PHP 5.2.11 './configure' '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu' '--mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info' '--sysconfdir=/etc' '--cache-file=./config.cache' '--with-pcre-regex=/usr' '--disable-cli' '--with-apxs2=/usr/sbin/apxs2' '--with-config-file-path=/etc/php/apache2-php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active' '--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar' '--with-curl' '--without-curlwrappers' '--disable-dbase' '--enable-exif' '--without-fbsql' '--without-fdftk' '--disable-filter' '--enable-ftp' '--with-gettext' '--without-gmp' '--disable-ipv6' '--without-kerberos' '--enable-mbstring' '--with-mcrypt' '--with-mhash' '--without-msql' '--without-mssql' '--with-ncurses' '--with-openssl' '--with-openssl-dir=/usr' '--enable-pcntl' '--without-pgsql' '--without-pspell' '--without-recode' '--disable-shmop' '--without-snmp' '--enable-soap' '--enable-sockets' '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--without-tidy' '--disable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--with-xmlrpc' '--without-xsl' '--enable-zip' '--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--without-xpm-dir' '--with-gd' '--with-imap' '--with-imap-ssl' '--with-ldap' '--without-ldap-sasl' '--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=/usr/bin/mysql_config' '--without-pdo-dblib' '--with-pdo-mysql=/usr' '--without-pdo-odbc' '--without-pdo-pgsql' '--without-pdo-sqlite' '--with-readline' '--without-libedit' '--without-mm' '--without-sqlite' Reproduce code: --- $SoapClient = new SoapClient( $soap_url_.'?wsdl', array( 'location' = $soap_url_, 'cache_wsdl'= WSDL_CACHE_NONE, 'user_agent'= __FUNCTION__, 'trace' = 1, 'exceptions'= 1, 'allow_self_signed' = 1, 'proxy_host'= $proxy_host, 'proxy_login' = $proxy_user, 'proxy_password'= $proxy_pass, 'proxy_port'= (int)$proxy_port ) ); Expected result: I expect everything to go smooth and fetch the WSDL file contents. I tested the proxy manually on the https wsdl resource and it works. Actual result: -- Warning: SoapClient::SoapClient() [soapclient.soapclient]: SSL operation failed with code 1. OpenSSL Error messages: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol in /var/www/vhosts/site/connect-soap.php on line 138 Warning:
Bug #60634 [Ver-Asn]: Segmentation fault when trying to die() in SessionHandler::write()
Edit report at https://bugs.php.net/bug.php?id=60634edit=1
ID: 60634
Updated by: tony2...@php.net
Reported by:bobwei9 at hotmail dot com
Summary:Segmentation fault when trying to die() in
SessionHandler::write()
-Status: Verified
+Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X 10.7
PHP Version:trunk-SVN-2012-01-01 (SVN)
-Assigned To:
+Assigned To:iliaa
Block user comment: N
Private report: N
Previous Comments:
[2012-01-04 11:43:38] ar...@php.net
Automatic comment from SVN on behalf of arpad
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=321758
Log: add more tests for #60634 (stems from #21306) and xfail them all for the
moment
[2012-01-03 21:47:26] ar...@php.net
This is present in 5.3 too using the old style session_set_save_handler().
Seems to be related to the zend_try in php_session_flush().
[2012-01-03 21:46:51] ar...@php.net
Automatic comment from SVN on behalf of arpad
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=321733
Log: add test for #60634
[2012-01-01 19:32:18] bobwei9 at hotmail dot com
Description:
The apache or the CLI reports an segmentation fault while trying to die() or to
exit() a script in the write method of a class which extends the SessionHandler
class.
Test script:
---
?php
class session_handler extends SessionHandler
{
function close () {return true;}
function destroy ($a) {return true;}
function open ($a,$b) {return true;}
function gc ($a) {return true;}
function read ($a) {return ;}
function write ($a,$b) {die();}
}
session_set_save_handler(new session_handler);
session_start();
session_write_close(); # apache segfaults
print never appears?;
Actual result:
--
Apache/cli segfaults
Backtrace:
#0 0x00010261de30 in zval_delref_p [inlined] () at
/Users/.../php-src-trunk-20120101/Zend/zend.h:82
#1 0x00010261de30 in i_zval_ptr_dtor [inlined] () at
/Users/.../php-src-trunk-20120101/Zend/zend_execute.h:82
#2 0x00010261de30 in zend_vm_stack_clear_multiple [inlined] () at
/Users/.../php-src-trunk-20120101/Zend/zend_execute.h:339
#3 0x00010261de30 in zend_do_fcall_common_helper_SPEC
(execute_data=0x109a170d8) at zend_execute.c:736
#4 0x00010262720e in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x109a170d8) at zend_vm_execute.h:2215
#5 0x00010261aec2 in execute (op_array=0x109a51d98) at
zend_vm_execute.h:410
#6 0x0001025c731b in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at zend.c:1272
#7 0x000102509153 in php_execute_script (primary_file=0x7fff6198ab60) at
main.c:2476
#8 0x00010279d153 in do_cli (argc=2, argv=0x7fff6198ae18) at php_cli.c:983
#9 0x00010279ee95 in main (argc=2, argv=0x7fff6198ae18) at php_cli.c:1356
--
Edit this bug report at https://bugs.php.net/bug.php?id=60634edit=1
Bug #53437 [Asn]: Crash when using unserialized DatePeriod instance
Edit report at https://bugs.php.net/bug.php?id=53437edit=1
ID: 53437
Updated by: tony2...@php.net
Reported by:from dot php dot net at brainbox dot cz
Summary:Crash when using unserialized DatePeriod instance
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Windows XP SP3
PHP Version:5.3.3
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
@Cataphrac (the Date(Period|Interval) serialization patch is here btw:
http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff )
Previous Comments:
[2011-12-06 06:07:24] der...@php.net
Automatic comment from SVN on behalf of derick
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=320479
Log: - Added a test case for #53437.
[2011-01-09 06:00:35] cataphr...@php.net
Reassigning to Derick, as the patch I've written is under his consideration.
[2010-12-01 21:50:03] fel...@php.net
Duplicated of #52113
[2010-12-01 17:15:05] from dot php dot net at brainbox dot cz
Description:
DatePeriod class does not have the serialization/unserialization logic
implemented. Therefore, when unserialized instance is used, script crashes.
This is result of serializing the DatePeriod instance:
O:10:DatePeriod:0:{}
unserialize() wents fine as well, but when I call foreach() on unserialized
instance, the script crashes.
Test script:
---
$dp = new DatePeriod(new DateTime('2010-01-01 UTC'), new DateInterval('P1D'),
2);
echo Original:\r\n;
foreach($dp as $dt) {
echo $dt-format('Y-m-d H:i:s').\r\n;
}
echo \r\n;
$ser = serialize($dp); // $ser is: O:10:DatePeriod:0:{}
// Create dangerous instance
$dpu = unserialize($ser); // $dpu has invalid valuesâ¦
echo Unserialized:\r\n;
// â¦which leads to CRASH:
foreach($dpu as $dt) {
echo $dt-format('Y-m-d H:i:s').\r\n;
}
Expected result:
Original:
2010-01-01 00:00:00
2010-01-02 00:00:00
2010-01-03 00:00:00
Unserialized:
2010-01-01 00:00:00
2010-01-02 00:00:00
2010-01-03 00:00:00
Actual result:
--
PHP crashes on the unserialize line.
--
Edit this bug report at https://bugs.php.net/bug.php?id=53437edit=1
Bug #60536 [Csd-ReO]: Traits Segfault
Edit report at https://bugs.php.net/bug.php?id=60536edit=1 ID: 60536 Updated by: tony2...@php.net Reported by:scott...@php.net Summary:Traits Segfault -Status: Closed +Status: Re-Opened Type: Bug Package:Scripting Engine problem Operating System: ubuntu 11.11 PHP Version:5.4SVN-2011-12-15 (SVN) Assigned To:laruence Block user comment: N Private report: N New Comment: Valgrind complains about invalid read and writes in the tests: http://dev.daylessday.org/diff/bug60536_001.mem http://dev.daylessday.org/diff/bug60536_003.mem So the problem is definitely not fixed yet. Previous Comments: [2011-12-17 14:26:18] g...@php.net Automatic comment from SVN on behalf of gron Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=321089 Log: Fixed inconsistent and broken handling of private properties in traits. # The handling of private properties in classes is now consistent with private properties in traits. # Perviously, privates could cause strict warnings, are were not properly merged into the class when # the parent class had a private property of the same name. Now, we introduce it without notice, # since it is a new and independent property, just like in normal classes. # This problem was diagnosed while working on Bug #60536. [2011-12-16 19:03:04] larue...@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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2011-12-16 19:02:31] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=321073 Log: Fixed bug #60536 (Traits Segfault) # this is a tough one, I think I should explain # Zend use zend_object-gt;properties_table both as zval ** and zval *** # if a zend_object-gt;properties is not initialized, the properties_table is zval ** # while in rebuild_object_properties, zend will store the zval ** to zend_object-gt;properties # then stash the zval ***(ie, zobj-gt;properties_table[0] is zval ** now) to zobj-gt;properties_table[0] # so when a zend_object inherit form multi parent and these parent have a same property_info-gt;offset # properties, will result in a repeat zval **-gt;zval ** transform, which will lead to a segmentfault # *may be* this fix is not the best fix, we should not use this tricky way, and rewrite this mechanism. [2011-12-16 18:43:37] larue...@php.net I hava another fix for this. I am going to ci it. [2011-12-16 16:47:05] g...@php.net property008.phpt demonstrates the actual issue. 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 https://bugs.php.net/bug.php?id=60536 -- Edit this bug report at https://bugs.php.net/bug.php?id=60536edit=1
Bug #60082 [Asn-Csd]: 100% CPU / when using references with ArrayObject($ref).
Edit report at https://bugs.php.net/bug.php?id=60082edit=1 ID: 60082 Updated by: tony2...@php.net Reported by:tklingenberg at lastflood dot net Summary:100% CPU / when using references with ArrayObject($ref). -Status: Assigned +Status: Closed Type: Bug Package:SPL related Operating System: GNU/Linux PHP Version:5.3.8 Assigned To:helly Block user comment: N Private report: N 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-11-18 05:22:24] tony2...@php.net Automatic comment from SVN on behalf of tony2001 Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=319432 Log: fix bug #60082 (Crash in ArrayObject() when using recursive references) --Tis line, and those below, will be ignored-- Mtrunk/ext/spl/spl_array.c Mbranches/PHP_5_4/ext/spl/spl_array.c Mbranches/PHP_5_3/ext/spl/spl_array.c Mbranches/PHP_5_3/NEWS [2011-11-01 10:10:18] tyr...@php.net Automatic comment from SVN on behalf of tyrael Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318635 Log: marking ext/spl/tests/bug60082.phpt as slow test [2011-10-20 12:22:20] larue...@php.net hmm, your patch seems better, agree. [2011-10-20 05:46:43] tony2...@php.net I'd suggest to try to detect recursion in this case. Unfortunately, I don't see any way to do it except by adding another field to spl_array internal struct. But on the other hand, this struct is not used anywhere except spl_array.c itself, so it should be fine. The patch is attached. [2011-10-20 05:44:42] tony2...@php.net The following patch has been added/updated: Patch Name: recursion-detection Revision: 1319089482 URL: https://bugs.php.net/patch-display.php?bug=60082patch=recursion-detectionrevision=1319089482 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 https://bugs.php.net/bug.php?id=60082 -- Edit this bug report at https://bugs.php.net/bug.php?id=60082edit=1
Bug #59808 [Opn-Csd]: Compilation error: too many arguments to function 'php_json_decode'
Edit report at https://bugs.php.net/bug.php?id=59808edit=1 ID: 59808 Updated by: tony2...@php.net Reported by:eborned at gmail dot com Summary:Compilation error: too many arguments to function 'php_json_decode' -Status: Open +Status: Closed Type: Bug Package:solr Operating System: Debian PHP Version:5.2.17 -Assigned To: +Assigned To:tony2001 Block user comment: N Private report: N 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-10-13 14:23:14] alex at discardmail dot com I have searched through the PHP source tree of 5.2 and 5.3 where it can be seen that the function php_json_decode (in php/ext/json/php_json.h) requires 5 arguments in PHP 5.3 and 4 in PHP 5.2: PHP 5.2: php_json_decode(zval *return_value, char *buf, int buf_len, zend_bool assoc TSRMLS_DC); PHP 5.3: php_json_decode(zval *return_value, char *str, int str_len, zend_bool assoc, long depth TSRMLS_DC) Solr-PECL wants to call php_json_decode with 5 parameters (in solr-1.0.1/solr_functions_helpers.c): php_json_decode(json_decode_ret_val, (char *) json_string, json_string_length, 1, recursion_depth TSRMLS_CC); So it can not be compiled with PHP 5.2 in that way. Additionally the command ZEND_EXTERN_MODULE_GLOBALS(json) does not work with PHP 5.2. I've added a patch which uses the 4-argument-function and does not use ZEND_EXTERN_MODULE_GLOBALS(json) at PHP 5.2. I have not tested if php_json_decode is working after this patch, but at least PECL-solr can be compiled with PHP 5.2 and the other functions are working. Because of this bug it can not be installed via PECL/PEAR, but manually: wget http://pecl.php.net/get/solr-1.0.1.tgz tar xfz solr-1.0.1.tgz cd solr-1.0.1 wget -Opeclsolr.patch 'https://bugs.php.net/patch-display.php?bug_id=59808patch=peclsolr.patchrevision=latestdownload=1' patch solr_functions_helpers.c peclsolr.patch phpize ./configure make make install And then add the extension to your php.ini and restart Apache: extension = solr.so [2011-10-11 15:18:59] php at discardmail dot com Same error on CentOS 5.3 and PHP 5.2.13: ./configure --enable-solr=yes --enable-solr-debug=no --with-curl=/usr/include/curl --with-libxml-dir=/usr/include/libxml2 make solr-1.0.1/solr_functions_helpers.c:23: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âjson_globalsâ solr-1.0.1/solr_functions_helpers.c: In function âsolr_json_to_php_nativeâ: solr-1.0.1/solr_functions_helpers.c:1123: error: too many arguments to function âphp_json_decodeâ make: *** [solr_functions_helpers.lo] Error 1 [2011-09-06 13:15:59] badllama77 at gmail dot com Same issue ubuntu 9.04/php 5.2.6 ubuntu 10.04/php 5.2.10 /home/emyers/src/solr-1.0.1/solr_functions_helpers.c:23: error: expected =, ,, ;, asm or __attribute__ before json_globals /home/emyers/src/solr-1.0.1/solr_functions_helpers.c: In function solr_json_to_php_native: /home/emyers/src/solr-1.0.1/solr_functions_helpers.c:1123: error: too many arguments to function php_json_decode [2011-09-05 07:51:07] james at siteace dot co dot uk I can confirm i have the same issue installing or upgrading on centOS/Plesk and PHP 5.2.10 I have installed the beta version without issue [2011-08-31 18:47:25] ken dot williams at meteorgames dot com Confirmed same issue with php 5.2.11 / Cent5.4 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 https://bugs.php.net/bug.php?id=59808 -- Edit this bug report at https://bugs.php.net/bug.php?id=59808edit=1
Bug #60104 [Opn-Asn]: Segmentation Fault in pdo_sqlite when using sqliteCreateFunction()
Edit report at https://bugs.php.net/bug.php?id=60104edit=1
ID: 60104
Updated by: tony2...@php.net
Reported by:patrickalla...@php.net
Summary:Segmentation Fault in pdo_sqlite when using
sqliteCreateFunction()
-Status: Open
+Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Gentoo Linux
PHP Version:trunk-SVN-2011-10-20 (SVN)
-Assigned To:
+Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Dmitry, could you take a look at it?
Looks like something is wrong with that caching thingie in the executor..
(gdb) f 0
#0 ZEND_INIT_METHOD_CALL_SPEC_CV_CONST_HANDLER (execute_data=0x77f9d1c0)
at /local/qa/5_4_valgrind/Zend/zend_vm_execute.h:28949
28949 if ((EX(fbc)-common.fn_flags ZEND_ACC_STATIC) != 0) {
(gdb) p *execute_data.fbc
$10 = {type = 90 'Z', common = {type = 90 'Z', function_name =
0x5a5a5a5a5a5a5a5a Address 0x5a5a5a5a5a5a5a5a out of bounds, scope =
0x5a5a5a5a5a5a5a5a,
fn_flags = 1515870810, prototype = 0x5a5a5a5a5a5a5a5a, num_args =
1515870810, required_num_args = 1515870810, arg_info = 0x5a5a5a5a5a5a5a5a},
op_array = {type = 90 'Z', function_name = 0x5a5a5a5a5a5a5a5a Address
0x5a5a5a5a5a5a5a5a out of bounds, scope = 0x5a5a5a5a5a5a5a5a,
fn_flags = 1515870810, prototype = 0x5a5a5a5a5a5a5a5a, num_args =
1515870810, required_num_args = 1515870810, arg_info = 0x5a5a5a5a5a5a5a5a,
refcount = 0x5a5a5a5a5a5a5a5a, opcodes = 0x5a5a5a5a5a5a5a5a, last =
1515870810, vars = 0x5a5a5a5a5a5a5a5a, last_var = 1515870810, T = 1515870810,
brk_cont_array = 0x5a5a5a5a5a5a5a5a, last_brk_cont = 1515870810,
try_catch_array = 0x5a5a5a5a5a5a5a5a, last_try_catch = 1515870810,
static_variables = 0x5a5a5a5a5a5a5a5a, this_var = 1515870810, filename =
0x5a5a5a5a5a5a5a5a Address 0x5a5a5a5a5a5a5a5a out of bounds,
line_start = 1515870810, line_end = 1515870810, doc_comment =
0x5a5a5a5a5a5a5a5a Address 0x5a5a5a5a5a5a5a5a out of bounds,
doc_comment_len = 1515870810, early_binding = 1515870810, literals =
0x5a5a5a5a5a5a5a5a, last_literal = 1515870810,
run_time_cache = 0x5a5a5a5a5a5a5a5a, last_cache_slot = 1515870810, reserved
= {0x5a5a5a5a5a5a5a5a, 0x5a5a5a5a5a5a5a5a, 0x5a5a5a5a5a5a5a5a,
0x5a5a5a5a5a5a5a5a}}, internal_function = {type = 90 'Z', function_name =
0x5a5a5a5a5a5a5a5a Address 0x5a5a5a5a5a5a5a5a out of bounds,
scope = 0x5a5a5a5a5a5a5a5a, fn_flags = 1515870810, prototype =
0x5a5a5a5a5a5a5a5a, num_args = 1515870810, required_num_args = 1515870810,
arg_info = 0x5a5a5a5a5a5a5a5a, handler = 0x5a5a5a5a5a5a5a5a, module =
0x5a5a5a5a5a5a5a5a}}
Previous Comments:
[2011-11-04 19:13:31] patrickalla...@php.net
Automatic comment from SVN on behalf of patrickallaert
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318784
Log: Added test for #60104
[2011-10-26 09:34:35] patrickalla...@php.net
I have been able to reproduce it without PHPUnit.
I committed ext/pdo_sqlite/tests/bug60104.phpt to make it easier.
[2011-10-26 09:32:34] patrickalla...@php.net
Automatic comment from SVN on behalf of patrickallaert
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318424
Log: Added test for #60104
[2011-10-21 10:15:16] patrickalla...@php.net
The segfault appears the second time it executes $this-handler-
sqliteCreateFunction() in the setUp().
If unset() isn't used in tearDown(), then there is no crash.
[2011-10-21 07:30:03] patrickalla...@php.net
?php
class SegfaultTest extends PHPUnit_Framework_TestCase
{
protected $handler;
public function setUp()
{
try
{
$this-handler = new PDO( sqlite::memory: );
$this-handler-sqliteCreateFunction( 'md5', array(
'ezcQuerySqliteFunctions', 'md5Impl' ), 1 );
}
catch ( PDOException $e )
{
$this-markTestSkipped(
'PDO session could not be created: ' . $e-getMessage()
);
}
}
public function tearDown()
{
unset( $this-handler );
}
public function testOne()
{
}
public function testTwo()
{
}
}
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
https://bugs.php.net/bug.php?id=60104
--
Edit this bug report at https://bugs.php.net/bug.php?id=60104edit=1
Bug #60082 [Asn]: 100% CPU / when using references with ArrayObject($ref).
Edit report at https://bugs.php.net/bug.php?id=60082edit=1 ID: 60082 Updated by: tony2...@php.net Reported by:tklingenberg at lastflood dot net Summary:100% CPU / when using references with ArrayObject($ref). Status: Assigned Type: Bug Package:SPL related Operating System: GNU/Linux PHP Version:5.3.8 Assigned To:helly Block user comment: N Private report: N New Comment: I'd suggest to try to detect recursion in this case. Unfortunately, I don't see any way to do it except by adding another field to spl_array internal struct. But on the other hand, this struct is not used anywhere except spl_array.c itself, so it should be fine. The patch is attached. Previous Comments: [2011-10-20 05:44:42] tony2...@php.net The following patch has been added/updated: Patch Name: recursion-detection Revision: 1319089482 URL: https://bugs.php.net/patch-display.php?bug=60082patch=recursion-detectionrevision=1319089482 [2011-10-19 02:28:53] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=318204 Log: Test for #60082 [2011-10-19 02:09:08] larue...@php.net helly, plz look at this. thanks :) [2011-10-18 12:51:03] larue...@php.net The following patch has been added/updated: Patch Name: bug60082.phpt Revision: 1318942263 URL: https://bugs.php.net/patch-display.php?bug=60082patch=bug60082.phptrevision=1318942263 [2011-10-18 12:46:20] larue...@php.net The following patch has been added/updated: Patch Name: bug60082.patch Revision: 1318941980 URL: https://bugs.php.net/patch-display.php?bug=60082patch=bug60082.patchrevision=1318941980 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 https://bugs.php.net/bug.php?id=60082 -- Edit this bug report at https://bugs.php.net/bug.php?id=60082edit=1
Bug #55768 [Opn-Csd]: PDO_OCI can't resume session when kill Oracle session's
Edit report at https://bugs.php.net/bug.php?id=55768edit=1 ID: 55768 Updated by: tony2...@php.net Reported by:mikhail dot v dot gavrilov at gmail dot com Summary:PDO_OCI can't resume session when kill Oracle session's -Status: Open +Status: Closed Type: Bug Package:Oracle related Operating System: All PHP Version:5.3.8 -Assigned To: +Assigned To:tony2001 Block user comment: N Private report: N 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-09-27 09:11:54] tony2...@php.net Automatic comment from SVN on behalf of tony2001 Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=317381 Log: fix bug #55768 (PDO_OCI can't resume Oracle session after it's been killed) [2011-09-23 13:04:06] mikhail dot v dot gavrilov at gmail dot com Description: I found problem in PDO_OCI, if Oracle session killed by ALTER SYSTEM KILL SESSION operator, PDO_OCI can't resume session. For example we can find all PHP active sessions on Oracle: SELECT 'ALTER SYSTEM KILL SESSION ''' || s.sid||','|| s.serial#||''' IMMEDIATE;' FROM gv$session s JOIN gv$process p ON p.addr = s.paddr AND p.inst_id = s.inst_id WHERE s.type != 'BACKGROUND'and s.program like 'php-fpm: pool%'; And run results strings for kill session: ALTER SYSTEM KILL SESSION ',xxx' IMMEDIATE; ALTER SYSTEM KILL SESSION ',xxx' IMMEDIATE; First error that catch PHP script look so: SQLSTATE[01002]: Disconnect error: 3113 OCIStmtExecute: Error while trying to retrieve text for error ORA-03113 separator not found in message(3144)separator not found in message(3142) (/root/rpmbuild/BUILD/php-5.3.8/ext/pdo_oci/oci_statement.c:148) Second and all next error look so: SQLSTATE[HY000]: General error: 3114 OCIStmtExecute: Error while trying to retrieve text for error ORA-03114 (/root/rpmbuild/BUILD/php-5.3.8/ext/pdo_oci/oci_statement.c:148) My connection parameters: PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION PDO::ATTR_PERSISTENT = true PDO::ATTR_AUTOCOMMIT = false -- Edit this bug report at https://bugs.php.net/bug.php?id=55768edit=1
Bug #55410 [Opn-Asn]: Apache's crash with trait in a separate file
Edit report at https://bugs.php.net/bug.php?id=55410edit=1 ID: 55410 Updated by: tony2...@php.net Reported by:paddelman at hotmail dot com Summary:Apache's crash with trait in a separate file -Status: Open +Status: Assigned Type: Bug -Package:Reproducible crash +Package:Scripting Engine problem Operating System: Windows XP PHP Version:5.4.0alpha3 -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N New Comment: Valgrind log: https://gist.github.com/1141668 Some GDB data: https://gist.github.com/9232dcdd3b48d646c5c6 Previous Comments: [2011-08-12 08:23:28] paddelman at hotmail dot com Debug Report: Analysis Summary Type Description Recommendation Error WARNING - DebugDiag was not able to locate debug symbols for php5ts.dll, so the information below may be incomplete. In apache__PID__4388__Date__08_12_2011__Time_09_35_55AM__156__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!zend_mm_set_custom_handlers+270 in G:\Apps\EasyPhp\EasyPHP-5.4alpha3\php\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x0100 on thread 63 Please follow up with the vendor The PHP Group for G:\Apps\EasyPhp\EasyPHP-5.4alpha3\php\php5ts.dll Information DebugDiag determined that this dump file (apache__PID__4388__Date__08_12_2011__Time_09_35_55AM__156__Second_Chance_Exception_C005.dmp) is a crash dump and did not perform any hang analysis. If you wish to enable combined crash and hang analysis for crash dumps, edit the CrashHangAnalysis.asp script (located in the DebugDiag\Scripts folder) and set the g_DoCombinedAnalysis constant to True. Analysis Details Your browser settings are currently prohibiting this report's scripts from running. This is preventing some features of this analysis report from displaying properly. To enable scripts to run, right-click the security warning above and choose Allow Blocked Content... or enable the Allow active content to run in files on My Computer* setting on the Advanced tab of your Internet Options dialog to avoid being prompted in the future Table Of Contents apache__PID__4388__Date__08_12_2011__Time_09_35_55AM__156__Second_Chance_Exception_C005.dmp Faulting Thread Faulting Module Information Report for apache__PID__4388__Date__08_12_2011__Time_09_35_55AM__156__Second_Chance_Exception_C005.dmp Report for apache__PID__4388__Date__08_12_2011__Time_09_35_55AM__156__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name SATINA Operating System Windows XP Service Pack 3 Number Of Processors 2 Process ID 4388 Process Image G:\Apps\EasyPhp\EasyPHP-5.4alpha3\apache\bin\apache.exe System Up-Time 02:37:38 Process Up-Time 00:02:35 Thread 63 - System ID 5176 Entry point msvcr90!endthreadex+6f Create time 12/08/2011 09:33:23 Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.15 Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_mm_set_custom_handlers+270 0054 02eedf58 php5ts!safe_emalloc+74 PHP5TS!ZEND_MM_SET_CUSTOM_HANDLERS+270WARNING - DebugDiag was not able to locate debug symbols for php5ts.dll, so the information below may be incomplete. In apache__PID__4388__Date__08_12_2011__Time_09_35_55AM__156__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!zend_mm_set_custom_handlers+270 in G:\Apps\EasyPhp\EasyPHP-5.4alpha3\php\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x0100 on thread 63 Module Information Image Name: G:\Apps\EasyPhp\EasyPHP-5.4alpha3\php\php5ts.dll Symbol Type: Export Base address: 0x00b9 Time Stamp: Thu Aug 04 12:43:07 2011 Checksum: 0x005ecb62 Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.4.0alpha3 Managed DLL: False Internal Name: PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2010 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Module Size: 6,04 MBytes Product Version: 5.4.0alpha3 Symbol File Name: php5ts.dll Special Build: [2011-08-12 08:20:59] paddelman at hotmail dot com Description: When using traits (in a separate file!),
Bug #55339 [Opn-Asn]: Segfault with allow_call_time_pass_reference = Off
Edit report at https://bugs.php.net/bug.php?id=55339edit=1
ID: 55339
Updated by: tony2...@php.net
Reported by:tomas dot brastavicius at quantum dot lt
Summary:Segfault with allow_call_time_pass_reference = Off
-Status: Open
+Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3SVN-2011-08-01 (SVN)
-Assigned To:
+Assigned To:dmitry
Block user comment: N
Private report: N
Previous Comments:
[2011-08-01 19:47:31] tomas dot brastavicius at quantum dot lt
Description:
The scripts that are provided below causes segfault. The following
configuration was used to compile PHP:
./configure --disable-all
Test script:
---
To reproduce the bug one needs 3 PHP files:
1. index.php
?php
function error_handler($errno, $errstr, $errfile, $errline)
{
require_once 'error_handler.php';
}
set_error_handler('error_handler');
require_once('inc.php');
echo 'Never prints';
2. error_handler.php
?php
// The file may be empty. It's OK.
3. inc.php
?php
function foo()
{
$array = array();
foreach ($array as $key = $value) {
bar($key, $value);
}
}
function bar()
{
}
Before running index.php be sure allow_call_time_pass_reference is Off
Expected result:
Never prints
Actual result:
--
Program terminated with signal 11, Segmentation fault.
#0 0x006210e7 in ?? ()
(gdb) bt
#0 0x006210e7 in ?? ()
#1 0x0001 in ?? ()
#2 0x7f3a4a29d390 in ?? ()
#3 0x in ?? ()
--
Edit this bug report at https://bugs.php.net/bug.php?id=55339edit=1
Bug #54488 [Asn]: SIGSEGV in zend_assign_to_variable
Edit report at https://bugs.php.net/bug.php?id=54488edit=1 ID: 54488 Updated by: tony2...@php.net Reported by:dbetz at df dot eu Summary:SIGSEGV in zend_assign_to_variable Status: Assigned Type: Bug Package:FPM related Operating System: Gentoo PHP Version:5.3.6 Assigned To:fat Block user comment: N Private report: N New Comment: Valgrind log would be quite helpful: https://bugs.php.net/bugs-getting-valgrind-log.php Previous Comments: [2011-07-12 19:08:38] f...@php.net I've asked for help on internals: http://news.php.net/php.internals/53922 see where it goes [2011-07-07 02:38:16] dbetz at df dot eu Hello, with 5.3.7RC3-dev i cant hit the bug anymore ( i think ) I will keep on testing. Thx, Daniel [2011-07-06 08:56:27] dbetz at df dot eu Ah, what i have forgotten: With debug flags in the php-fpm binary the segfaults seems not to occur so often. I try now the latest snapshot to see if the problem is there too. [2011-07-06 08:41:50] dbetz at df dot eu Oh sorry, my failure. Now its 5.3.6 and the problem still exists with that version. Greetings, Daniel [2011-07-06 08:32:58] f...@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. you are reporting using 5.3.6 but on the phpinfo() page you provide us it's 5.3.5. Is it possible for you to test using the last snapshot of 5.3 please ? thx ++ jerome 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 https://bugs.php.net/bug.php?id=54488 -- Edit this bug report at https://bugs.php.net/bug.php?id=54488edit=1
Bug #51914 [Opn-Fbk]: __autoload Does not Work in error_handler function by some case
Edit report at http://bugs.php.net/bug.php?id=51914edit=1
ID: 51914
Updated by: tony2...@php.net
Reported by:i at walkinraven dot name
Summary:__autoload Does not Work in error_handler function
by some case
-Status: Open
+Status: Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: Ubuntu 8.04
PHP Version:5.2.13
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2010-05-26 05:18:04] i at walkinraven dot name
Description:
If your script does as below step, it will cause autoload function
halt:
1. You have set an user-defined error handler function.
2. A statement need autoload.
3. The __autoload function emit an error.
4. The user-defined error handler function need autoload.
Test script:
---
URI: http://docs.google.com/View?id=dgt79v8r_120cwxm5mrg
Expected result:
Should not emit any fatal error
Actual result:
--
Fatal error: Class 'Class_A' not found in /usr/share/php/PEAR.php on
line 569
Call Stack:
0.0002 60296 1. {main}()
/home/winfred/workspace/Test/applications/Bugs/new/index.php:0
0.0003 61216 2. __autoload()
/home/winfred/workspace/Test/applications/Bugs/new/index.php:0
0.0012 176604 3. error_handler()
/home/winfred/workspace/Test/applications/Bugs/new/index.php:0
--
Edit this bug report at http://bugs.php.net/bug.php?id=51914edit=1
Bug #54721 [Asn]: crypt function
Edit report at http://bugs.php.net/bug.php?id=54721edit=1 ID: 54721 Updated by: tony2...@php.net Reported by:os at irj dot ru Summary:crypt function Status: Assigned Type: Bug Package:*Encryption and hash functions Operating System: Windows 7 x64 PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: Pierre, could you test the proposed fix, please? Thanks in advance. Previous Comments: [2011-05-16 17:18:12] paj...@php.net Please note that as this code may or should produce similar results on all platforms or builds, it is not correct. MD5 salt is max. 12 characters as described in the manual and how the extra characters are treated are implementation specific. Use blowfish or other stronger algorithm if you like to use a bigger salt. [2011-05-16 16:46:03] paj...@php.net Confirmed. Seems to be only happening in the TS API. [2011-05-13 06:16:20] os at irj dot ru At Windows XP Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: C:\tmpphp test.php $1$dW0.is5.$UW7SlpXxFDXZ9zHcYQy.l/ C:\tmpphp test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmpphp test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmpphp test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmpphp test.php C:\tmpphp -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies [2011-05-13 06:06:23] os at irj dot ru From download page I downloaded VC9 x86 Thread Safe (2011-Mar-22 13:27:32) as ZIP arhive, unzip it and run test script at office using cli interface on Microsoft Windows 7 x86, bug too. Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: D:\tmpphp test.php pre $1$dW0.is5.$EkFno5M.sWHzVKG.KcE4g. D:\tmpphp test.php pre $1$dW0.is5.$C08LtG..f5qYCBEqaEaeV. D:\tmpphp test.php pre $1$dW0.is5.$U.zA4AF2/AvLMpxAdd57x1 D:\tmpphp test.php pre $1$dW0.is5.$FO6NpJOzWGbHX3Al2BRcU1 D:\tmpphp test.php pre $1$dW0.is5.$OoBfHS6yulKgQHVDZ8XLx/ D:\tmpphp -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\tmp [2011-05-12 18:58:23] os at irj dot ru Sorry, in cli mode bug too (in previos command I use a old CLI php) This is a correct log D:\Web\var\avers.localhostD:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php pre $1$dW0.is5.$.O4MUs7rYRmlSuPIA16Jt. D:\Web\var\avers.localhostD:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php pre $1$dW0.is5.$sVRmxDm7.B8xcTu1HZKf6/ D:\Web\var\avers.localhostD:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php pre $1$dW0.is5.$zI8c4NaU.KzK2y5u.W4Ax. D:\Web\var\avers.localhostD:\Web\php53\php.exe -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\Web\var\avers.localhostD:\curl\curl.exe http://avers.localhost/test.php pre $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhostD:\curl\curl.exe http://avers.localhost/test.php pre $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost..\..\apache22\bin\httpd.exe -k restart httpd.exe: Could not reliably determine the server's fully qualified domain name , using 192.168.0.240 for ServerName D:\Web\var\avers.localhostD:\curl\curl.exe http://avers.localhost/test.php pre $1$dW0.is5.$.y5yjTLPgypzeHv0FU7zW0 D:\Web\var\avers.localhostD:\Web\php53\php.exe D:\Web\var\avers.localhost\test .php pre $1$dW0.is5.$m.YjcIs.joLsQHQGZ0bxn/ D:\Web\var\avers.localhost 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=54721 -- Edit this bug report at http://bugs.php.net/bug.php?id=54721edit=1
Bug #54721 [Opn-Asn]: crypt function
Edit report at http://bugs.php.net/bug.php?id=54721edit=1 ID: 54721 Updated by: tony2...@php.net Reported by:os at irj dot ru Summary:crypt function -Status: Open +Status: Assigned Type: Bug Package:*Encryption and hash functions Operating System: Windows 7 x64 PHP Version:5.3.6 -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N Previous Comments: [2011-05-13 06:16:20] os at irj dot ru At Windows XP Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: C:\tmpphp test.php $1$dW0.is5.$UW7SlpXxFDXZ9zHcYQy.l/ C:\tmpphp test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmpphp test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmpphp test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmpphp test.php C:\tmpphp -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies [2011-05-13 06:06:23] os at irj dot ru From download page I downloaded VC9 x86 Thread Safe (2011-Mar-22 13:27:32) as ZIP arhive, unzip it and run test script at office using cli interface on Microsoft Windows 7 x86, bug too. Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: D:\tmpphp test.php pre $1$dW0.is5.$EkFno5M.sWHzVKG.KcE4g. D:\tmpphp test.php pre $1$dW0.is5.$C08LtG..f5qYCBEqaEaeV. D:\tmpphp test.php pre $1$dW0.is5.$U.zA4AF2/AvLMpxAdd57x1 D:\tmpphp test.php pre $1$dW0.is5.$FO6NpJOzWGbHX3Al2BRcU1 D:\tmpphp test.php pre $1$dW0.is5.$OoBfHS6yulKgQHVDZ8XLx/ D:\tmpphp -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\tmp [2011-05-12 18:58:23] os at irj dot ru Sorry, in cli mode bug too (in previos command I use a old CLI php) This is a correct log D:\Web\var\avers.localhostD:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php pre $1$dW0.is5.$.O4MUs7rYRmlSuPIA16Jt. D:\Web\var\avers.localhostD:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php pre $1$dW0.is5.$sVRmxDm7.B8xcTu1HZKf6/ D:\Web\var\avers.localhostD:\Web\php53\php.exe D:\Web\var\avers.localhost\test. php pre $1$dW0.is5.$zI8c4NaU.KzK2y5u.W4Ax. D:\Web\var\avers.localhostD:\Web\php53\php.exe -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\Web\var\avers.localhostD:\curl\curl.exe http://avers.localhost/test.php pre $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhostD:\curl\curl.exe http://avers.localhost/test.php pre $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost..\..\apache22\bin\httpd.exe -k restart httpd.exe: Could not reliably determine the server's fully qualified domain name , using 192.168.0.240 for ServerName D:\Web\var\avers.localhostD:\curl\curl.exe http://avers.localhost/test.php pre $1$dW0.is5.$.y5yjTLPgypzeHv0FU7zW0 D:\Web\var\avers.localhostD:\Web\php53\php.exe D:\Web\var\avers.localhost\test .php pre $1$dW0.is5.$m.YjcIs.joLsQHQGZ0bxn/ D:\Web\var\avers.localhost [2011-05-12 18:50:22] os at irj dot ru In CLI mode crypt function work normaly, but as apache 2 module bug present CMD Log: Microsoft Windows [Version 6.1.7601] (c) ÐоÑпоÑаÑÐ¸Ñ ÐайкÑоÑоÑÑ (Microsoft Corp.), 2009. ÐÑе пÑава заÑиÑенÑ. C:\Windows\system32cd D:\Web\var\avers.localhost C:\Windows\system32d: D:\Web\var\avers.localhostD:\Web\bin\php\php.exe D:\Web\var\avers.localhost\te st.php pre $1$dW0.is5.$em49ePD07X75OTvpVod410 D:\Web\var\avers.localhostD:\curl\curl.exe http://avers.localhost/test.php pre $1$dW0.is5.$d2QAXWA.uqHWaY1KopvYr. D:\Web\var\avers.localhost..\..\apache22\bin\httpd.exe -k restart httpd.exe: Could not reliably determine the server's fully qualified domain name , using 192.168.0.240 for ServerName D:\Web\var\avers.localhostD:\curl\curl.exe http://avers.localhost/test.php pre $1$dW0.is5.$PD4o/IBVjS2AVWa1.Rpdi/ D:\Web\var\avers.localhost [2011-05-12 18:32:55] paj...@php.net The browsers have nothing to do with the server side running code. Please try using the CLI interface (cmd line) to confirm the results. 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=54721 -- Edit this bug report at
Bug #54367 [Csd-ReO]: Use of closure causes problem in ArrayAccess
Edit report at http://bugs.php.net/bug.php?id=54367edit=1
ID: 54367
Updated by: tony2...@php.net
Reported by:jpa...@php.net
Summary:Use of closure causes problem in ArrayAccess
-Status: Closed
+Status: Re-Opened
Type: Bug
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The test for this bug causes invalid read and subsequent segfault in 5_3
(but works fine in trunk):
==17645== Invalid read of size 8
==17645==at 0x93625F: _zval_ptr_dtor (zend_execute_API.c:446)
==17645==by 0x97BAD6: zend_leave_helper_SPEC
(zend_vm_execute.h:167)
==17645==by 0x980ACE: ZEND_RETURN_SPEC_CONST_HANDLER
(zend_vm_execute.h:1714)
==17645==by 0x97B8E6: execute (zend_vm_execute.h:107)
==17645==by 0x947FBE: zend_execute_scripts (zend.c:1194)
==17645==by 0x8D2E56: php_execute_script (main.c:2275)
==17645==by 0xA2C0A5: main (php_cli.c:1193)
==17645== Address 0xa74fb98 is 56 bytes inside a block of size 264
free'd
==17645==at 0x4C2599C: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17645==by 0x922C77: _efree (zend_alloc.c:2358)
==17645==by 0x96F0A9: zend_closure_free_storage
(zend_closures.c:190)
==17645==by 0x975C47: zend_objects_store_del_ref_by_handle_ex
(zend_objects_API.c:220)
==17645==by 0x9759AE: zend_objects_store_del_ref
(zend_objects_API.c:172)
==17645==by 0x945591: _zval_dtor_func (zend_variables.c:52)
==17645==by 0x93528B: _zval_dtor (zend_variables.h:35)
==17645==by 0x93625A: _zval_ptr_dtor (zend_execute_API.c:445)
==17645==by 0x97BAD6: zend_leave_helper_SPEC
(zend_vm_execute.h:167)
==17645==by 0x980ACE: ZEND_RETURN_SPEC_CONST_HANDLER
(zend_vm_execute.h:1714)
==17645==by 0x97B8E6: execute (zend_vm_execute.h:107)
==17645==by 0x947FBE: zend_execute_scripts (zend.c:1194)
Previous Comments:
[2011-04-20 15:00:11] dmi...@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.
[2011-04-20 14:59:21] dmi...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=310389
Log: Fixed bug #54367 (Use of closure causes problem in ArrayAccess).
[2011-03-25 09:55:25] jpa...@php.net
Felipe: strange, I got no crash with your code (5.3.6,Linux,
self-compiled)
[2011-03-24 22:49:49] fel...@php.net
I can reproduce a crash with:
?php
class MyObjet implements ArrayAccess
{
public function __construct() { }
public function offsetSet($offset, $value) { }
public function offsetExists($offset) { }
public function offsetUnset($offset) { }
public function offsetGet ($offset) {
return function () { };
}
}
$a = new MyObjet();
echo $a['p']('foo');
?
Breakpoint 1, 0x085368b3 in ZEND_SEND_VAL_SPEC_CONST_HANDLER
(execute_data=0x8ade614, tsrm_ls=0x89022a0)
at /home/felipe/dev/php5/Zend/zend_vm_execute.h:1719
1719 ARG_MUST_BE_SENT_BY_REF(EX(fbc),
opline-op2.u.opline_num)) {
(gdb) p execute_data-fbc-common
$7 = {type = 90 'Z', function_name = 0x5a5a5a5a Address 0x5a5a5a5a out
of bounds, scope = 0x5a5a5a5a, fn_flags = 1515870810,
prototype = 0x5a5a5a5a, num_args = 1515870810, required_num_args =
1515870810, arg_info = 0x5a5a5a5a, pass_rest_by_reference = 90 'Z',
return_reference = 90 'Z'}
[2011-03-24 13:52:23] jpa...@php.net
Description:
Closures cant use variables from external context when the context is in
ArrayAccess method
Test script:
---
?php
class MyObjet implements ArrayAccess
{
// All the stuff for ArrayAccess
public function offsetGet ($offset)
{
return function ($var) use ($offset) { // here is the problem
return sprintf('%s%s/%$1s', $offset, $var);
};
}
}
$a = new MyObjet();
echo $a['p']('foo');
Expected result:
pfoo/p
Actual result:
--
PHP Notice: Undefined variable: offset in {file.php} on line 11
--
Edit this bug report at http://bugs.php.net/bug.php?id=54367edit=1
Bug #54644 [Asn]: wrong pathes in php_pdo_mysql_int.h
Edit report at http://bugs.php.net/bug.php?id=54644edit=1 ID: 54644 Updated by: tony2...@php.net Reported by:public at grik dot net Summary:wrong pathes in php_pdo_mysql_int.h Status: Assigned Type: Bug Package:PDO related Operating System: unix PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: Andrey, whatever that header is, its contents is not used in PDO_MYSQL and the header itself is not installed, which means there's not way to build PDO_MYSQL+mysqlnd dynamically. Previous Comments: [2011-05-03 09:21:09] and...@php.net Tony, you are not exactly right. ext/mysql/mysql_mysqlnd.h is not a left-over. If you take a look into ext/mysqli you will find mysqli_mysqlnd.h, which is larger but follows the same schema - ext_driver (mysqli_libmysql.h exists). However, mysql_myslqnd.h is so small, that it could be incorporated into another file, if wanted. Best, Andrey [2011-05-03 06:56:38] tony2...@php.net I didn't commit the patch yet, I still want to hear from the MySQL guys first. Also it's their domain, not mine. [2011-05-02 22:32:28] public at grik dot net thanks! I am sorry for the wrong initial description, complaining at # include ext/mysqlnd/mysqlnd.h while the error clearly told about ext/mysql/mysql_mysqlnd.h [2011-05-02 21:20:36] tony2...@php.net There's also another issue: you can't install mysqlnd itself, you have to install one of the extensions using it. So in order to build shared version of PDO_MYSQL with myslnd you have to build ext/mysql with myslnd *statically*. I believe ext/mysqlND should be full-grown extension with its own --enable-mysqlnd option, this was you could build it separately AND still be able to use your automagic with $PHP_MYSQLND_ENABLED. [2011-05-02 21:12:41] tony2...@php.net The problem is quite weird. I guess this line: # include ext/mysql/mysql_mysqlnd.h ..is some kind of leftover from the good ol' times when mysqlnd was a part of ext/mysql/; at least nothing breaks if I remove it. So the patch is as easy as this: --- php_pdo_mysql_int.h (revision 307861) +++ php_pdo_mysql_int.h (working copy) @@ -25,7 +25,6 @@ #if defined(PDO_USE_MYSQLND) # include ext/mysqlnd/mysqlnd.h -# include ext/mysql/mysql_mysqlnd.h # include ext/mysqlnd/mysqlnd_libmysql_compat.h # define PDO_MYSQL_PARAM_BIND MYSQLND_PARAM_BIND #else 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=54644 -- Edit this bug report at http://bugs.php.net/bug.php?id=54644edit=1
Bug #54644 [Asn]: wrong pathes in php_pdo_mysql_int.h
Edit report at http://bugs.php.net/bug.php?id=54644edit=1 ID: 54644 Updated by: tony2...@php.net Reported by:public at grik dot net Summary:wrong pathes in php_pdo_mysql_int.h Status: Assigned Type: Bug Package:PDO related Operating System: unix PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: The problem is quite weird. I guess this line: # include ext/mysql/mysql_mysqlnd.h ..is some kind of leftover from the good ol' times when mysqlnd was a part of ext/mysql/; at least nothing breaks if I remove it. So the patch is as easy as this: --- php_pdo_mysql_int.h (revision 307861) +++ php_pdo_mysql_int.h (working copy) @@ -25,7 +25,6 @@ #if defined(PDO_USE_MYSQLND) # include ext/mysqlnd/mysqlnd.h -# include ext/mysql/mysql_mysqlnd.h # include ext/mysqlnd/mysqlnd_libmysql_compat.h # define PDO_MYSQL_PARAM_BIND MYSQLND_PARAM_BIND #else Previous Comments: [2011-05-02 20:19:11] public at grik dot net There is one phpize in the system, and I reinstalled PHP to ensure the error persists. mysqlnd.h exists and is present in the proper folder [root@devel php-5.3.6]# whereis phpize phpize: /usr/local/bin/phpize [root@devel php-5.3.6]# phpize -v Configuring for: PHP Api Version: 20090626 Zend Module Api No: 20090626 Zend Extension Api No: 220090626 [root@devel php-5.3.6]# locate mysqlnd.h /usr/local/include/php/ext/mysqlnd/mysqlnd.h /usr/local/include/php/ext/mysqlnd/php_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysql/mysql_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqli/mysqli_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/php_mysqlnd.h [root@devel php-5.3.6]# ll /usr/local/include/php/ext/mysqlnd/mysqlnd.h -rw-r--r-- 1 root root 17088 2011-05-02 20:49 /usr/local/include/php/ext/mysqlnd/mysqlnd.h [root@devel php-5.3.6]# php-config --includes -I/usr/local/include/php -I/usr/local/include/php/main - I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend - I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib [2011-05-02 19:11:42] public at grik dot net Look: # tar -xjf php-5.3.6.tar.bz2 mysqli]# cd php-5.3.6/ext/mysqli/ mysqli]# phpize; ./configure --with-mysqli=mysqlnd; make ... Build complete. Don't forget to run 'make test'. mysqli]# cd ../pdo_mysql/ pdo_mysql]# phpize;./configure --with-pdo-mysql=mysqlnd;make ... In file included from /usr/src/web/php-5.3.6/ext/pdo_mysql/pdo_mysql.c:32: /usr/src/web/php-5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h:28:38: error: ext/mysql/mysql_mysqlnd.h: No such file or directory make: *** [pdo_mysql.lo] Error 1 # php -v PHP 5.3.6 (cli) (built: Apr 30 2011 21:21:49) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies pdo_mysql]# cd ../.. php-5.3.6]# ./configure --with-pdo-mysql=mysqlnd;make Build complete. Don't forget to run 'make test'. What else can I show you? [2011-05-02 14:43:08] johan...@php.net The mysqlnd.h file inside the distribution is *not* the file you are looking for. You are looking for a file installed on your system. The installation where phpize is coming from. [2011-05-02 13:40:20] public at grik dot net yes, I have it installed. It was a re-compilation of an extension due to another error: http://bugs.php.net/bug.php?id=54646 I understand you are busy and abused by reports, but this is not that case. I managed to recompile it after patching the header file. Please re-read the description. [2011-05-02 13:32:13] johan...@php.net To compile the extension stand-alone you need an installed PHP. I was asking about that. 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=54644 -- Edit this bug report at http://bugs.php.net/bug.php?id=54644edit=1
Bug #54644 [Asn]: wrong pathes in php_pdo_mysql_int.h
Edit report at http://bugs.php.net/bug.php?id=54644edit=1 ID: 54644 Updated by: tony2...@php.net Reported by:public at grik dot net Summary:wrong pathes in php_pdo_mysql_int.h Status: Assigned Type: Bug Package:PDO related Operating System: unix PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: There's also another issue: you can't install mysqlnd itself, you have to install one of the extensions using it. So in order to build shared version of PDO_MYSQL with myslnd you have to build ext/mysql with myslnd *statically*. I believe ext/mysqlND should be full-grown extension with its own --enable-mysqlnd option, this was you could build it separately AND still be able to use your automagic with $PHP_MYSQLND_ENABLED. Previous Comments: [2011-05-02 21:12:41] tony2...@php.net The problem is quite weird. I guess this line: # include ext/mysql/mysql_mysqlnd.h ..is some kind of leftover from the good ol' times when mysqlnd was a part of ext/mysql/; at least nothing breaks if I remove it. So the patch is as easy as this: --- php_pdo_mysql_int.h (revision 307861) +++ php_pdo_mysql_int.h (working copy) @@ -25,7 +25,6 @@ #if defined(PDO_USE_MYSQLND) # include ext/mysqlnd/mysqlnd.h -# include ext/mysql/mysql_mysqlnd.h # include ext/mysqlnd/mysqlnd_libmysql_compat.h # define PDO_MYSQL_PARAM_BIND MYSQLND_PARAM_BIND #else [2011-05-02 20:19:11] public at grik dot net There is one phpize in the system, and I reinstalled PHP to ensure the error persists. mysqlnd.h exists and is present in the proper folder [root@devel php-5.3.6]# whereis phpize phpize: /usr/local/bin/phpize [root@devel php-5.3.6]# phpize -v Configuring for: PHP Api Version: 20090626 Zend Module Api No: 20090626 Zend Extension Api No: 220090626 [root@devel php-5.3.6]# locate mysqlnd.h /usr/local/include/php/ext/mysqlnd/mysqlnd.h /usr/local/include/php/ext/mysqlnd/php_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysql/mysql_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqli/mysqli_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/php_mysqlnd.h [root@devel php-5.3.6]# ll /usr/local/include/php/ext/mysqlnd/mysqlnd.h -rw-r--r-- 1 root root 17088 2011-05-02 20:49 /usr/local/include/php/ext/mysqlnd/mysqlnd.h [root@devel php-5.3.6]# php-config --includes -I/usr/local/include/php -I/usr/local/include/php/main - I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend - I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib [2011-05-02 19:11:42] public at grik dot net Look: # tar -xjf php-5.3.6.tar.bz2 mysqli]# cd php-5.3.6/ext/mysqli/ mysqli]# phpize; ./configure --with-mysqli=mysqlnd; make ... Build complete. Don't forget to run 'make test'. mysqli]# cd ../pdo_mysql/ pdo_mysql]# phpize;./configure --with-pdo-mysql=mysqlnd;make ... In file included from /usr/src/web/php-5.3.6/ext/pdo_mysql/pdo_mysql.c:32: /usr/src/web/php-5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h:28:38: error: ext/mysql/mysql_mysqlnd.h: No such file or directory make: *** [pdo_mysql.lo] Error 1 # php -v PHP 5.3.6 (cli) (built: Apr 30 2011 21:21:49) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies pdo_mysql]# cd ../.. php-5.3.6]# ./configure --with-pdo-mysql=mysqlnd;make Build complete. Don't forget to run 'make test'. What else can I show you? [2011-05-02 14:43:08] johan...@php.net The mysqlnd.h file inside the distribution is *not* the file you are looking for. You are looking for a file installed on your system. The installation where phpize is coming from. [2011-05-02 13:40:20] public at grik dot net yes, I have it installed. It was a re-compilation of an extension due to another error: http://bugs.php.net/bug.php?id=54646 I understand you are busy and abused by reports, but this is not that case. I managed to recompile it after patching the header file. Please re-read the description. 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=54644 -- Edit this bug report at http://bugs.php.net/bug.php?id=54644edit=1
Bug #54644 [Csd-Asn]: wrong pathes in php_pdo_mysql_int.h
Edit report at http://bugs.php.net/bug.php?id=54644edit=1 ID: 54644 Updated by: tony2...@php.net Reported by:public at grik dot net Summary:wrong pathes in php_pdo_mysql_int.h -Status: Closed +Status: Assigned Type: Bug Package:PDO related Operating System: unix PHP Version:5.3.6 Assigned To:mysql Block user comment: N Private report: N New Comment: I didn't commit the patch yet, I still want to hear from the MySQL guys first. Also it's their domain, not mine. Previous Comments: [2011-05-02 22:32:28] public at grik dot net thanks! I am sorry for the wrong initial description, complaining at # include ext/mysqlnd/mysqlnd.h while the error clearly told about ext/mysql/mysql_mysqlnd.h [2011-05-02 21:20:36] tony2...@php.net There's also another issue: you can't install mysqlnd itself, you have to install one of the extensions using it. So in order to build shared version of PDO_MYSQL with myslnd you have to build ext/mysql with myslnd *statically*. I believe ext/mysqlND should be full-grown extension with its own --enable-mysqlnd option, this was you could build it separately AND still be able to use your automagic with $PHP_MYSQLND_ENABLED. [2011-05-02 21:12:41] tony2...@php.net The problem is quite weird. I guess this line: # include ext/mysql/mysql_mysqlnd.h ..is some kind of leftover from the good ol' times when mysqlnd was a part of ext/mysql/; at least nothing breaks if I remove it. So the patch is as easy as this: --- php_pdo_mysql_int.h (revision 307861) +++ php_pdo_mysql_int.h (working copy) @@ -25,7 +25,6 @@ #if defined(PDO_USE_MYSQLND) # include ext/mysqlnd/mysqlnd.h -# include ext/mysql/mysql_mysqlnd.h # include ext/mysqlnd/mysqlnd_libmysql_compat.h # define PDO_MYSQL_PARAM_BIND MYSQLND_PARAM_BIND #else [2011-05-02 20:19:11] public at grik dot net There is one phpize in the system, and I reinstalled PHP to ensure the error persists. mysqlnd.h exists and is present in the proper folder [root@devel php-5.3.6]# whereis phpize phpize: /usr/local/bin/phpize [root@devel php-5.3.6]# phpize -v Configuring for: PHP Api Version: 20090626 Zend Module Api No: 20090626 Zend Extension Api No: 220090626 [root@devel php-5.3.6]# locate mysqlnd.h /usr/local/include/php/ext/mysqlnd/mysqlnd.h /usr/local/include/php/ext/mysqlnd/php_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysql/mysql_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqli/mysqli_mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/mysqlnd.h /usr/src/web/php-5.3.6/ext/mysqlnd/php_mysqlnd.h [root@devel php-5.3.6]# ll /usr/local/include/php/ext/mysqlnd/mysqlnd.h -rw-r--r-- 1 root root 17088 2011-05-02 20:49 /usr/local/include/php/ext/mysqlnd/mysqlnd.h [root@devel php-5.3.6]# php-config --includes -I/usr/local/include/php -I/usr/local/include/php/main - I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend - I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib [2011-05-02 19:11:42] public at grik dot net Look: # tar -xjf php-5.3.6.tar.bz2 mysqli]# cd php-5.3.6/ext/mysqli/ mysqli]# phpize; ./configure --with-mysqli=mysqlnd; make ... Build complete. Don't forget to run 'make test'. mysqli]# cd ../pdo_mysql/ pdo_mysql]# phpize;./configure --with-pdo-mysql=mysqlnd;make ... In file included from /usr/src/web/php-5.3.6/ext/pdo_mysql/pdo_mysql.c:32: /usr/src/web/php-5.3.6/ext/pdo_mysql/php_pdo_mysql_int.h:28:38: error: ext/mysql/mysql_mysqlnd.h: No such file or directory make: *** [pdo_mysql.lo] Error 1 # php -v PHP 5.3.6 (cli) (built: Apr 30 2011 21:21:49) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies pdo_mysql]# cd ../.. php-5.3.6]# ./configure --with-pdo-mysql=mysqlnd;make Build complete. Don't forget to run 'make test'. What else can I show 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=54644 -- Edit this bug report at http://bugs.php.net/bug.php?id=54644edit=1
Bug #54423 [Opn-Csd]: classes from dl()'ed extensions are not destroyed
Edit report at http://bugs.php.net/bug.php?id=54423edit=1 ID: 54423 Updated by: tony2...@php.net Reported by:tony2...@php.net Summary:classes from dl()'ed extensions are not destroyed -Status: Open +Status: Closed Type: Bug Package:Scripting Engine problem PHP Version:5.3SVN-2011-03-30 (SVN) -Assigned To: +Assigned To:tony2001 Block user comment: N Private report: N New Comment: Patch committed. Previous Comments: [2011-03-30 14:53:55] tony2...@php.net Description: If an extension loaded with dl() declares any clasess, these classes are not destroyed along with the module and it's other resources. That causes crashes when using delayed early binding, though that's not a requirement, see reproduce case below. Test script: --- Reproduce case is quite intricate: start ONE child process of any PHP SAPI (except CLI/CGI/embed, of course) execute this code: ?php dl(extension declaring any internal classes with create_object() handler) $o = new That class; ? then comment out the dl() and execute it again. The class is still present, but it's handler pointers are invalid, therefore PHP will crash with a similar backtrace: Program received signal SIGSEGV, Segmentation fault. 0xb6e17da0 in ?? () (gdb) bt #0 0xb6e17da0 in ?? () #1 0x081cc629 in _object_and_properties_init (arg=0x83deae8, class_type=0x8455380, properties=0x0) at /local/dev/php/PHP_5_3/Zend/zend_API.c:1088 #2 0x081cc730 in _object_init_ex (arg=0x83deae8, class_type=0x8455380) at /local/dev/php/PHP_5_3/Zend/zend_API.c:1096 #3 0x081ee86d in ZEND_NEW_SPEC_HANDLER (execute_data=0x8411d80) at /local/dev/php/PHP_5_3/Zend/zend_vm_execute.h:476 #4 0x081eb4f9 in execute (op_array=0x83dd3f4) at /local/dev/php/PHP_5_3/Zend/zend_vm_execute.h:107 #5 0x081cab82 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /local/dev/php/PHP_5_3/Zend/zend.c:1194 #6 0x08179b90 in php_execute_script (primary_file=0xbfda0cb0) at /local/dev/php/PHP_5_3/main/main.c:2268 #7 0x0825a53d in main (argc=1, argv=0xbfda0e04) at /local/dev/php/PHP_5_3/sapi/fpm/fpm/fpm_main.c:1882 (gdb) f 1 #1 0x081cc629 in _object_and_properties_init (arg=0x83deae8, class_type=0x8455380, properties=0x0) at /local/dev/php/PHP_5_3/Zend/zend_API.c:1088 1088Z_OBJVAL_P(arg) = class_type-create_object(class_type TSRMLS_CC); (gdb) p class_type-create_object $1 = (zend_object_value (*)(zend_class_entry *)) 0xb6e17da0 (gdb) p *class_type-create_object Cannot access memory at address 0xb6e17da0 -- Edit this bug report at http://bugs.php.net/bug.php?id=54423edit=1
Req #34906 [Asn]: mysql: no way to get errno for a failed secondary connection attempt
Edit report at http://bugs.php.net/bug.php?id=34906edit=1
ID: 34906
Updated by: tony2...@php.net
Reported by:feldgendler at mail dot ru
Summary:mysql: no way to get errno for a failed secondary
connection attempt
Status: Assigned
Type: Feature/Change Request
Package:MySQL related
Operating System: *
PHP Version:5CVS-2005-10-19 (cvs)
-Assigned To:georg
+Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
Reassigned to Johannes.
The patch is still available here:
http://dev.daylessday.org/diff/bug34906.diff
Previous Comments:
[2005-10-18 13:51:40] feldgendler at mail dot ru
About the patch: I think it's not enough. Once a connection attempt has
failed, conect_errno will be nonzero, and mysql_errno() without
arguments always will return this value. This will be too much deviation
from the current behavior -- in fact, many always call mysql_errno()
without arguments. Here is a typical script which will be broken:
if (!mysql_connect('dbhost', 'user', 'pass')) {
mysql_connect('backup-dbhost', 'user', 'pass');
}
// ...
if (!mysql_query(...)) {
echo mysql_errno(); // This will print connect_errno!
}
I think that connect_errno should be reset to zero somewhere, but I
don't know where it would be appropriate. mysql_errno() shouldn't reset
connect_errno because mysql_error() and mysql_errno() are expected to be
idempotent.
[2005-10-18 13:43:11] tony2...@php.net
Assigned to the maintainer.
Georg, please check the patch:
http://tony2001.phpclub.net/dev/tmp/bug34906.diff
[2005-10-18 13:19:52] feldgendler at mail dot ru
Description:
This is actually a bug in the well-defined and documented API, so there
is no reproduce code here.
After successfully establishing a connection, when an attempt to create
another connection fails, there is no way to find out the errno. This is
because mysql_errno() always uses an established link, either the one
passed as the argument or the default one. There is just no way to find
out why the second connection failed.
// assume this one succeeds
$first_connection = mysql_connect($host1, $u1, $p1);
// at this point, $first_connection is the default link
// assume this one fails
$second_connection = mysql_connect($host2, $u2, $p2);
// $second_connection is false,
// $first_connection is still the default link
echo mysql_errno();
// 0 is printed because there is no error
// on $first_connection
Before stamping Bogus on this bug, please note the following:
1. I have read the manual about mysql_errno() and mysql_connect(). Every
word of it. Even more, I think that PHP currently behaves as documented.
But it's just wrong because there is no way to find out why a connection
has failed.
2. I have read other bug reports about mysql_errno(). They are actually
about other issues, or they don't state this problem clearly enough, so
I'm filing this bug report to make it clear what the problem is.
3. I have read the source code of the mysql extension. From the source,
I've found out that the error code and message from a failed connection
attempt is really stored in mysql_globals (connect_errno and
connect_error), but mysql_errno() PHP function only returns
MySG(connect_errno) when the function is invoked without arguments AND
there is no default link. If there is a default link, and an attempt to
establish a second one has failed, there isn't a way to have
MySG(connect_errno) returned to the PHP program.
It is not obvious how to fix this bug, because it isn't a deviation from
the documented behavior, but rather an incompleteness of the API. Two of
the possible approaches are proposed here:
http://www.mail-archive.com/internals@lists.php.net/msg02524.html
--
Edit this bug report at http://bugs.php.net/bug.php?id=34906edit=1
Bug #51772 [Fbk]: php-fpm do not support PowerPC processors
Edit report at http://bugs.php.net/bug.php?id=51772edit=1 ID: 51772 Updated by: tony2...@php.net Reported by:vaskes at mail dot ru Summary:php-fpm do not support PowerPC processors Status: Feedback Type: Bug Package:FPM related Operating System: RedHat Ent. server 5.4-ppc64 PHP Version:5.3.2 Assigned To:tony2001 Block user comment: N Private report: N New Comment: Well, I'm more concerned about the stability of the patch, as the original author has already reported that it compiles fine, but is unstable, without going into any details. Previous Comments: [2010-11-26 00:48:34] chris dot tandiono at gmail dot com I can confirm that it compiles properly with the attached patch on 32-bit ppc: [ch...@host ~]$ uname -a Darwin host.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh No idea whether it works completely properly; the machine is very low load. [2010-09-27 14:16:20] tony2...@php.net Any news? [2010-06-23 18:59:23] tony2...@php.net Ok, let me know if you need any help. More info on your problems would be appreciated, of course. [2010-06-17 22:28:42] vaskes at mail dot ru Using http://snaps.php.net/php5.3-201006161230.tar.gz this patch applied successfully and php compiled successfully too. I did some stress testing on this php-fpm and discover that php-fpm working unstable. I will perform some additional test to discover the issue more thoroughly and post results here. [2010-06-09 15:43:28] tony2...@php.net sapi/fpm/fpm/fpm_main.o: In function `main': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1698: undefined reference to `php_output_end_all' No, trunk is not broken =) You're trying to compile FPM from trunk with 5.3.2 while you should be using FPM from PHP_5_3 branch instead. But the easiest way to test it would be to try a snapshot from http://snaps.php.net This way you wouldn't need to manually add FPM to your sources, since FPM is already available in 5.3.3 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/bug.php?id=51772 -- Edit this bug report at http://bugs.php.net/bug.php?id=51772edit=1
Bug #53394 [Opn-Fbk]: ARRAY_AS_PROPS flag is ignored when used with PDOStatement::fetchObject
Edit report at http://bugs.php.net/bug.php?id=53394edit=1
ID: 53394
Updated by: tony2...@php.net
Reported by:public at grik dot net
Summary:ARRAY_AS_PROPS flag is ignored when used with
PDOStatement::fetchObject
-Status: Open
+Status: Feedback
Type: Bug
Package:SPL related
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2010-11-24 13:54:20] crocodile2u at gmail dot com
Or possibly it would be better to change the PDO's behaviour? It seems
very
strange and unnatural that constructor is called after the properties
are set. It
only makes developers write unobvious code for the only purpose of
workaround for
this PDO's feature (personally, I would consider it a bug).
[2010-11-24 13:46:58] public at grik dot net
I was hinted that PDO sets the fields before calling a constructor.
It makes everything clear.
parent::__construct($array,ArrayObject::ARRAY_AS_PROPS);
is called after setting object fields, and they don't get processed by
ArrayObject::offsetSet.
ArrayObject::оffsetGet after changing mode to ARRAY_AS_PROPS doesn't
see the fields set by the PDO hack.
оffsetGet can process existing fields after changing the mode, I
suppose.
[2010-11-24 04:13:05] public at grik dot net
Description:
If the object is created and filled by PDOStatement::fetchObject, the
ArrayObject::ARRAY_AS_PROPS is ignored.
Seems like PDO sets the fields values directly around ArrayObject magic
setters, and breaks the ArrayObject native behaviour.
Test script:
---
class ArraySlice extends ArrayObject{
function __construct(array $array=array()){
parent::__construct($array,ArrayObject::ARRAY_AS_PROPS);
}
}
$PDO = new PDO($dsn, $user, $password);
$a = $PDO-query('select id from links')-fetchObject('ArraySlice');
echo $a-id; //works
echo $a['id'];//Notice occured ... Undefined index: id
Expected result:
value of the id field
Actual result:
--
Notice
--
Edit this bug report at http://bugs.php.net/bug.php?id=53394edit=1
Bug #53394 [Fbk-Asn]: ARRAY_AS_PROPS flag is ignored when used with PDOStatement::fetchObject
Edit report at http://bugs.php.net/bug.php?id=53394edit=1
ID: 53394
Updated by: tony2...@php.net
Reported by:public at grik dot net
Summary:ARRAY_AS_PROPS flag is ignored when used with
PDOStatement::fetchObject
-Status: Feedback
+Status: Assigned
Type: Bug
Package:SPL related
PHP Version:5.3.3
-Assigned To:
+Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
Felipe, could you check this out plz?
Previous Comments:
[2010-11-24 15:25:58] tony2...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-11-24 13:54:20] crocodile2u at gmail dot com
Or possibly it would be better to change the PDO's behaviour? It seems
very
strange and unnatural that constructor is called after the properties
are set. It
only makes developers write unobvious code for the only purpose of
workaround for
this PDO's feature (personally, I would consider it a bug).
[2010-11-24 13:46:58] public at grik dot net
I was hinted that PDO sets the fields before calling a constructor.
It makes everything clear.
parent::__construct($array,ArrayObject::ARRAY_AS_PROPS);
is called after setting object fields, and they don't get processed by
ArrayObject::offsetSet.
ArrayObject::оffsetGet after changing mode to ARRAY_AS_PROPS doesn't
see the fields set by the PDO hack.
оffsetGet can process existing fields after changing the mode, I
suppose.
[2010-11-24 04:13:05] public at grik dot net
Description:
If the object is created and filled by PDOStatement::fetchObject, the
ArrayObject::ARRAY_AS_PROPS is ignored.
Seems like PDO sets the fields values directly around ArrayObject magic
setters, and breaks the ArrayObject native behaviour.
Test script:
---
class ArraySlice extends ArrayObject{
function __construct(array $array=array()){
parent::__construct($array,ArrayObject::ARRAY_AS_PROPS);
}
}
$PDO = new PDO($dsn, $user, $password);
$a = $PDO-query('select id from links')-fetchObject('ArraySlice');
echo $a-id; //works
echo $a['id'];//Notice occured ... Undefined index: id
Expected result:
value of the id field
Actual result:
--
Notice
--
Edit this bug report at http://bugs.php.net/bug.php?id=53394edit=1
Req #30804 [Sus-Csd]: multiple returned lob resource being overwritten
Edit report at http://bugs.php.net/bug.php?id=30804edit=1
ID: 30804
Updated by: tony2...@php.net
Reported by:michael dot caplan at lechateau dot ca
Summary:multiple returned lob resource being overwritten
-Status: Suspended
+Status: Closed
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:OCI8 related
Operating System: RHE 3
PHP Version:5CVS-2005-04-05
-Assigned To:tony2001
+Assigned To:sixd
Block user comment: N
New Comment:
AFAIK this is fixed for a long time already.
Previous Comments:
[2008-07-04 13:35:24] rain_c1 at yahoo dot com
This Bug is also valid for PDO_OCI.
In PDO_OCI there is no load() method for LOBs. So the described
workaround does not work. This makes this bug much more serious than
evaluated until now in the discussion.
[2006-03-21 10:05:41] tony2...@php.net
The problem is that we allocate ONE LOB descriptor, bind it to the
statement and then fetch real data into it.
So there may be multiple resources, but all of them will point to the
same lob descriptor in the end.
I still don't see a decent way to change it, but in the same time I
don't think this is a major problem.
[2006-03-21 04:05:20] ma...@php.net
Well,
echo $row['CLOB_TEXT']-load();
is not exactly the same as
$res[] = $row['CLOB_TEXT'];
In the last one you are assigning the whole object to an element of an
array. This may be the reason it overwrites all the rest.
Try this:
$res[] = $row['CLOB_TEXT']-load();
and the print as
foreach($res as $r) {
echo $r . \r\n;
}
Just my guess.
maxim
[2005-04-06 21:35:25] michael dot caplan at lechateau dot ca
It was a little difficult to test -- php kept on segfaulting with the DB
abstraction lib I normaily use. I tried a new test as follows, but
unfortunately I had the same results:
CREATE TABLE INTRANET.CLOB_TEST
(ID NUMBER NOT NULL ENABLE,
TEXT_TEXT VARCHAR2(500) NOT NULL ENABLE,
CLOB_TEXT CLOB,
PRIMARY KEY (ID)
)
ID TEXT_TEXT CLOB_TEXT
-- - -
1 text1 this is a clob of text1
2 text2 this is a clob of text2
3 text3 this is a clob of text3
4 text4 this is a clob of text4
5 text5 this is a clob of text5
?php
$db = ocinlogon('intranet', 'stidemoron', 'webdev');
$query = 'select
ID,
TEXT_TEXT,
CLOB_TEXT
from
CLOB_TEST';
$stmt = ociparse($db, $query);
ociexecute($stmt);
while (OCIFetchInto ($stmt, $row, OCI_ASSOC)) {
echo $row['ID'] . \r\n;
echo $row['TEXT_TEXT'] . \r\n;
echo $row['CLOB_TEXT']-load() . \r\n;
}
echo 2-\r\n;
$stmt = ociparse($db, $query);
ociexecute($stmt);
$res = array();
while (OCIFetchInto ($stmt, $row, OCI_ASSOC)) {
$res[] = $row['CLOB_TEXT'];
}
foreach($res as $r) {
echo $r-load() . \r\n;
}
?
results:
1
text1
this is a clob of text1
2
text2
this is a clob of text2
3
text3
this is a clob of text3
4
text4
this is a clob of text4
5
text5
this is a clob of text5
2-
this is a clob of text5
this is a clob of text5
this is a clob of text5
this is a clob of text5
this is a clob of text5
[2004-11-16 14:48:26] michael dot caplan at lechateau dot ca
Description:
I'm not 100% sure if this is a bug, or just a 'quirk', but my attempt to
get feedback on this issue on the php db support list was unsuccessful.
So, here I am
I am selecting multiple columns from a table, one being a clob. the
query returns multiple records for the query. The results are all good,
execpt the clob column in certain circumstances.
Normally, with such a db return, I would loop through the results and
grab the clobs one by one. Under 'special' circumstances, I would want
to first loop throught the results and assign the results to a new array
before fetching the clob. This is where things get funky. In this
senario, the last returned record's clob column overwrites all previous
clob columns (all the previous records have there unique data, except
the clob columns which contains the data for the last record across all
previous records).
A working example:
$query = 'select
id,
author,
cdate,
views,
title,
message,
top
from
Bug #40633 [Sus-Opn]: disk_free_space returns a bad result on filesystems with negative free space
Edit report at http://bugs.php.net/bug.php?id=40633edit=1
ID: 40633
Updated by: tony2...@php.net
Reported by:adam-phpbugs at adam dot gs
Summary:disk_free_space returns a bad result on filesystems
with negative free space
-Status: Suspended
+Status: Open
Type: Bug
Package:Filesystem function related
Operating System: FreeBSD
PHP Version:5.2.1
-Assigned To:tony2001
+Assigned To:
Block user comment: N
Previous Comments:
[2009-10-16 04:29:56] perryc at gmail dot com
Remarkably on a completely different machine, version of FreeBSD,
available disk space, etc I get the same return value from
disk_free_space() (albeit with slightly better precision):
Oct 15 2009 21:21:51 disk_free_space(): 3.7778931862952E+22
The reporter's remarks about negative free space are correct.
[2007-04-26 23:18:13] adam-phpbugs at adam dot gs
For some reason I didn't get any notification of stas's message.
this is FreeBSD 6.2-STABLE
pre
struct statvfs {
fsblkcnt_t f_bavail; /* Number of blocks */
fsblkcnt_t f_bfree;
fsblkcnt_t f_blocks;
fsfilcnt_t f_favail; /* Number of files (e.g.,
inodes) */
fsfilcnt_t f_ffree;
fsfilcnt_t f_files;
unsigned long f_bsize;/* Size of blocks counted above
*/
unsigned long f_flag;
unsigned long f_frsize; /* Size of fragments */
unsigned long f_fsid; /* Not meaningful */
unsigned long f_namemax; /* Same as
pathconf(_PC_NAME_MAX) */
};/pre
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/statvfs.h for
cvs/changelog (make sure your looking at 6.2-RELEASE) branch, there may
be differences.
[2007-04-10 20:58:25] s...@php.net
Funny thing is that PHP doesn't use any unsigned numbers on the way - it
translates it directly from system call int64 to double. I guess version
of the system and header file defining struct statvfs would be useful.
[2007-02-26 15:44:08] tony2...@php.net
Please provide an SSH account on a machine where I can reproduce it.
[2007-02-26 13:33:03] adam-phpbugs at adam dot gs
changing OS to FreeBSD
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=40633
--
Edit this bug report at http://bugs.php.net/bug.php?id=40633edit=1
Bug #37111 [Fbk-NoF]: Apache crashes when strftime is called inside user defined session write func
Edit report at http://bugs.php.net/bug.php?id=37111edit=1 ID: 37111 Updated by: tony2...@php.net Reported by:haakonsk at gmail dot com Summary:Apache crashes when strftime is called inside user defined session write func -Status: Feedback +Status: No Feedback Type: Bug Package:Date/time related Operating System: * PHP Version:5.*, 6CVS (2008-11-11) -Assigned To:tony2001 +Assigned To: Block user comment: N Previous Comments: [2010-03-06 22:43:23] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-11-28 01:23:53] j...@php.net Antony, since you could reproduce this (?), can you try this patch: http://pecl.php.net/~jani/patches/bug37111.patch [2008-11-02 12:35:26] j...@php.net Derick, would you mind responding to my comment above? [2008-02-15 00:11:11] j...@php.net Why can't this be fixed by making ext/date the last extension to be unloaded? ie. simply rename config.m4 to config9.m4 :) (dunno how to do it for the windows build..does it have the same method of simple rename?) [2006-07-27 09:27:06] der...@php.net But as we can't just run it at the end... I would say there is a more fundamental problem here... 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=37111 -- Edit this bug report at http://bugs.php.net/bug.php?id=37111edit=1
Bug #52604 [Opn-Bgs]: Serialization of objects with __sleep() and fatal error
Edit report at http://bugs.php.net/bug.php?id=52604edit=1
ID: 52604
Updated by: tony2...@php.net
Reported by:zerspam at mail dot ru
Summary:Serialization of objects with __sleep() and fatal
error
-Status: Open
+Status: Bogus
Type: Bug
Package:Session related
Operating System: irrelevant
PHP Version:Irrelevant
Block user comment: N
New Comment:
However if your class implements Serializable everything works as
expected when there is a fatal error.
Not true.
See this example:
-
set_error_handler('my_error_handler');
session_start();
$a-b();
class myclass implements Serializable
{
private $a= 1;
private $b = 2;
public function serialize()
{
var_dump(serialize);
return serialize(array('a'));
}
public function unserialize($data)
{
var_dump(unserialize);
return unserialize($data);
}
}
function my_error_handler($code, $error, $file = NULL, $line = NULL)
{
throw new ErrorException($error, $code, 0, $file, $line);
}
$obj = new myclass();
$_SESSION['obj'] = $obj;
-
Whether your class implements Serializable or not, serializers are
called on _request shutdown_ which never happens in case of fatal error,
because fatal error means BOOM!, exit.
And to be honest, I don't see anything wrong here.
Your script FAILED with a fatal error, did you expect PHP to ignore it
an go on running?
Previous Comments:
[2010-09-14 04:43:08] isaiah dot derosewilson at kohanaphp dot com
I also have this same problem. I've tested both php 5.2.12 and 5.3.3 and
neither of them correctly serialize the object when there is a fatal
error - the whole object gets serialized when there is a fatal error
instead of just the properties in __sleep(). However if your class
implements Serializable everything works as expected when there is a
fatal error.
[2010-09-05 13:32:43] zerspam at mail dot ru
Well, 3 weeks left and even no comments from dev team?
[2010-08-14 09:40:26] zerspam at mail dot ru
Description:
Seems like __sleep() does not being invoked when fatal error was risen.
Test script:
---
set_error_handler('my_error_handler');
session_start();
$obj = new myclass();
$_SESSION['obj'] = $obj;
$a-b();
class myclass
{
private $a = 1;
private $b = 2;
public function __sleep()
{
return array('a');
}
}
function my_error_handler($code, $error, $file = NULL, $line = NULL)
{
throw new ErrorException($error, $code, 0, $file, $line);
}
Expected result:
Object with only 'a' property in session file
Actual result:
--
Object with 'a' and 'b' properties in session file
--
Edit this bug report at http://bugs.php.net/bug.php?id=52604edit=1
Bug #52501 [Ana]: Misconfigured Sendmail sends PHP-FPM into an infinite loop
Edit report at http://bugs.php.net/bug.php?id=52501edit=1 ID: 52501 Updated by: tony2...@php.net Reported by:marekroman1 at gmail dot com Summary:Misconfigured Sendmail sends PHP-FPM into an infinite loop Status: Analyzed Type: Bug Package:FPM related Operating System: DebianLenny2.6.26-2-openvz-amd64 PHP Version:5.3.3 Assigned To:fat Block user comment: N New Comment: I'd appreciate if you give me some time to test it in my environment. A week or so would be enough, I guess. Previous Comments: [2010-10-09 14:43:20] f...@php.net small bug correction. [2010-10-09 14:43:04] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v8.patch Revision: 1286628184 URL: http://bugs.php.net/patch-display.php?bug=52501patch=fpm-nomorelibevent.v8.patchrevision=1286628184 [2010-10-08 23:18:24] mplomer at gmx dot de I did some general tests with patch.v7 (apachebench with hitting the limits; increasing and decreasing server load; ...) and I could not detect any errors. But I did not do any more detailed tests. [2010-10-06 11:36:35] f...@php.net small bug correction. [2010-10-06 11:36:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-nomorelibevent.v7.patch Revision: 1286357775 URL: http://bugs.php.net/patch-display.php?bug=52501patch=fpm-nomorelibevent.v7.patchrevision=1286357775 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=52501 -- Edit this bug report at http://bugs.php.net/bug.php?id=52501edit=1
Bug #50345 [ReO-Csd]: nanosleep not detected properly on some solaris versions
Edit report at http://bugs.php.net/bug.php?id=50345edit=1 ID: 50345 Updated by: tony2...@php.net Reported by:sle at ocf dot berkeley dot edu Summary:nanosleep not detected properly on some solaris versions -Status: Re-Opened +Status: Closed Type: Bug Package:Compile Failure Operating System: Solaris 10 PHP Version:5.3.1 Assigned To:tony2001 Block user comment: N New Comment: Yep, that was a mistake (typo?) on my side, sorry. Fix committed, thanks a lot. Previous Comments: [2010-10-05 15:43:37] tony2...@php.net Automatic comment from SVN on behalf of tony2001 Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=304088 Log: fix bug #50345 (nanosleep not detected properly on some solaris versions) [2010-10-05 15:27:50] u...@php.net This would fix it, could someone double-check and apply the patch? nixn...@linux-fuxh:~/php/php-src/branches/PHP_5_3 svn diff configure.in Index: configure.in === --- configure.in(Revision 304085) +++ configure.in(Arbeitskopie) @@ -611,7 +611,7 @@ ) dnl Some systems (like OpenSolaris) do not have nanosleep in libc -PHP_CHECK_FUNC(nanosleep, rt) +PHP_CHECK_FUNC_LIB(nanosleep, rt) dnl Check for getaddrinfo, should be a better way, but... dnl Also check for working getaddrinfo [2010-10-04 13:28:13] u...@php.net According to previous bug comments this commit should be reverted: nixn...@linux-fuxh:~/php/php-src/branches/PHP_5_3 svn diff -r297960:297961 Index: configure.in === --- configure.in(Revision 297960) +++ configure.in(Revision 297961) @@ -611,7 +611,7 @@ ) svn log -r297961 r297961 | tony2001 | 2010-04-13 14:41:46 +0200 (Di, 13. Apr 2010) | 2 Zeilen simplify configure check for nanosleep() dnl Some systems (like OpenSolaris) do not have nanosleep in libc -AC_CACHE_CHECK([for nanosleep], ac_cv_func_nanosleep, [PHP_CHECK_FUNC_LIB(nanosleep, rt)]) +PHP_CHECK_FUNC(nanosleep, rt) dnl Check for getaddrinfo, should be a better way, but... dnl Also check for working getaddrinfo Antony, can you shed some light on it? Thanks! [2010-10-04 13:19:32] u...@php.net Manually setting -lrt will fix it, but maybe this could be fixed in the source? This breaks Solaris 8, 9 and 10 builds. Any PHP version since at least 5.3.1 is affected. NAME nanosleep - high resolution sleep SYNOPSIS cc [ flag... ] file... -lrt [ library... ] #include time.h int nanosleep(const struct timespec *rqtp, struct timespec *rmtp); [2010-09-17 19:42:57] svinopas at gmail dot com I am experiencing this issue on Solaris 09/10 SPARC and 5.3.3. Is there fix available yet? 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=50345 -- Edit this bug report at http://bugs.php.net/bug.php?id=50345edit=1
Bug #51772 [Fbk]: php-fpm do not support PowerPC processors
Edit report at http://bugs.php.net/bug.php?id=51772edit=1 ID: 51772 Updated by: tony2...@php.net Reported by:vaskes at mail dot ru Summary:php-fpm do not support PowerPC processors Status: Feedback Type: Bug Package:FPM related Operating System: RedHat Ent. server 5.4-ppc64 PHP Version:5.3.2 Assigned To:tony2001 Block user comment: N New Comment: Any news? Previous Comments: [2010-06-23 18:59:23] tony2...@php.net Ok, let me know if you need any help. More info on your problems would be appreciated, of course. [2010-06-17 22:28:42] vaskes at mail dot ru Using http://snaps.php.net/php5.3-201006161230.tar.gz this patch applied successfully and php compiled successfully too. I did some stress testing on this php-fpm and discover that php-fpm working unstable. I will perform some additional test to discover the issue more thoroughly and post results here. [2010-06-09 15:43:28] tony2...@php.net sapi/fpm/fpm/fpm_main.o: In function `main': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1698: undefined reference to `php_output_end_all' No, trunk is not broken =) You're trying to compile FPM from trunk with 5.3.2 while you should be using FPM from PHP_5_3 branch instead. But the easiest way to test it would be to try a snapshot from http://snaps.php.net This way you wouldn't need to manually add FPM to your sources, since FPM is already available in 5.3.3 snapshots. [2010-06-09 12:17:56] f...@php.net trunk seems to be broken. please try to apply the patch in PHP_5_3 branch instead. [2010-06-09 11:29:52] vaskes at mail dot ru I can provide ssh access to ppc server. 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=51772 -- Edit this bug report at http://bugs.php.net/bug.php?id=51772edit=1
Bug #51772 [Fbk]: php-fpm do not support PowerPC processors
Edit report at http://bugs.php.net/bug.php?id=51772edit=1 ID: 51772 Updated by: tony2...@php.net Reported by: vaskes at mail dot ru Summary: php-fpm do not support PowerPC processors Status: Feedback Type: Bug Package: FPM related Operating System: RedHat Ent. server 5.4-ppc64 PHP Version: 5.3.2 Assigned To: fat New Comment: Ok, let me know if you need any help. More info on your problems would be appreciated, of course. Previous Comments: [2010-06-17 22:28:42] vaskes at mail dot ru Using http://snaps.php.net/php5.3-201006161230.tar.gz this patch applied successfully and php compiled successfully too. I did some stress testing on this php-fpm and discover that php-fpm working unstable. I will perform some additional test to discover the issue more thoroughly and post results here. [2010-06-09 15:43:28] tony2...@php.net sapi/fpm/fpm/fpm_main.o: In function `main': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1698: undefined reference to `php_output_end_all' No, trunk is not broken =) You're trying to compile FPM from trunk with 5.3.2 while you should be using FPM from PHP_5_3 branch instead. But the easiest way to test it would be to try a snapshot from http://snaps.php.net This way you wouldn't need to manually add FPM to your sources, since FPM is already available in 5.3.3 snapshots. [2010-06-09 12:17:56] f...@php.net trunk seems to be broken. please try to apply the patch in PHP_5_3 branch instead. [2010-06-09 11:29:52] vaskes at mail dot ru I can provide ssh access to ppc server. [2010-06-09 11:29:09] vaskes at mail dot ru After applying this patch i got following error: sapi/fpm/fpm/fpm_main.o: In function `main': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1698: undefined reference to `php_output_end_all' /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1699: undefined reference to `php_output_deactivate' /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1639: undefined reference to `php_output_end_all' /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1640: undefined reference to `php_output_deactivate' sapi/fpm/fpm/fpm_main.o: In function `zif_fastcgi_finish_request': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1496: undefined reference to `php_output_end_all' collect2: ld returned 1 exit status make: *** [sapi/fpm/php-fpm] Error 1 [r...@headnode php-5.3.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/bug.php?id=51772 -- Edit this bug report at http://bugs.php.net/bug.php?id=51772edit=1
Bug #52142 [Opn-Asn]: using diff change the datetime object
Edit report at http://bugs.php.net/bug.php?id=52142edit=1
ID: 52142
Updated by: tony2...@php.net
Reported by: riccardo at mercuriosistemi dot com
Summary: using diff change the datetime object
-Status: Open
+Status: Assigned
Type: Bug
Package: Date/time related
Operating System: slackware
PHP Version: 5.3.2
-Assigned To:
+Assigned To: derick
Previous Comments:
[2010-06-22 12:40:46] riccardo at mercuriosistemi dot com
Description:
A DateTime object with timezone_type=1 is always set to timezone=+00:00
after the use of diff
Test script:
---
date_default_timezone_set( Europe/Rome );
$da = new DateTime('2010-06-22T00:00:00+02:00');
$a = new DateTime('2010/06/23');
print_r($da);
$da-diff($a);
// $da has been changed
print_r($da);
Expected result:
DateTime Object
(
[date] = 2010-06-22 00:00:00
[timezone_type] = 1
[timezone] = +02:00
)
DateTime Object
(
[date] = 2010-06-21 22:00:00
[timezone_type] = 1
[timezone] = +02:00
)
Actual result:
--
DateTime Object
(
[date] = 2010-06-22 00:00:00
[timezone_type] = 1
[timezone] = +02:00
)
DateTime Object
(
[date] = 2010-06-21 22:00:00
[timezone_type] = 1
[timezone] = +00:00
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52142edit=1
Req #49707 [Asn-Csd]: Add FPM SAPI Support
Edit report at http://bugs.php.net/bug.php?id=49707edit=1 ID: 49707 Updated by: tony2...@php.net Reported by: dreamcat4 at gmail dot com Summary: Add FPM SAPI Support -Status: Assigned +Status: Closed Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: * PHP Version: 5.3 Assigned To: tony2001 New Comment: FPM has been added to PHP_5_3 and trunk. Previous Comments: [2009-12-03 11:01:59] tony2...@php.net Reassigning to myself. See new branch in SVN: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_FPM [2009-11-14 21:58:57] dreamc...@php.net Hi, the latest version of php-fpm is now revision 103. I'm assigning to johannes so hopefully we can get some kind of feedback / re-assignment / prioritization. Download link: https://launchpad.net/php-fpm/+download [2009-10-12 12:59:50] dreamcat4 at gmail dot com Bug isn't showing up in Summary Report. Updated target version - 5.3.0 [2009-10-02 13:09:46] admin at yqed dot com I would be interested to see this implemented. I will forward this link to Scott MacVicar also. [2009-09-29 10:45:20] dreamcat4 at gmail dot com Updated target version - 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/bug.php?id=49707 -- Edit this bug report at http://bugs.php.net/bug.php?id=49707edit=1
Bug #52050 [Asn-Fbk]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050edit=1 ID: 52050 Updated by: tony2...@php.net Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload -Status: Assigned +Status: Feedback Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 Assigned To: fat New Comment: Please also show the output of `ldd /path/to/php-fpm`. Thanks. Previous Comments: [2010-06-11 15:36:27] marcus at adolfsson dot com This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Your system will tell you anyway :) ; Start a new pool named 'www'. [www] ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port'- to listen on a TCP socket to a specific address on ;a specific port; ; 'port' - to listen on a TCP socket to all addresses on a ;specific port; ; '/path/to/unix/socket' - to listen on a unix socket. ; Note: This value is mandatory. listen = 127.0.0.1:9000 ; Set listen(2) backlog. A value of '-1' means unlimited. ; Default Value: -1 listen.backlog = -1 ; List of ipv4 addresses of FastCGI clients which are allowed to connect. ; Equivalent to the FCGI_WEB_SERVER_ADDRS environment variable in the original ; PHP FCGI (5.2.2+). Makes sense only with a tcp listening socket. Each address ; must be separated by a comma. If this value is left blank, connections will be ; accepted from any ip address. ; Default Value: any ;listen.allowed_clients = 127.0.0.1 ; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0666 ;listen.owner = nobody ;listen.group = nobody ;listen.mode = 0666 ; Unix user/group of processes ; Note: The user is mandatory. If the group is not set, the default user's group ; will be used. user = phpfm group = phpfm ; Choose how the process manager will control the number of child processes. ; Possible Values: ; static - a fixed number (pm.max_children) of child processes; ; dynamic - the number of child processes are set dynamically based on the ; following directives: ; pm.max_children - the maximum number of children that can ;be alive at the same time. ; pm.start_servers - the number of children created on startup. ; pm.min_spare_servers - the minimum number of children in 'idle' ;state (waiting to process). If the number ;of 'idle' processes is less than this ;number then some children will be created. ; pm.max_spare_servers - the maximum number of children in 'idle' ;state (waiting to process). If the number ;of 'idle' processes is greater than this ;number then some children will be killed. ; Note: This value
Bug #51772 [Ana]: php-fpm do not support PowerPC processors
Edit report at http://bugs.php.net/bug.php?id=51772edit=1 ID: 51772 Updated by: tony2...@php.net Reported by: vaskes at mail dot ru Summary: php-fpm do not support PowerPC processors Status: Analyzed Type: Bug Package: FPM related Operating System: RedHat Ent. server 5.4-ppc64 PHP Version: 5.3.2 Assigned To: fat New Comment: sapi/fpm/fpm/fpm_main.o: In function `main': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1698: undefined reference to `php_output_end_all' No, trunk is not broken =) You're trying to compile FPM from trunk with 5.3.2 while you should be using FPM from PHP_5_3 branch instead. But the easiest way to test it would be to try a snapshot from http://snaps.php.net This way you wouldn't need to manually add FPM to your sources, since FPM is already available in 5.3.3 snapshots. Previous Comments: [2010-06-09 12:17:56] f...@php.net trunk seems to be broken. please try to apply the patch in PHP_5_3 branch instead. [2010-06-09 11:29:52] vaskes at mail dot ru I can provide ssh access to ppc server. [2010-06-09 11:29:09] vaskes at mail dot ru After applying this patch i got following error: sapi/fpm/fpm/fpm_main.o: In function `main': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1698: undefined reference to `php_output_end_all' /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1699: undefined reference to `php_output_deactivate' /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1639: undefined reference to `php_output_end_all' /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1640: undefined reference to `php_output_deactivate' sapi/fpm/fpm/fpm_main.o: In function `zif_fastcgi_finish_request': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1496: undefined reference to `php_output_end_all' collect2: ld returned 1 exit status make: *** [sapi/fpm/php-fpm] Error 1 [r...@headnode php-5.3.2]# [2010-06-08 11:46:13] tony2...@php.net Please try the patch attached. [2010-06-08 11:45:48] tony2...@php.net The following patch has been added/updated: Patch Name: ppc-support Revision: 1275990348 URL: http://bugs.php.net/patch-display.php?bug=51772patch=ppc-supportrevision=1275990348 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=51772 -- Edit this bug report at http://bugs.php.net/bug.php?id=51772edit=1
Bug #51772 [Ana-Fbk]: php-fpm do not support PowerPC processors
Edit report at http://bugs.php.net/bug.php?id=51772edit=1 ID: 51772 Updated by: tony2...@php.net Reported by: vaskes at mail dot ru Summary: php-fpm do not support PowerPC processors -Status: Analyzed +Status: Feedback Type: Bug Package: FPM related Operating System: RedHat Ent. server 5.4-ppc64 PHP Version: 5.3.2 Assigned To: fat Previous Comments: [2010-06-09 15:43:28] tony2...@php.net sapi/fpm/fpm/fpm_main.o: In function `main': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1698: undefined reference to `php_output_end_all' No, trunk is not broken =) You're trying to compile FPM from trunk with 5.3.2 while you should be using FPM from PHP_5_3 branch instead. But the easiest way to test it would be to try a snapshot from http://snaps.php.net This way you wouldn't need to manually add FPM to your sources, since FPM is already available in 5.3.3 snapshots. [2010-06-09 12:17:56] f...@php.net trunk seems to be broken. please try to apply the patch in PHP_5_3 branch instead. [2010-06-09 11:29:52] vaskes at mail dot ru I can provide ssh access to ppc server. [2010-06-09 11:29:09] vaskes at mail dot ru After applying this patch i got following error: sapi/fpm/fpm/fpm_main.o: In function `main': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1698: undefined reference to `php_output_end_all' /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1699: undefined reference to `php_output_deactivate' /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1639: undefined reference to `php_output_end_all' /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1640: undefined reference to `php_output_deactivate' sapi/fpm/fpm/fpm_main.o: In function `zif_fastcgi_finish_request': /home/php-5.3.2/sapi/fpm/fpm/fpm_main.c:1496: undefined reference to `php_output_end_all' collect2: ld returned 1 exit status make: *** [sapi/fpm/php-fpm] Error 1 [r...@headnode php-5.3.2]# [2010-06-08 11:46:13] tony2...@php.net Please try the patch attached. 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=51772 -- Edit this bug report at http://bugs.php.net/bug.php?id=51772edit=1
Bug #52032 [Asn-Fbk]: segmentation fault
Edit report at http://bugs.php.net/bug.php?id=52032edit=1
ID: 52032
Updated by: tony2...@php.net
Reported by: slogster at gmail dot com
Summary: segmentation fault
-Status: Assigned
+Status: Feedback
Type: Bug
Package: FPM related
Operating System: linux x86_64
PHP Version: 5.3SVN-2010-06-09 (SVN)
Assigned To: fat
Previous Comments:
[2010-06-09 15:42:41] f...@php.net
Please provide :
- your conf file
- compilation options
- the request which makes FPM to crash
[2010-06-09 15:36:19] slogster at gmail dot com
I am running php-fpm:
URL: http://svn.php.net/repository/php/php-src/branches/PHP_5_3
Revision: 299968
[2010-06-09 15:35:00] slogster at gmail dot com
Description:
Core was generated by `/usr/local/php-5.3-r299968/sbin/php-fpm'.
Program terminated with signal 11, Segmentation fault.
[New process 11882]
#0 0x55955aab in _zend_is_inconsistent (ht=0x5500,
file=0x55ccf738 /home/l3et3r/php-5.3-r299968/Zend/zend_hash.c,
line=517)
at /home/l3et3r/php-5.3-r299968/Zend/zend_hash.c:53
53 if (ht-inconsistent==HT_OK) {
(gdb) bt
#0 0x55955aab in _zend_is_inconsistent (ht=0x5500,
file=0x55ccf738 /home/l3et3r/php-5.3-r299968/Zend/zend_hash.c,
line=517)
at /home/l3et3r/php-5.3-r299968/Zend/zend_hash.c:53
#1 0x55957821 in zend_hash_destroy (ht=0x5500) at
/home/l3et3r/php-5.3-r299968/Zend/zend_hash.c:517
#2 0x55a334d7 in fcgi_close (req=0x7fff64fee540, force=0,
destroy=1)
at /home/l3et3r/php-5.3-r299968/sapi/fpm/fpm/fastcgi.c:675
#3 0x55a33de4 in fcgi_finish_request (req=0x7fff64fee540,
force_close=0)
at /home/l3et3r/php-5.3-r299968/sapi/fpm/fpm/fastcgi.c:1000
#4 0x55a395b5 in sapi_cgi_deactivate () at
/home/l3et3r/php-5.3-r299968/sapi/fpm/fpm/fpm_main.c:881
#5 0x558d62f6 in sapi_deactivate () at
/home/l3et3r/php-5.3-r299968/main/SAPI.c:444
#6 0x558ca34d in php_request_shutdown (dummy=0x0) at
/home/l3et3r/php-5.3-r299968/main/main.c:1642
#7 0x55a3b5d3 in main (argc=1, argv=0x7fff64ff0788)
at /home/l3et3r/php-5.3-r299968/sapi/fpm/fpm/fpm_main.c:1881
(gdb) frame 7
#7 0x55a3b5d3 in main (argc=1, argv=0x7fff64ff0788)
at /home/l3et3r/php-5.3-r299968/sapi/fpm/fpm/fpm_main.c:1881
1881php_request_shutdown((void *) 0);
(gdb) frame 6
#6 0x558ca34d in php_request_shutdown (dummy=0x0) at
/home/l3et3r/php-5.3-r299968/main/main.c:1642
1642sapi_deactivate(TSRMLS_C);
(gdb) frame 5
#5 0x558d62f6 in sapi_deactivate () at
/home/l3et3r/php-5.3-r299968/main/SAPI.c:444
444 sapi_module.deactivate(TSRMLS_C);
(gdb) frame 4
#4 0x55a395b5 in sapi_cgi_deactivate () at
/home/l3et3r/php-5.3-r299968/sapi/fpm/fpm/fpm_main.c:881
881 if (
(gdb) frame 3
#3 0x55a33de4 in fcgi_finish_request (req=0x7fff64fee540,
force_close=0)
at /home/l3et3r/php-5.3-r299968/sapi/fpm/fpm/fastcgi.c:1000
1000fcgi_close(req, force_close, 1);
(gdb) frame 2
#2 0x55a334d7 in fcgi_close (req=0x7fff64fee540, force=0,
destroy=1)
at /home/l3et3r/php-5.3-r299968/sapi/fpm/fpm/fastcgi.c:675
675 zend_hash_destroy(req-env);
(gdb) frame 1
#1 0x55957821 in zend_hash_destroy (ht=0x5500) at
/home/l3et3r/php-5.3-r299968/Zend/zend_hash.c:517
517 IS_CONSISTENT(ht);
(gdb) frame 0
#0 0x55955aab in _zend_is_inconsistent (ht=0x5500,
file=0x55ccf738 /home/l3et3r/php-5.3-r299968/Zend/zend_hash.c,
line=517)
at /home/l3et3r/php-5.3-r299968/Zend/zend_hash.c:53
53 if (ht-inconsistent==HT_OK) {
--
Edit this bug report at http://bugs.php.net/bug.php?id=52032edit=1
Bug #51983 [Asn]: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1
Edit report at http://bugs.php.net/bug.php?id=51983edit=1 ID: 51983 Updated by: tony2...@php.net Reported by: konstantin at symbi dot org Summary: [fpm sapi] pm.status_path not working when cgi.fix_pathinfo=1 Status: Assigned Type: Bug Package: FPM related Operating System: Any PHP Version: 5.3SVN-2010-06-03 (snap) Assigned To: fat New Comment: Jerome, I agree that we should drop this fix_pathinfo stuff - it makes no sense to adopt all the freaky things from CGI API. The patch requires some extensive testing, though, that's clear. But I don't think we should keep in mind of all the web-servers you mentioned. Apache, nginx lightty are my biggest concern, others can be safely dropped (or assumed working). You can forget about IIS anyway, FPM doesn't support Windows. Previous Comments: [2010-06-04 09:07:10] konstantin at symbi dot org And of course I never say we should do anything with the CGI/FCGI sapi. I am sure its implementation must not be chanhed 'cause it was tested with many webservers during years. I am speaking only about FPM sapi which is much more specific. [2010-06-04 09:04:54] konstantin at symbi dot org FPM sapi implements remote fastcgi only (also known as external FastCGI). So it is limited to web servers which support it. I have tested Nginx, Lighttpd, and Apache mod_fastcgi. For other webservers listed, are there ones which of them support remote fastcgi? At least I am sure that IIS does not (even with its latest fastcgi implementations, I've asked this question on IIS FastCGI forums). As far as I know, thttpd does not, too. [2010-06-04 08:59:23] f...@php.net I'm asking about Apache, to be certain not to ban some webservers from using FPM. According to http://www.fastcgi.com/drupal/node/3, we have to make sure that FPM is compliant with all of the following webservers: Apache Microsoft IIS Microsoft IIS (second generation) SunOne Lighttpd Premium thttpd http MyServer Pi3Web WebSTAR (Mac OS) Nginx Cherokee [2010-06-04 08:52:49] konstantin at symbi dot org 99% of fpm installations are with nginx or lighty, using fpm sapi with non-FSM webservers is at least very strange. But I have just checked it with Apache+mod_fastcgi in a simplest configuration: DocumentRoot /var/www FastCgiExternalServer /var/www -socket /tmp/php-fpm.sock Directory /var/www Options FollowSymLinks +ExecCGI AllowOverride All Order Allow,Deny Allow from all /Directory and it works OK. The patch contains comments in the top of the new init_request_info() implementation. It describes why fastcgi parameters are mapped to the script filename in this way, and it was chosen after examining CGI specs, typical fpm configurations, and common sense. BTW, those webservers like old IIS versions with buggy cgi implementations which required that awkward way of guessing what they meant, for which the original implementation of init_request_info() was designed, do not support remote FastCGI at all. [2010-06-04 08:25:19] f...@php.net Have you tried your patch with other webservers than nginx and lighttpd ? 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=51983 -- Edit this bug report at http://bugs.php.net/bug.php?id=51983edit=1
Bug #52001 [Opn-Asn]: Memory allocation problems after using variable variables
Edit report at http://bugs.php.net/bug.php?id=52001edit=1
ID: 52001
Updated by: tony2...@php.net
Reported by: lisio at bk dot ru
Summary: Memory allocation problems after using variable
variables
-Status: Open
+Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Linux
PHP Version: 5.3.2
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2010-06-06 19:15:45] boldin dot pavel at gmail dot com
Zend/zend_compile.c 1066:
if (opline type == BP_VAR_W arg_offset) {
opline-extended_value = ZEND_FETCH_MAKE_REF;
}
Is not this bug too? ZEND_FETCH_MAKE_REF is not set for first
(arg_offset == 0) arg?
[2010-06-06 19:06:29] boldin dot pavel at gmail dot com
I have attached patch. It must be reviewed by professional PHP
developer.
For me it is clearly that call of SEPARATE_ZVAL_TO_MAKE_IS_REF must be
predicated with such a check (and it is done in all other cases).
[2010-06-06 18:38:05] boldin dot pavel at gmail dot com
Finally: bug is at
if (opline-extended_value ZEND_FETCH_MAKE_REF) {
SEPARATE_ZVAL_TO_MAKE_IS_REF(retval);
}
SEPARATE_ZVAL_TO_MAKE_IS_REF seems to ruine *retval (which is
executor_globals.uninitialized_ptr). Then this leads to incorrectly
working zend_send_by_var_helper and incorrect referencing count in
zend_assign_to_variable.
Trying to patch now.
[2010-06-06 18:08:56] boldin dot pavel at gmail dot com
Version without bug:
(gdb)
zend_send_by_var_helper_SPEC_VAR (execute_data=0x88a28d0)
at /home/davinchi/php-5.3.2/Zend/zend_vm_execute.h:8257
8257varptr = _get_zval_ptr_var(opline-op1, EX(Ts),
free_op1 TSRMLS_CC);
(gdb)
8259if (varptr == EG(uninitialized_zval)) {
(gdb) p varptr
$24 = (zval *) 0x877fd04
(gdb) p executor_globals.uninitialized_zval
$25 = (zval *) 0x877fd04
(gdb) p executor_globals.uninitialized_zval_ptr
$26 = (zval *) 0x877fd04
And version with bug:
zend_send_by_var_helper_SPEC_VAR (execute_data=0x88a28d0)
at /home/davinchi/php-5.3.2/Zend/zend_vm_execute.h:8254
8254zend_op *opline = EX(opline);
(gdb)
8257varptr = _get_zval_ptr_var(opline-op1, EX(Ts),
free_op1 TSRMLS_CC);
(gdb) n
8259if (varptr == EG(uninitialized_zval)) {
(gdb) p varptr
$27 = (zval *) 0x8876d8c
(gdb) p executor_globals.uninitialized_zval
$28 = (zval *) 0x877fd04
(gdb) p executor_globals.uninitialized_zval_ptr
$29 = (zval *) 0x8876d8c
See that uninitialized_zval_ptr dont pointers to the uninitialized_zval
at all!
[2010-06-06 11:23:47] boldin dot pavel at gmail dot com
Here is the problem: Zend/zend_execution.c line 703 (version 5.3.2):
incorrect reference count (== 1) in case of bug. Should be == 3 and copy
data in 'else' branch.
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=52001
--
Edit this bug report at http://bugs.php.net/bug.php?id=52001edit=1
Bug #51772 [Ana]: php-fpm do not support PowerPC processors
Edit report at http://bugs.php.net/bug.php?id=51772edit=1 ID: 51772 Updated by: tony2...@php.net Reported by: vaskes at mail dot ru Summary: php-fpm do not support PowerPC processors Status: Analyzed Type: Bug Package: FPM related Operating System: RedHat Ent. server 5.4-ppc64 PHP Version: 5.3.2 Assigned To: fat New Comment: Please try the patch attached. Previous Comments: [2010-06-08 11:45:48] tony2...@php.net The following patch has been added/updated: Patch Name: ppc-support Revision: 1275990348 URL: http://bugs.php.net/patch-display.php?bug=51772patch=ppc-supportrevision=1275990348 [2010-06-08 01:13:06] f...@php.net I don't have a powerpc to test. I'll get some code from nginx. Do you have time to test it ? [2010-06-07 11:44:26] vaskes at mail dot ru changed package to FPM related [2010-05-08 15:44:04] vaskes at mail dot ru Description: PHP-FPM sapi do not support PowerPC processor. Build server IBM JS20 bladeserver [r...@headnode ~]# uname -a Linux headnode.tst.local 2.6.18-194.el5 #1 SMP Tue Mar 16 22:03:12 EDT 2010 ppc64 ppc64 ppc64 GNU/Linux Test script: --- svn co http://svn.php.net/repository/php/php-src/trunk/sapi/fpm sapi/fpm ./buildconf --force ./configure --prefix=/opt/php --enable-fpm --build=powerpc-redhat-linux-gnu --host=powerpc-redhat-linux-gnu --target=ppc-redhat-linux-gnu make make install Expected result: Successfull compilation and php-fpm working Actual result: -- /bin/sh /home/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile cc -I/home/php-5.3.2/sapi/fpm -Isapi/fpm/ -I/home/php-5.3.2/sapi/fpm/ -DPHP_ATOM_INC -I/home/php-5.3.2/include -I/home/php-5.3.2/main -I/home/php-5.3.2 -I/home/php-5.3.2/ext/date/lib -I/home/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/home/php-5.3.2/ext/sqlite3/libsqlite -I/home/php-5.3.2/TSRM -I/home/php-5.3.2/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /home/php-5.3.2/sapi/fpm/fpm/fastcgi.c -o sapi/fpm/fpm/fastcgi.lo /bin/sh /home/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile cc -I/home/php-5.3.2/sapi/fpm -Isapi/fpm/ -I/home/php-5.3.2/sapi/fpm/ -DPHP_ATOM_INC -I/home/php-5.3.2/include -I/home/php-5.3.2/main -I/home/php-5.3.2 -I/home/php-5.3.2/ext/date/lib -I/home/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/home/php-5.3.2/ext/sqlite3/libsqlite -I/home/php-5.3.2/TSRM -I/home/php-5.3.2/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /home/php-5.3.2/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo /bin/sh /home/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile cc -I/home/php-5.3.2/sapi/fpm -Isapi/fpm/ -I/home/php-5.3.2/sapi/fpm/ -DPHP_ATOM_INC -I/home/php-5.3.2/include -I/home/php-5.3.2/main -I/home/php-5.3.2 -I/home/php-5.3.2/ext/date/lib -I/home/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/home/php-5.3.2/ext/sqlite3/libsqlite -I/home/php-5.3.2/TSRM -I/home/php-5.3.2/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c -o sapi/fpm/fpm/fpm_children.lo In file included from /home/php-5.3.2/sapi/fpm/fpm/fpm_shm_slots.h:8, from /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c:28: /home/php-5.3.2/sapi/fpm/fpm/fpm_atomic.h:124:2: error: #error unsupported processor. please write a patch and send it to me In file included from /home/php-5.3.2/sapi/fpm/fpm/fpm_shm_slots.h:8, from /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c:28: /home/php-5.3.2/sapi/fpm/fpm/fpm_atomic.h:128: error: expected Ðââ¤)Ðâ⥠before Ðââ¤*Ðâ⥠token In file included from /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c:28: /home/php-5.3.2/sapi/fpm/fpm/fpm_shm_slots.h:16: error: expected specifier-qualifier-list before Ðââ¤atomic_tÐâ⥠make: *** [sapi/fpm/fpm/fpm_children.lo] Error 1 /bin/sh /home/php-5.3.2/libtool --silent --preserve-dup-deps --mode=compile cc -I/home/php-5.3.2/sapi/fpm -Isapi/fpm/ -I/home/php-5.3.2/sapi/fpm/ -DPHP_ATOM_INC -I/home/php-5.3.2/include -I/home/php-5.3.2/main -I/home/php-5.3.2 -I/home/php-5.3.2/ext/date/lib -I/home/php-5.3.2/ext/ereg/regex -I/usr/include/libxml2 -I/home/php-5.3.2/ext/sqlite3/libsqlite -I/home/php-5.3.2/TSRM -I/home/php-5.3.2/Zend-I/usr/include -g -O2 -fvisibility=hidden -c /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c -o sapi/fpm/fpm/fpm_children.lo In file included from /home/php-5.3.2/sapi/fpm/fpm/fpm_shm_slots.h:8, from /home/php-5.3.2/sapi/fpm/fpm/fpm_children.c:28: /home/php-5.3.2/sapi/fpm/fpm/fpm_atomic.h:124:2: error: #error unsupported processor. please write a patch and send it
Bug #51945 [Opn-Asn]: Symlink() Fails On DFS Shares
Edit report at http://bugs.php.net/bug.php?id=51945edit=1 ID: 51945 Updated by: tony2...@php.net Reported by: v-sumada at microsoft dot com Summary: Symlink() Fails On DFS Shares -Status: Open +Status: Assigned Type: Bug Package: Filesystem function related Operating System: windows 2008, 2008R2,2003 PHP Version: 5.3.2 -Assigned To: +Assigned To: pajoye Previous Comments: [2010-05-28 19:20:01] v-sumada at microsoft dot com Description: We have a DFS Standalone namespace created at the 2008 Server with a new folder which has been given a target as remote share .We are trying to create a symlink in this remote Share from 2008R2 Server for a directory and as well as File and Both the cases Fail.The Expected result is failure in creating the symlink using symlink(). The processs Montior show with the result of Name Not Found in creating a symlink. Test script: --- ?php $path ='winhost-name\\namespace\\folder\\'; $dir_name = symlinkdir; $symlink_name = symlinktodir; var_dump(mkdir($dir_name,0777,true)); var_dump(symlink($dir_name,symlink_name)); ? Expected result: bool(true) bool(true) Actual result: -- bool(true) bool(false) -- Edit this bug report at http://bugs.php.net/bug.php?id=51945edit=1
Bug #51944 [Opn-Asn]: One-way SOAP requests are not sent, and no error is reported
Edit report at http://bugs.php.net/bug.php?id=51944edit=1
ID: 51944
Updated by: tony2...@php.net
Reported by: scottij at arbor dot net
Summary: One-way SOAP requests are not sent, and no error is
reported
-Status: Open
+Status: Assigned
Type: Bug
Package: SOAP related
Operating System: Mac OS X 10.5.8
PHP Version: 5.3.2
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2010-05-28 18:38:48] scottij at arbor dot net
Description:
One-way soap requests appear to fail silently. A one-way soap request
is a request which only defines an input message, and has no output
message. When making such a soap request, the request is never sent but
no errors are generated. The call just returns.
My php configure line was:
./configure --with-curl --enable-exif --enable-soap --with-snmp
--with-openssl
Here is a sample WSDL entry that fails:
definitions name=TestSoap
targetNamespace=urn:TestSoap
xmlns:tns=urn:TestSoap
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns=http://schemas.xmlsoap.org/wsdl/;
message name=OneWayRequest
part name=oneArg type=xsd:string/
/message
portType name=TestSoapPort
operation name=OneWay
input message=OneWayRequest/
/operation
/portType
binding name=TestSoapBinding type=tns:TestSoapPort
operation name=OneWay
soap:operation soapAction=urn:TestSoapAction/
input
soap:body use=encoded
namespace=urn:TestSoap
encodingStyle=http://schemas.xmlsoap.org/soap/encoding//
/input
/operation
/binding
service name=TestSoapService
port name=TestSoapPort binding=tns:TestSoapBinding
soap:address location=https://127.0.0.1/soap/
/port
/service
/definitions
Test script:
---
/* Using the above WSDL */
$user = 'someuser';
$password = 'password';
$client = new
SoapClient($wsdl, array(
location = https://127.0.0.1/soap;,
login = $user,
password = $password,
trace = 1,
exceptions = 0,
authentication = SOAP_AUTHENTICATION_DIGEST
)
);
$result = $client-OneWay('foo');
if(is_soap_fault($result)) {
print SOAP Fault: (faultcode: ($result-faultcode), .
faultstring: ($result-faultstring))\n;
} else {
print_r($result);
}
exit;
Expected result:
The script should open a connection to the specified soap server and
send a request to call the OneWay function. This does not happen.
Actual result:
--
Fails silently -- no error, no backtrace, and no output.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51944edit=1
Bug #52015 [Opn-Asn]: Ending date is ignored while iterating DatePeriod
Edit report at http://bugs.php.net/bug.php?id=52015edit=1
ID: 52015
Updated by: tony2...@php.net
Reported by: ko dot fivestar at gmail dot com
Summary: Ending date is ignored while iterating DatePeriod
-Status: Open
+Status: Assigned
Type: Bug
Package: Date/time related
Operating System: Ubuntu 10.04
PHP Version: 5.3.2
-Assigned To:
+Assigned To: derick
Previous Comments:
[2010-06-07 16:03:49] degeb...@php.net
The following patch has been added/updated:
Patch Name: php_bug52015.diff
Revision: 1275919428
URL:
http://bugs.php.net/patch-display.php?bug=52015patch=php_bug52015.diffrevision=1275919428
[2010-06-07 16:03:44] degeb...@php.net
Whether or not it's a bug is debatable. It could be considered a
half-open interval (which would then make it a documentation issue).
Changing it to a closed interval would break backwards compatibility. It
would probably be better adding one more option to DatePeriod that
allows the inclusion of the end date. The attached patch implements
that.
[2010-06-07 13:56:17] ko dot fivestar at gmail dot com
Description:
When passing DateTime objects to first and third argument of DatePeriod
constructor, the specified date on the third argument is not being
interated when both DateTime object contains same time value.
After looking through ext/date/php_date.c, date_period_it_has_more()
function (line 1831) had following code:
---
return object-start-sse object-end-sse ? SUCCESS : FAILURE;
---
While the operator is currently used to compare values, operator
= is more appropriate for this content.
Test script:
---
$period = new \DatePeriod(
new \DateTime('2010-06-01'),
new \DateInterval('P1D'),
new \DateTime('2010-06-03')
);
foreach ($period as $day) {
echo $day-format('Y-m-d') . \n;
}
Expected result:
2010-06-01
2010-06-02
2010-06-03
Actual result:
--
2010-06-01
2010-06-02
--
Edit this bug report at http://bugs.php.net/bug.php?id=52015edit=1
Bug #51940 [Opn-Bgs]: [notice] child pid 7335 exit signal Segmentation fault (11)
Edit report at http://bugs.php.net/bug.php?id=51940edit=1 ID: 51940 Updated by: tony2...@php.net Reported by: levuhoang at yahoo dot com Summary: [notice] child pid 7335 exit signal Segmentation fault (11) -Status: Open +Status: Bogus Type: Bug Package: Reproducible crash Operating System: Centos 5.2 PHP Version: 5.2.13 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. The backtrace clearly shows it has nothing to do with PHP. Previous Comments: [2010-06-02 06:23:22] levuhoang at yahoo dot com It seems the problem is libapr-1.so.0.3.0 and later. If I use libapr-1.so.0.2.7, it's fine. Otherwise, openssl_pkcs7_sign does not work. [2010-05-28 06:36:26] levuhoang at yahoo dot com Description: Apache child process is killed when using openssl_pkcs7_sign I tried the snapshot PHP version (5.2dev) but not solve the problem. Apache: 2.2.15 OpenSSL: 1.0 PHP: 5.2.13/5.2dev OS: Centos 5.2 PHP Module: mod_security Test script: --- http://pastebin.com/vhjKtRJm Expected result: signed file must created. Actual result: -- Compile directives: ./configure \ --with-apxs2=/opt/apache2/bin/apxs \ --with-mysql \ --prefix=/opt/apache2/php \ --with-config-file-path=/opt/apache2/php \ --enable-force-cgi-redirect \ --disable-cgi \ --with-zlib \ --with-gettext \ --with-gdbm \ --enable-soap \ --with-pear \ --with-libxml-dir \ --with-ncurses \ --enable-gd-jis-conv \ --enable-gd-native-ttf \ --enable-mbstring \ --with-gd \ --with-freetype-dir=/usr/include/freetype2 \ --enable-gd-native-ttf \ --enable-shared \ --with-jpeg-dir \ --with-xpm-dir \ --enable-sockets \ --with-openssl=/usr/local/ssl BackTrace: warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libaprutil-1.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libaprutil-1.so.0 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libldap-2.3.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libldap-2.3.so.0 Reading symbols from /usr/lib/liblber-2.3.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/liblber-2.3.so.0 Reading symbols from /lib/libdb-4.3.so...(no debugging symbols found)...done. Loaded symbols for /lib/libdb-4.3.so Reading symbols from /opt/apache2/lib/libexpat.so.0...done. Loaded symbols for /opt/apache2/lib/libexpat.so.0 Reading symbols from /opt/apache2/lib/libapr-1.so.0...done. Loaded symbols for /opt/apache2/lib/libapr-1.so.0 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /lib/libssl.so.6...done. Loaded symbols for /lib/libssl.so.6 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /lib/libkeyutils.so.1...done. Loaded symbols for /lib/libkeyutils.so.1
Bug #51900 [Opn-Bgs]: Abstract Method Not Overridden will Halt PHP.
Edit report at http://bugs.php.net/bug.php?id=51900edit=1
ID: 51900
Updated by: tony2...@php.net
Reported by: jrdoane at gmail dot com
Summary: Abstract Method Not Overridden will Halt PHP.
-Status: Open
+Status: Bogus
Type: Bug
Package: Class/Object related
Operating System: Ubuntu 9.10/RHEL 4
PHP Version: 5.2.13
New Comment:
Not reproducible.
Please enable error reporting and make sure display_errors is set to
On.
PHP 5.3.99-dev
PHP 5.3.3-dev
PHP 5.2.14-dev
All these versions report a fatal error:
Fatal error: Class example contains 1 abstract method and must therefore
be declared abstract or implement the remaining methods (abcEx::foo) in
/tmp/1.php on line 4
Previous Comments:
[2010-05-24 17:27:48] jrdoane at gmail dot com
Description:
if you have an abstract class that gets overridden, if a method that is
overridden has a default where the abstract doesn't, PHP just halts
without any error, warning, or fatal. For small projects this is
manageable, but when you have a large project, hunting down these things
take a long time, such as a multi-thousand lined library loaded with
abstract classes.
These are the folowing versions of PHP that I've tested:
$ php --version
PHP 5.2.10-2ubuntu6.4 with Suhosin-Patch 0.9.7 (cli) (built: Jan 6 2010
22:56:44)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
and
This is a RHEL box. (Red Hat Enterprise Linux ES release 4 (Nahant
Update 8))
$ php --version
PHP 5.2.13 (cli) (built: Apr 6 2010 18:40:35)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
Test script:
---
runme.php
?php
include(file1.php); // Fails here because a method isn't overridden.
// Just halts, no errors with error_reporting on and error output set to
E_ALL.
// The included file never actually executes any code unless the $bar
in
// the abstract class is changed to $bar=null, which fixes the problem,
but
// finding the problem to begin with is the problem.
?
file1.php
?php
include_once(file2.php);
class example extends absEx {
function foo($bar=null) {
// Do something
}
}
?
file2.php
?php
abstract class absEx {
abstract function foo($bar);
}
?
Expected result:
Error: Abstract method not overridden (Line: # OR method name)
Actual result:
--
# PHP halts suddenly with no error output.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51900edit=1
Bug #51822 [Ver-Asn]: Segfault with strange __destruct() for static class variables
Edit report at http://bugs.php.net/bug.php?id=51822edit=1 ID: 51822 Updated by: tony2...@php.net Reported by: daan at react dot com Summary: Segfault with strange __destruct() for static class variables -Status: Verified +Status: Assigned Type: Bug Package: Scripting Engine problem Operating System: Debian Etch PHP Version: 5.2.13 -Assigned To: +Assigned To: dmitry Previous Comments: [2010-05-14 15:20:44] daan at react dot com Reference to bugreport at xdebug: http://bugs.xdebug.org/view.php?id=580 [2010-05-14 15:14:51] daan at react dot com Hmm looks like it might be xdebug related.. #1 0xb739e2f2 in xdebug_execute (op_array=0x9ce5214) at /tmp/pear/temp/xdebug/xdebug.c:1392 I tried it on a non-xdebug php 5.2.10, and that had no problems - the 5.3.1 I tested with did not have xdebug installed either. Will throw the bug that way then.. apologies for the misdirected bug report! [2010-05-14 15:04:40] daan at react dot com JIC you still need it - a trace: #0 0x0837f473 in zend_hash_find (ht=0x9ce0398, arKey=0xb73babed , nKeyLength=5, pData=0xbfc0ea7c) at /usr/src/php-5.2.13/Zend/zend_hash.c:880 #1 0xb739e2f2 in xdebug_execute (op_array=0x9ce5214) at /tmp/pear/temp/xdebug/xdebug.c:1392 #2 0x08368c20 in zend_call_function (fci=0xbfc0ebec, fci_cache=0xbfc0ec10) at /usr/src/php-5.2.13/Zend/zend_execute_API.c:1039 #3 0x08387b2c in zend_call_method (object_pp=0xbfc0ec94, obj_ce=0x9ce3c0c, fn_proxy=0xbfc0ec98, function_name=0x8638cb8 __destruct, function_name_len=10, retval_ptr_ptr=0x0, param_count=0, arg1=0x0, arg2=0x0) at /usr/src/php-5.2.13/Zend/zend_interfaces.c:88 #4 0x0838da67 in zend_objects_destroy_object (object=0x9ce4898, handle=1) at /usr/src/php-5.2.13/Zend/zend_objects.c:101 #5 0x08390d30 in zend_objects_store_del_ref_by_handle (handle=1) at /usr/src/php-5.2.13/Zend/zend_objects_API.c:198 #6 0x08390d75 in zend_objects_store_del_ref (zobject=0x9ce22c4) at /usr/src/php-5.2.13/Zend/zend_objects_API.c:169 #7 0x08367ee9 in _zval_ptr_dtor (zval_ptr=0x9ce4928) at /usr/src/php-5.2.13/Zend/zend_variables.h:35 #8 0x0837e245 in zend_hash_destroy (ht=0x9ce48ec) at /usr/src/php-5.2.13/Zend/zend_hash.c:526 #9 0x0838dc07 in zend_object_std_dtor (object=0x9ce3284) at /usr/src/php-5.2.13/Zend/zend_objects.c:45 #10 0x0838dc40 in zend_objects_free_object_storage (object=0x9ce3284) at /usr/src/php-5.2.13/Zend/zend_objects.c:122 #11 0x08390d52 in zend_objects_store_del_ref_by_handle (handle=2) at /usr/src/php-5.2.13/Zend/zend_objects_API.c:211 #12 0x08390d75 in zend_objects_store_del_ref (zobject=0x9ce48d4) at /usr/src/php-5.2.13/Zend/zend_objects_API.c:169 #13 0x08367ee9 in _zval_ptr_dtor (zval_ptr=0x9ce46f8) at /usr/src/php-5.2.13/Zend/zend_variables.h:35 #14 0x0837e245 in zend_hash_destroy (ht=0x9ce4548) at /usr/src/php-5.2.13/Zend/zend_hash.c:526 #15 0x0836c123 in destroy_zend_class (pce=0x9d1a78c) at /usr/src/php-5.2.13/Zend/zend_opcode.c:184 #16 0x0837de9c in zend_hash_apply_deleter (ht=0x9b136a0, p=0x9d1a780) at /usr/src/php-5.2.13/Zend/zend_hash.c:611 #17 0x0837dfcb in zend_hash_reverse_apply (ht=0x9b136a0, apply_func=0x83675b0 clean_non_persistent_class) at /usr/src/php-5.2.13/Zend/zend_hash.c:760 #18 0x0836a8b6 in shutdown_executor () at /usr/src/php-5.2.13/Zend/zend_execute_API.c:291 #19 0x083752e4 in zend_deactivate () at /usr/src/php-5.2.13/Zend/zend.c:860 #20 0x083356eb in php_request_shutdown (dummy=0x0) at /usr/src/php-5.2.13/main/main.c:1504 #21 0x083e0872 in main (argc=2, argv=0xbfc0f4f4) at /usr/src/php-5.2.13/sapi/cli/php_cli.c:1346 [2010-05-14 15:00:16] fel...@php.net In fact I got something on Valgring log: Invalid write read and: ==5285== Address 0x65f0ba4 is 4 bytes inside a block of size 256 free'd ==5285==at 0x4024866: free (vg_replace_malloc.c:325) ==5285==by 0x83ACBD6: _efree (zend_alloc.c:2308) ==5285==by 0x83CD787: zend_ptr_stack_destroy (zend_ptr_stack.c:74) ==5285==by 0x83BE48B: shutdown_executor (zend_execute_API.c:283) ==5285==by 0x83D05D9: zend_deactivate (zend.c:860) ==5285==by 0x836D12B: php_request_shutdown (main.c:1504) ==5285==by 0x8459950: main (php_cli.c:1346) [2010-05-14 14:58:06] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I cannot reproduce it on 5_2 SVN. The remainder of the
Bug #51706 [Opn-Bgs]: Make fails dns.c:305: error: expected specifier-qualifier-list before ‘HEADER'
Edit report at http://bugs.php.net/bug.php?id=51706edit=1 ID: 51706 Updated by: tony2...@php.net Reported by: keith at take88 dot com Summary: Make fails dns.c:305: error: expected specifier-qualifier-list before âHEADER' -Status: Open +Status: Bogus Type: Bug Package: Compile Failure Operating System: Mac OS X 10.6.3 PHP Version: 5.3.2 New Comment: Apparently this is not a PHP problem, so it's unlikely we can help you and no point to keep the report open. Previous Comments: [2010-05-17 20:14:14] keith at take88 dot com So anyone have any clues about this bug? It sure would be nice if I could get this to work. [2010-05-04 17:12:36] keith at take88 dot com Wait a second. I'm seeing this when I run ./configure checking build system type... Invalid configuration `/usr': machine `/usr' not recognized That's the --prefix=/usr part of my ./configure script. That sounds like it could be screwing up my dns host stuff. Any ideas? [2010-05-04 16:18:02] ras...@php.net Works fine for me on Leopard here as well. Both 5.3.2 and SVN. [2010-05-04 15:47:14] keith at take88 dot com I'm trying to build PHP from source using a fresh install of Snow Leopard. No fink. No Macports. When I try an SVN install I get other problems. [2010-05-04 11:14:45] david dot zuelke at bitextender dot com Can't reproduce here... building from fresh SVN checkout of PHP_5_3 on a new install of Mac OS X 10.6.3. Both with ./configure --disable-all and MACOSX_DEPLOYMENT_TARGET=10.6.3 CFLAGS=-arch x86_64 -g -Os -pipe -no-cpp- precomp CCFLAGS=-arch x86_64 -g -Os -pipe CXXFLAGS=-arch x86_64 -g -Os -pipe LDFLAGS=- arch x86_64 -bind_at_load -L/usr/local/lib/ -liconv ./configure --disable-all it builds just fine, make test shows nothing unusual (http://pastie.org/944860), gethostbyname() etc work. Maybe it's some sort of library conflict on your system? Or your checkout is borked? Undeclared identifiers sound fishy; T_MX etc are defined outside of PHP. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51706 -- Edit this bug report at http://bugs.php.net/bug.php?id=51706edit=1
Bug #51651 [Opn-Bgs]: Dynamic class instatiation does not recognize namespaces.
Edit report at http://bugs.php.net/bug.php?id=51651edit=1
ID: 51651
Updated by: tony2...@php.net
Reported by: bruno dot p dot reis at gmail dot com
Summary: Dynamic class instatiation does not recognize
namespaces.
-Status: Open
+Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: windows vista
PHP Version: 5.3.2
New Comment:
This is a limitation of namespaces in PHP - they are resolved in
compile-time.
See http://www.php.net/manual/en/language.namespaces.dynamic.php
Previous Comments:
[2010-04-23 23:12:56] bruno dot p dot reis at gmail dot com
Description:
When I use a variable value as a class name, the file namespace is not
recognized.
Test script:
---
?php
namespace test;
class Test{}
new Test;
$className = '\test\Test';
new $className; // this works
$className = 'Test';
new $className; // this should work either, because this file declares
the test namespace, but it does not recognize class Test.
Expected result:
I expect to see no error.
Actual result:
--
Fatal error: Class 'Test' not found in ...
--
Edit this bug report at http://bugs.php.net/bug.php?id=51651edit=1
Bug #51760 [Opn-Fbk]: Memory Leak: zend hash not properly destroyed in CGI main
Edit report at http://bugs.php.net/bug.php?id=51760edit=1
ID: 51760
Updated by: tony2...@php.net
Reported by: russell dot tempero at rightnow dot com
Summary: Memory Leak: zend hash not properly destroyed in CGI
main
-Status: Open
+Status: Feedback
Type: Bug
Package: Performance problem
Operating System: Linux
PHP Version: 5.3.2
New Comment:
This hash is destroyed on shutdown by this function:
static PHP_MSHUTDOWN_FUNCTION(cgi)
{
zend_hash_destroy(CGIG(user_config_cache));
UNREGISTER_INI_ENTRIES();
return SUCCESS;
}
Previous Comments:
[2010-05-14 20:32:47] russell dot tempero at rightnow dot com
In my patch I forgot to set ht-pListHead to NULL. The following line
should be added toward the end of the zend_hash_destroy() function:
ht-pListHead = NULL;
[2010-05-06 23:57:27] russell dot tempero at rightnow dot com
Description:
After upgrading to PHP 5.3.2, we ran it through Purify and noticed the
following memory leak:
MLK: 32 bytes leaked at 0x9b70ca8
* This memory was allocated from:
calloc [rtlib.o]
_zend_hash_init [zend_hash.c:168]
php_cgi_globals_ctor [cgi_main.c:1429]
allocate_new_resource [TSRM.c:303]
ts_resource_ex [TSRM.c:370]
.
.
.
The problem is that php_cgi_globals_ctor() (the constructor) is calling
zend_hash_init() but there is no corresponding destructor to call
zend_hash_destroy(). I have attached a patch that will fix this.
You will notice in the patch that I had to make changes to
zend_hash_destroy() to prevent a double free. Apparently there are
places that are already calling zend_hash_destroy() for the hash that is
initialized in php_cgi_globals_ctor(), but it is not currently getting
called all of the time. Perhaps a more correct fix would be to find
where these other calls to zend_hash_destroy() are being made and either
eliminate them altogether or make sure they are called all of the time
and not have the destructor function.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51760edit=1
Bug #51640 [Opn-Bgs]: Fwrite writes twice a text
Edit report at http://bugs.php.net/bug.php?id=51640edit=1
ID: 51640
Updated by: tony2...@php.net
Reported by: spiderboy1989 at gmail dot com
Summary: Fwrite writes twice a text
-Status: Open
+Status: Bogus
Type: Bug
Package: Filesystem function related
Operating System: Windows XP
PHP Version: 5.3.2
New Comment:
Not reproducible.
Try providing a working example script, the one in the report doesn't
work.
Previous Comments:
[2010-06-01 10:19:44] g_i_ivanov at mail dot bg
I have the same problem:
Windows XP Professional SP3, Apache/2.2.14, PHP 5.2.13 (cli)
code:
--
$fp = fopen(d:/Projects/test/logs/testfile.txt, a);
fwrite($fp, date('c') . - Sample text . PHP_EOL);
fclose($fp);
result:
--
2010-05-31T10:36:37+03:00 - Sample text
2010-05-31T10:36:37+03:00 - Sample text
[2010-04-23 01:57:42] spiderboy1989 at gmail dot com
Description:
I'm having troubles with fwrite() function. It is writing twice a text I
just need to write once. I searched in google for the same problem, and
I found the same bug reported here :
http://bugs.php.net/bug.php?id=21916, and here :
http://bugs.php.net/bug.php?id=16225, but neither of both was solved.
This is how it writes into the file :
First
Second
Hello world!
Hello world!
Third
As you can see, the string hello world! is writed twice, and that
should not happen. Also, and this is weird, the line fwrite($op,
$lastLine); prints the text correctly, just once...
Test script:
---
$file = test.txt;
$string = Hello world!\r\n;
$op = fopen($file,r+);
$exp = explode(\n, fread($op, filesize($file)));
$lastLine = end($exp);
fseek($op, -strlen($lastLine), SEEK_END);
fwrite($op, $string);
fwrite($op, $lastLine);
fclose($op);
Expected result:
The text should be writed just once.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51640edit=1
Bug #51558 [Opn-Fbk]: configuration script fails at building readline shared library module
Edit report at http://bugs.php.net/bug.php?id=51558edit=1 ID: 51558 Updated by: tony2...@php.net Reported by: cremator at mail dot bg Summary: configuration script fails at building readline shared library module -Status: Open +Status: Feedback Type: Bug Package: Compile Failure Operating System: AIX 5.3 oslevel -r 5300-11 PHP Version: 5.3.2 New Comment: What's in your config.log? I do not mean to paste it all, but I need to see the parts related to readline and rl_pending_input() in particular. Put config.log online, if possible. I guess your lib is broken or was built in a wrong way. Previous Comments: [2010-04-15 10:50:05] cremator at mail dot bg Description: readline shared library 6.0 has been build on aix with gcc 4.2.0, gnu make 3.80, shared library ncurses 5.7, following a bit the guide at http://www.tekwire.net/joomla/building/apache/http_AIX_5.2.htm#p2.29 Everything seems to be working except that readline.h include file doesn't cope well with php 5.3.2 configure script. After downgrade php to 5.2.6 and patching it for openssl 1.0 everything works like it should. excuse my bad english and my less than little knowledge in coding Expected result: Thank you for using PHP. Actual result: -- checking for libedit readline replacement... no checking for readline support... yes, shared checking for tgetent in -lncurses... yes checking for readline in -lreadline... yes checking for rl_pending_input in -lreadline... no configure: error: invalid readline installation detected. Try --with-libedit instead. -- Edit this bug report at http://bugs.php.net/bug.php?id=51558edit=1
Bug #51552 [Opn-Asn]: debug_backtrace() causes segmentation fault and/or memory issues
Edit report at http://bugs.php.net/bug.php?id=51552edit=1
ID: 51552
Updated by: tony2...@php.net
Reported by: kkotowicz at gmail dot com
Summary: debug_backtrace() causes segmentation fault and/or
memory issues
-Status: Open
+Status: Assigned
Type: Bug
Package: Reproducible crash
Operating System: win/linux
PHP Version: 5.3.2
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2010-04-29 18:44:47] kkotowicz at gmail dot com
I dug depper into the issue, it looks as debug_backtrace() and functions
accepting references are causing the problem.
Here's the script that describes it:
?php
function walk($element, $key, $p) {
var_dump(func_get_args());
$backtrace = debug_backtrace();
//var_dump($backtrace);
unset($backtrace); // commenting this line crashes PHP
}
$a = range(1,10);
array_walk($a, 'walk', 'testthis');
?
this results in:
array(3) {
[0]=
int(1)
[1]=
int(0)
[2]=
string(8) testthis
}
array(3) {
[0]=
int(2)
[1]=
int(1)
[2]=
string(8) ! 1
}
array(3) {
[0]=
int(3)
[1]=
int(2)
[2]=
int(2)
}
array(3) {
[0]=
int(4)
[1]=
int(3)
[2]=
string(4) !
}
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate
134217728 bytes) in E:\tmp\php_bug\bug.php on line 4
for the first iteration, everything is ok. But each next time walk() is
called, the $p argument gets some random value, thus pointing to the
memory issues with debug_backtrace(). The backtrace itself will show
some garbage each next time.
[2010-04-28 19:40:08] kkotowicz at gmail dot com
The same problem occurs when running php 5.3.2/Win32
Backtrace generated from MS Debug Diagnostic Tool below:
Entry point php!mainCRTStartup
Create time 2010-04-28 19:34:00
Time spent in user mode 0 Days 0:0:0.15
Time spent in kernel mode 0 Days 0:0:0.0
Function Arg 1 Arg 2 Arg 3 Source
php5!zend_hash_num_elements+4 1007dbc0
php5!_zval_copy_ctor_func+61 01170378 011a0080 01170a50
php5!zend_startup_builtin_functions+2b54 01171648
011a0278
php5!zend_fetch_debug_backtrace+21a 01170830 00c0ea4c
0001
php5!zend_fetch_debug_backtrace+374 01170830
php5!execute+cdf 011a0278 01172d68 011a0278
php5!execute+4c25 10549738 10544688
php5!execute+1f0 0129cb18 0116f5f0 00c0eb30
php5!zend_call_function+6c1 10544688 105446ac 00c0eb70
php5!zif_max+3d3 0116f5f0 00c0eb30
php5!zif_array_walk+cf 0003 01170260
php5!execute+cdf 011a0080 0116f668 011a0080
php5!execute+4c25 00c0ec28 00c0fed4 00c0fcbc
php5!execute+1f0 0116f668 00c0fed4
php5!zend_execute_scripts+be 0008 0003
php5!php_execute_script+1e2 00c0fed4 0040642c 0001
php!main+a9a 0004 003d31d0 003d3450
php!memcpy+160 000e 7ffdf000
kernel32!BaseProcessStart+23 00402dda
PHP5!ZEND_HASH_NUM_ELEMENTS+4In
php__PID__2516__Date__04_28_2010__Time_07_34_10PM__865__Second_Chance_Exception_C005.dmp
the assembly instruction at php5!zend_hash_num_elements+4 in
E:\tmp\php_bug\bin\php5.dll from The PHP Group has caused an access
violation exception (0xC005) when trying to read from memory
location 0x0008 on thread 0
[2010-04-28 18:30:03] kkotowicz at gmail dot com
gdb backtrace for the failing script below:
#0 zend_hash_num_elements (ht=0x868f630) at
/home/xxx/debugPHP/php-5.3.2/Zend/zend_hash.c:1014
#1 0x082b6665 in debug_backtrace_get_args (curpos=value optimized
out)
at /home/xxx/debugPHP/php-5.3.2/Zend/zend_variables.h:45
#2 0x082b68a2 in zend_fetch_debug_backtrace (return_value=0x868f854,
skip_last=1, provide_object=1)
at /home/xxx/debugPHP/php-5.3.2/Zend/zend_builtin_functions.c:2195
#3 0x082b6b44 in zif_debug_backtrace (ht=0, return_value=0x868f854,
return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1) at
/home/xxx/debugPHP/php-5.3.2/Zend/zend_builtin_functions.c:2269
#4 0x082ec629 in zend_do_fcall_common_helper_SPEC
(execute_data=0x86bffa4)
at /home/xxx/debugPHP/php-5.3.2/Zend/zend_vm_execute.h:313
#5 0x082c6540 in execute (op_array=0x869036c) at
/home/xxx/debugPHP/php-5.3.2/Zend/zend_vm_execute.h:104
#6 0x0829a77a in zend_call_function (fci=0x85c9348,
fci_cache=0x85c936c)
at
Bug #51430 [Opn-Bgs]: Numeric string array key is being implicitly cast to 32bit int and overflowing
Edit report at http://bugs.php.net/bug.php?id=51430edit=1 ID: 51430 Updated by: tony2...@php.net Reported by: will at flourishlib dot com Summary: Numeric string array key is being implicitly cast to 32bit int and overflowing -Status: Open +Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Fedora 12 PHP Version: 5.3.2 New Comment: Not reproducible with 5.3.2, 5.3.3-dev and trunk on 64bit Linux. Previous Comments: [2010-03-29 20:18:41] will at flourishlib dot com Description: When trying to use a string array key that contains a number outside of the 32bit integer range, the key is being cast to an integer implicitly by PHP and is overflowing the 32bit integer limits. This incorrect casting is present in both 5.3.1 and 5.3.2 (probably 5.3.0), however 5.1.6 through 5.2.13 do not perform this implicit casting. The manual indicates that an integer-like key will be cast to an integer, however that should not be the case when the integer will not losslessly cast, since that can cause keys to be overwritten. Test script: --- print_r(array(-2147483649 = TRUE, -2147483648 = FALSE)); print_r(array(-2147483649 = 1, -2147483648 = 2, 2147483647 = 3, 2147483648 = 4)); Expected result: Array ( [-2147483649] = 1 [-2147483648] = ) Array ( [-2147483649] = 1 [-2147483648] = 2 [2147483647] = 3 [2147483648] = 4 ) Actual result: -- Array ( [2147483647] = 1 [-2147483648] = ) Array ( [2147483647] = 3 [-2147483648] = 4 ) -- Edit this bug report at http://bugs.php.net/bug.php?id=51430edit=1
Bug #51405 [Opn-Fbk]: segmentation fault at the engine shutdown
Edit report at http://bugs.php.net/bug.php?id=51405edit=1 ID: 51405 Updated by: tony2...@php.net Reported by: miha dot vrhovnik at domenca dot com Summary: segmentation fault at the engine shutdown -Status: Open +Status: Feedback Type: Bug Package: Reproducible crash Operating System: Linux PHP Version: 5.3.2 New Comment: No, I don't think VmWare image can be called a short reproduce case. Do you use any accelerators/opcode caches/other non-standard extensions? If yes, please disable them and see if you can still reproduce it. Previous Comments: [2010-05-20 07:34:28] miha dot vrhovnik at domenca dot com Hi, Mike I've tried to strip it down to simple script, but without success. Would downloadable VmWare image where I'd strip away as much as I can, help? [2010-05-19 15:47:13] m...@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 ?php and ends 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. No reproduce case, no chance to do anything, sorry. [2010-03-27 19:46:56] miha dot vrhovnik at domenca dot com Just so there won't be any excuses that this is because I'm running under php-fpm Here is backtrace from apache2. a bit different configure -- removed fpm and added apache: ./configure '--with-apxs2=/usr/bin/apxs2' '--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--with-curl' '--enable-exif' '--enable-ftp' '--with-gd' '--with-imap' '--with-imap-ssl' '--enable-mbstring' '--with-mcrypt' '--enable-pcntl' '--with-pdo-mysql' '--with-pdo-pgsql' '--with-pgsql' '--with-readline' '--with-mysql' '--enable-soap' '--enable-sockets' '--enable-sqlite-utf8' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-tidy' '--enable-wddx' '--with-xmlrpc' '--with-xsl' '--enable-zip' '--with-kerberos' '--with-mysqli' '--with-config-file-path=/usr/local/etc' '--with-config-file-scan-dir=/usr/local/etc/php.d' '--with-pear' '--with-jpeg-dir=/usr/lib' --with-freetype-dir=/usr/lib and now the actual backtrace (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. _zend_mm_free_int (heap=0xb979d180, p=0xb9946290) at /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c:2018 2018/projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c: No such file or directory. in /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c (gdb) bt #0 _zend_mm_free_int (heap=0xb979d180, p=0xb9946290) at /projects/php53/php-fpm-5.3.2/Zend/zend_alloc.c:2018 #1 0xb6ff2498 in zend_hash_destroy (ht=0xba189ca0) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #2 0xb7003fc3 in zend_object_std_dtor (object=0xba193830) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:45 #3 0xb7003ff2 in zend_objects_free_object_storage (object=0xba193830) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:114 #4 0xb70075fc in zend_objects_store_del_ref_by_handle_ex (handle=127, handlers=0xb74c65c0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:220 #5 0xb700762f in zend_objects_store_del_ref (zobject=0xba189ff0) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects_API.c:172 #6 0xb6fdbedf in _zval_dtor (zval_ptr=0xba1a6238) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 #7 _zval_ptr_dtor (zval_ptr=0xba1a6238) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #8 0xb6ff2498 in zend_hash_destroy (ht=0xba19273c) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #9 0xb6fe6945 in _zval_dtor_func (zvalue=0xba197ef4) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.c:43 #10 0xb6fdbedf in _zval_dtor (zval_ptr=0xba106080) at /projects/php53/php-fpm-5.3.2/Zend/zend_variables.h:35 ---Type return to continue, or q return to quit--- #11 _zval_ptr_dtor (zval_ptr=0xba106080) at /projects/php53/php-fpm-5.3.2/Zend/zend_execute_API.c:439 #12 0xb6ff2498 in zend_hash_destroy (ht=0xba12276c) at /projects/php53/php-fpm-5.3.2/Zend/zend_hash.c:526 #13 0xb7003fc3 in zend_object_std_dtor (object=0xb5e7013c) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:45 #14 0xb7003ff2 in zend_objects_free_object_storage (object=0xb5e7013c) at /projects/php53/php-fpm-5.3.2/Zend/zend_objects.c:114 #15 0xb70075fc in zend_objects_store_del_ref_by_handle_ex (handle=120,
Bug #51404 [Opn-Bgs]: is_dir() returns false on cifs mounted share
Edit report at http://bugs.php.net/bug.php?id=51404edit=1
ID: 51404
Updated by: tony2...@php.net
Reported by: neversaynever at tut dot by
Summary: is_dir() returns false on cifs mounted share
-Status: Open
+Status: Bogus
Type: Bug
Package: Directory function related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
I'm sure PHP doesn't affect any of system functions, including stat().
You get what your stat() returns - not PHP problem.
Previous Comments:
[2010-03-26 20:34:07] neversaynever at tut dot by
Description:
I upgraded my kernel to 2.6.31 (stable) and has php-5.2.12 (stable),
but
php function is_dir() returns false for folder on my cifs mounted
share.
strace php -r 'var_dump(is_dir(/path_to_mounted_folder/));'
...
stat64(/path_to_mounted_folder/, {st_mode=S_IFDIR|0755, st_size=32768,
...}) = 0
gettimeofday({1269602972, 30466}, NULL) = 0
write(1, bool(false)\n, 12bool(false)
) = 12
...
Test script:
---
php -r 'var_dump(is_dir(/path_to_mounted_folder/));'
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51404edit=1
Bug #51397 [Ver-Bgs]: Math calculation bug
Edit report at http://bugs.php.net/bug.php?id=51397edit=1
ID: 51397
Updated by: tony2...@php.net
Reported by: emanuel dot dejanu at humaninfo dot ro
Summary: Math calculation bug
-Status: Verified
+Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: FREEBSD LINUX
PHP Version: 5.2.13
New Comment:
It looks to me that this code has an integer overflow at some point
Yep.
And it's easy to see where exactly it overflows:
Add var_dump($h); at the end of for() loop, you'll see it yourself:
int(177638)
int(5862122)
int(193450012)
int(203122)
int(213666243)
int(-1538948595)
int(754303898)
int(754303898)
Previous Comments:
[2010-04-25 12:46:01] paj...@php.net
It looks to me that this code has an integer overflow at some point. I
would suggest to use ext/hash if you need reliable hashes or add integer
overflow checks in your code.
This behavior can't be seen on windows. On this platform the long type
has the same size, no matter the architecture (32bit on both x64 and
x86).
[2010-04-25 12:29:10] cimodev at me dot com
My Result on OpenSuse 11.0 - 64bit with PHP 5.3.2:
229416432419738
-
On Debian 64bit:
PHP 5.3.2-0.dotdeb.1 with Suhosin-Patch (cli) (built: Mar 9 2010
11:42:01)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH
229416432419738
Maybe this bug occurres primarily on 32bit systems... I have none here
for testing
[2010-04-22 21:54:37] whatrevolution at yahoo dot com
My answer to myhash('CL6.1.7'): 229416432419738
PHP Version 5.2.10-2ubuntu6.4
System Linux 2.6.31-20-generic x86_64
Build Date Jan 6 2010 22:36:47
Server API Apache 2.0 Handler
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
Apache/2.2.12 (Ubuntu)
[2010-03-26 11:56:42] f...@php.net
Verified with 5.2.13 on Debian (default configure)
Verified in the Debian 5.2.6+lenny4 PHP (just for completeness)
Correct result with 5.3.2 on Gentoo
[2010-03-26 08:20:19] emanuel dot dejanu at humaninfo dot ro
Description:
I have used the code from the test script on my development machine
(Windows Professional 7 32bit) with php 5.2.12 and is working correctly
but when I have deployed on my production machine that is FreeBSD 6.3
32bit with the same php version 5.2.12 is giving wrong results
(-2147483593). I also run this on other production machine that is
RedHat 5 32bit with php 5.2.6 and is also giving wrong results
(-2147483593).
I can not test with php 5.2.13 on production machines (virtual
hosting).
On windows is giving the correctly result (754303898) with PHP 5.2.12
and PHP 5.3.1. I am running in 32bit platform on all machines.
---
PHP_INT_SIZE: 4
System = FreeBSD somehost.com 6.3-RELEASE FreeBSD 6.3-RELEASE #6: Wed
Oc
t 21 09:32:42 MDT 2009 r...@fc:/usr/src/sys/i386/compile/VKERN i386
Build Date = Mar 3 2010 12:51:00
Configure Command = './configure' '--with-layout=GNU'
'--with-config-file-sca
n-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml'
'--with-libxml-dir=/
usr/local' '--enable-reflection' '--program-prefix=' '--enable-fastcgi'
'--with-
apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL'
'--prefix=/
usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/'
'--build=i386-
portbld-freebsd6.3'
Server API = Command Line Interface
Virtual Directory Support = disabled
Configuration File (php.ini) Path = /usr/local/etc
Loaded Configuration File = /usr/local/etc/php.ini
Scan this dir for additional .ini files = /usr/local/etc/php
additional .ini files parsed = /usr/local/etc/php/extensions.ini
PHP API = 20041225
PHP Extension = 20060613
Zend Extension = 220060519
Debug Build = no
Test script:
---
function myhash($key) {
$h = 5381;
$l = strlen($key);
for($i = 0; $i $l; ++$i) {
$h = (($h 5) + $h) ^ ord($key[$i]);
}
return $h;
}
$h = myhash('CL6.1.7');
if ($h != 754303898)
echo bug\n;
echo $h . \n;
Expected result:
754303898
Actual result:
--
bug
-2147483593
--
Edit this bug report at http://bugs.php.net/bug.php?id=51397edit=1
Bug #51312 [Opn-Bgs]: include_once/require_once are case sensitive on OS X
Edit report at http://bugs.php.net/bug.php?id=51312edit=1 ID: 51312 Updated by: tony2...@php.net Reported by: whatthejeff at gmail dot com Summary: include_once/require_once are case sensitive on OS X -Status: Open +Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Mac OS X 10.6 PHP Version: 5.3.2 New Comment: It's not reproducible on windows because filesystems there are ALWAYS case insensitive. But since on Mac it's possible to choose between case sensitive and case insensitive FS, you have to control this yourself - there is no way for PHP to 'detect' how exactly the filename should be used (and even if there is, it would mean a nice performance impact). In short - this is not PHP problem. Previous Comments: [2010-03-19 06:09:01] whatthejeff at gmail dot com Further testing indicates that this bug does not exist for all case sensitive file systems. I could not reproduce this error using Windows. [2010-03-17 05:36:02] whatthejeff at gmail dot com Description: With PHP 5.3.2 on OS X 10.6 I am able to include the same file multiple times using include_once() and require_once() Configurations: -- $ /usr/local/php-test/bin/php -v PHP 5.3.2 (cli) (built: Mar 16 2010 21:48:40) $ /usr/local/php-test/bin/php -i | grep config Configure Command = './configure' '--prefix=/usr/local/php-test' Test script: --- $ echo '?php echo included\n; ?' test.php $ php -r 'require_once(test.php); require_once(Test.php);' or $ php -r 'include_once(test.php); include_once(Test.php);' Expected result: included Actual result: -- included included -- Edit this bug report at http://bugs.php.net/bug.php?id=51312edit=1
Bug #51307 [Opn-Asn]: php.exe error on command line
Edit report at http://bugs.php.net/bug.php?id=51307edit=1 ID: 51307 Updated by: tony2...@php.net Reported by: joerg dot klein at ifsam dot lu Summary: php.exe error on command line -Status: Open +Status: Assigned Type: Bug Package: Reproducible crash Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.2 -Assigned To: +Assigned To: pajoye Previous Comments: [2010-03-17 11:47:34] joerg dot klein at ifsam dot lu I double checked both configurations and both apache and cli are using the same php.ini and also the same settings. Nothing was changed since the previous working php versions. The only change to the system was replacing the php directory. Since 5.3 I use always the VC6 TS versions. I also have redownloaded and installed the 5.3.2 VC6 TS win32 binaries without success. Something has to be changed from 5.3.1 to 5.3.2. [2010-03-17 10:37:31] paj...@php.net I see only one cause, some old version of these extensions are being loaded. Or extensions not from the same PHP releases (VC6 instead of VC9 for example, for php 5.3). But there are no problem in 5.3.2's gd or mysql extensions. They work just fine (cli as you see yourself), apache, etc.). I would double check that apache is actually using the same configuration than CLI (via a simple phpinfo), and compare the paths (extension_dir, loaded php.ini). [2010-03-17 09:11:08] joerg dot klein at ifsam dot lu By disabling gd2 or mysql or both, the error is gone. I only have these to extensions enabled. [2010-03-16 16:54:04] paj...@php.net Please disable all extensions and enable them again one by one to figure out which one. [2010-03-16 16:15:14] joerg dot klein at ifsam dot lu Backtrace: Thread 0 - System ID 1180 Entry point php!mainCRTStartup Create time 16.03.2010 16:09:36 Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.93 Function Arg 1 Arg 2 Arg 3 Source php5ts!_zend_mm_free_int+66 002250f8 5c6e6574 100d2214 php5ts!_efree+36 01ad44b0 00223ba8 101f2e05 php5ts!closelog+54 101ae8b7 0001 0013 php5ts!zm_deactivate_syslog+5 0001 0013 00223ba8 php5ts!zm_deactivate_basic+e7 0001 0013 00223ba8 php5ts!module_registry_cleanup+1c 01bfcca8 00223ba8 00c0fb24 php5ts!zend_hash_reverse_apply+42 1054d280 10008400 00223ba8 php5ts!zend_deactivate_modules+62 00c0ffb0 56433230 php5ts!zend_deactivate_modules+48 00229adc 00223ba8 100bbbdb php5ts!zend_llist_clean+b 00229adc 00c0fdf0 php5ts!php_deactivate_ticks+1b 00c0fc0c 00223ba8 00c0fea8 php5ts!execute+2fe 01b00128 00223b00 php5ts!zend_execute_scripts+f6 00c0ffb0 56433230 php5ts!php_request_shutdown+13d 0002 00220178 01ace4c8 msvcrt!_lseek+aa 00c0ffb0 56433230 php5ts!php_request_shutdown+206 77bbd08c 0022 ntdll!RtlAllocateHeap+ee7 7ffda000 kernel32!BaseProcessStart+23 00402d78 PHP5TS!_ZEND_MM_FREE_INT+66In php__PID__1284__Date__03_16_2010__Time_04_09_56PM__366__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!_zend_mm_free_int+66 in C:\Program Files\Apache Group\Apache\php-bin\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x5e1baa1c on thread 0 Module Information Image Name: C:\Program Files\Apache Group\Apache\php-bin\php5ts.dll Symbol Type: PDB Base address: 0x1000 Time Stamp: Wed Mar 03 20:38:42 2010 Checksum: 0x Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.3.2 Managed DLL: False Internal Name: PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2009 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: C:\Program Files\Apache Software Foundation\Apache2.2\php-bin\php5ts.dll Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Module Size: 5,50 MBytes Product Version: 5.3.2 Symbol File Name: C:\Program Files\Apache Software
Bug #51276 [Opn-Csd]: php_load_extension is called when HAVE_LIBDL is not defined.
Edit report at http://bugs.php.net/bug.php?id=51276edit=1
ID: 51276
Updated by: tony2...@php.net
Reported by: tsteiner at nerdclub dot net
Summary: php_load_extension is called when HAVE_LIBDL is not
defined.
-Status: Open
+Status: Closed
Type: Bug
Package: Compile Failure
Operating System: Linux
PHP Version: 5.3.2
-Assigned To:
+Assigned To: tony2001
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:
[2010-06-08 14:54:13] tony2...@php.net
Automatic comment from SVN on behalf of tony2001
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=300272
Log: fix bug #51276 (php_load_extension() is missing when HAVE_LIBDL is
undefined)
[2010-03-19 16:42:59] richard at webdezign dot co dot uk
I have this problem too on CentOS 5.3.
I run:
../php-5.3.2/configure --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu
make
and get the same error. I do have libdl.so.2 in my lib64 directory.
But if I apply the php-5.3.2-nolibdl-compile-error patch, does that mean
that the PHP I compile will not be able to load extensions dynamically?
[2010-03-11 18:08:41] tsteiner at nerdclub dot net
Description:
When HAVE_LIBDL is not defined in main/php_config.h, the function
php_load_extension is not compiled in ext/standard/dl.c. However, the
function php_load_php_extension_cb() will always be compiled with a call
to php_load_extension. This causes compilation to fail with the
following message:
main/php_ini.o: In function `php_load_php_extension_cb':
[path removed]/main/php_ini.c:350: undefined reference to
`php_load_extension'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
This appears to be the only place php_load_extension is called.
Furthermore, php_load_php_extension_cb is only referenced by
php_ini_register_extensions(), which is only called in at
main/main.c:2021. It would seem that on architectures that don't
HAVE_LIBDL, the preceding functions should be inside #if defined()
checks.
I found this bug while cross-compiling from x86_64 to powerpc but I
don't believe it is a cross-compiling issue.
Test script:
---
CC=${CROSS_COMPILE}gcc ../php-5.3.2/configure
--host=powerpc-unknown-linux
make
Expected result:
PHP should compile without errors.
Actual result:
--
main/php_ini.o: In function `php_load_php_extension_cb':
[path removed]/main/php_ini.c:350: undefined reference to
`php_load_extension'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51276edit=1
Bug #51275 [Opn-Asn]: unpack('I', $x) on 64 bit big endian unreliable
Edit report at http://bugs.php.net/bug.php?id=51275edit=1
ID: 51275
Updated by: tony2...@php.net
Reported by: stuart_hayton at uk dot ibm dot com
Summary: unpack('I', $x) on 64 bit big endian unreliable
-Status: Open
+Status: Assigned
Type: Bug
Package: Strings related
Operating System: AIX64
PHP Version: 5.3.2
-Assigned To:
+Assigned To: kalle
Previous Comments:
[2010-03-12 04:45:04] ka...@php.net
Hi, could you please upload the patch using diff -u to the bug tracker?
[2010-03-11 16:20:33] stuart_hayton at uk dot ibm dot com
Description:
Testing unpack 'I' format on a 64bit big-endian architecture.
The result depends on the sign bit in the *next* integer in the packed
buffer
or a out of buffer byte if it is not that long.
A patch which resolves this is below.
I think the code ends up producing identical results for the I and i
format which may be the most desirable thing but the code looks like it
was
intended to behave differently. Maybe it can be simplified.
Similar to bug #40894 but a different format (I).
patch:
*** pack.c Thu Mar 11 15:05:11 2010
--- pack.c.orig Thu Mar 11 15:03:20 2010
***
*** 752,758
if (type == 'i') {
issigned =
input[inputpos + (machine_little_endian ? (sizeof(int) - 1) : 0)]
0x80;
! } else if (sizeof(long)
4 input[inputpos + (machine_little_endian ? (sizeof(int) - 1) : 0)]
0x80 == 0x80) {
v = ~INT_MAX;
}
--- 752,758
if (type == 'i') {
issigned =
input[inputpos + (machine_little_endian ? (sizeof(int) - 1) : 0)]
0x80;
! } else if (sizeof(long)
4 (input[inputpos + machine_endian_long_map[3]] 0x80) == 0x80) {
v = ~INT_MAX;
}
Test script:
---
?php
echo PHP_INT_MAX.\n;
print_r(unpack('I', pack('I', -1) . pack('I', 1)));
print_r(unpack('I', pack('I', -1) . pack('I', -1)));
?
Expected result:
9223372036854775807
Array
(
[1] = -1
)
Array
(
[1] = -1
)
Actual result:
--
9223372036854775807
Array
(
[1] = 4294957296
)
Array
(
[1] = -1
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51275edit=1
Bug #51274 [Opn-Asn]: Integer overflow does not cast as float
Edit report at http://bugs.php.net/bug.php?id=51274edit=1 ID: 51274 Updated by: tony2...@php.net Reported by: cduncan at regatta dot com Summary: Integer overflow does not cast as float -Status: Open +Status: Assigned Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: 5.3.2 -Assigned To: +Assigned To: aharvey Previous Comments: [2010-04-13 16:42:21] cduncan at regatta dot com I am now able to reproduce the problem, what extra information do you require to debug? [2010-03-26 10:17:04] cduncan at regatta dot com Thanks, I was worried I was going mad for a moment there. Unfortunately I can't reproduce it on the machines I'm using at the moment. The machine I was experiencing it on was a production box, so finding time to reproduce it again could be tricky. Once I am able to do so, what extra information would assist in tracking this down? Thanks [2010-03-26 09:24:56] ahar...@php.net Oh, I see what you're getting at now. Sorry about that. I still can't reproduce it, though. [2010-03-26 09:16:37] cduncan at regatta dot com Sorry but I'm misunderstanding what you are telling me. Why is the number reduced to the 32bit limit? (2147483647) Especially if you're saying the only way this could occur is with a 64bit OS? As I stated in my last edit, wouldn't a 64bit OS return: int(2147483648) [2010-03-26 07:50:20] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=296829 Log: Update to the integer type page to make it clearer how overflow works on 32- and 64-bit systems and what the critical thresholds are. Prompted by bug #51274, although not an actual fix for it. 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=51274 -- Edit this bug report at http://bugs.php.net/bug.php?id=51274edit=1
Bug #51265 [Opn-Fbk]: Segfault because of wrong memory allocation
Edit report at http://bugs.php.net/bug.php?id=51265edit=1
ID: 51265
Updated by: tony2...@php.net
Reported by: gotwig at papaya-cms dot com
Summary: Segfault because of wrong memory allocation
-Status: Open
+Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: Debian GNU/Linux 4.0
PHP Version: 5.2SVN-2010-03-10 (SVN)
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If 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.
Previous Comments:
[2010-03-12 16:25:44] gotwig at papaya-cms dot com
sorry, I have actually no idea how to exactly reproduce a stack
reallocation inside of preg_replace_callback with a custom script to
help you. I must think about, perhaps some days later.
[2010-03-12 16:03:39] paj...@php.net
Do you have a script to reproduce this problem?
[2010-03-12 14:45:12] gotwig at papaya-cms dot com
Hallo,
my assumption about a wrong sized block allocation has not confirmed, I
have the source of the problem now:
- it occurs in preg_replace_impl function,
- our php code use preg_replace_callback with a static callback to a
non-static object method,
- this raise an E_STRICT warning where an user defined error handler
will be called,
- this call reallocates argument stack where some pointers to the
previous argument stack frame are already saved in preg_replace_impl and
will be used a bit later.
Our PHP code likes as following:
class PapayaUtilStringUtf8 {
...
preg_replace_callback(
$pattern,
array('PapayaUtilStringUtf8', 'ensureCharCallback'),
(string)$string
);
...
function ensureCharCallback($charMatch) {
...
}
}
Actual backtrace from reallocation call, where p=0xb70318b0 is
argument_stack :
#0 _zend_mm_realloc_int (heap=0x81de2a0, p=0xb70318b0, size=516) at
/data/extern/php_svn/php-src-5.2/Zend/zend_alloc.c:2005
#1 0xb76d02e9 in zend_call_function (fci=0xbfad9d84, fci_cache=0x0) at
/data/extern/php_svn/php-src-5.2/Zend/zend_ptr_stack.h:99
#2 0xb76d191e in call_user_function_ex (function_table=0x812b088,
object_pp=0x0, function_name=0xb6bedd0c, retval_ptr_ptr=0xbfad9e00,
param_count=5, params=0xb6bed450,
no_separation=1, symbol_table=0x0) at
/data/extern/php_svn/php-src-5.2/Zend/zend_execute_API.c:640
#3 0xb76dbfe8 in zend_error (type=2048, format=0xb780ba78 Non-static
method %s::%s() cannot be called statically) at
/data/extern/php_svn/php-src-5.2/Zend/zend.c:1041
#4 0xb76e18fe in zend_is_callable_check_func (check_flags=value
optimized out, zobj_ptr_ptr=0xbfad9eb8, ce_org=0xb6d1dda0,
callable=0xb6b349f8, ce_ptr=0xbfad9ec4,
fptr_ptr=0xbfad9ebc) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2204
#5 0xb76e1cac in zend_is_callable_ex (callable=0xb6b349e0,
check_flags=value optimized out, callable_name=0xbfad9f44,
callable_name_len=0x0, ce_ptr=0xbfad9ec4,
fptr_ptr=0xbfad9ebc, zobj_ptr_ptr=0xbfad9eb8) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2332
#6 0xb76e1f97 in zend_is_callable (callable=0xb6b349e0, check_flags=0,
callable_name=0xbfad9f44) at
/data/extern/php_svn/php-src-5.2/Zend/zend_API.c:2363
#7 0xb751f2a4 in preg_replace_impl (ht=3, return_value=0xb6b34cac,
return_value_ptr=value optimized out, this_ptr=0x0,
return_value_used=1,
is_callable_replace=1 '\001') at
/data/extern/php_svn/php-src-5.2/ext/pcre/php_pcre.c:1319
[2010-03-10 18:43:40] gotwig at papaya-cms dot com
Description:
Hallo,
I have found a bug in _emalloc logic where an allocation returns a
pointer to a cached block smaller than requested; when this block is
used some memory after that goes corrupted and we get a segfault.
The problem is reproducible with our project code, that is a version of
papaya cms, but I am not able to reconstruct all circumstances with an
example script to send you, sorry. I am debugging it itself, but need
perhaps some help from you to understand how exact does memory
allocation works here and where will be such one
Bug #51260 [Opn-Bgs]: Compile PHP with compiled openssl - relocation R_X86_64_32
Edit report at http://bugs.php.net/bug.php?id=51260edit=1 ID: 51260 Updated by: tony2...@php.net Reported by: vejpuste at oikt dot czu dot cz Summary: Compile PHP with compiled openssl - relocation R_X86_64_32 -Status: Open +Status: Bogus Type: Bug Package: Compile Failure Operating System: CentOS release 5.4 x86_64 PHP Version: 5.2.13 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2010-04-07 04:23:04] cnemelka at yahoo dot com Same problem in RHEL5 (release 5.5 Tikanga) [2010-03-17 00:24:41] oneforall59 at hotmail dot com Hi same problem for me that -Wl,-rpath, isn't getting passed. I did a diff on a few file configure, Makefile, acinclude.m4, aclocal.m4 etc and I do see a chunk removed from configure but it doersn'tlook like its to do with it. But not sure. I do know there is somethign missing for it to pass the -Wl,-rpath, thou. In my build I added EXTRA_LDFLAGS=-L/usr/lib64 -Wl,-rpath,/usr/local/lib64/c- client/lib64 -L/usr/local/lib64/c-client/lib64 -L/usr/local/lib64/c- client/lib64 \ ./configure ... I had to because with multilib it was trying to read the 32bit libs . LDFLAGS=-L/lib64 -L/usr/lib64 etc weren't working . I just dunno what configure uses to get that line for EXTRA_LDFLAGS in Makefile :( [2010-03-10 13:30:35] vejpuste at oikt dot czu dot cz Description: I have compiled openssl (./config -Bsymbolic) PHP compiled --with-openssl=/usr/local/ssl PHP 5.2.12 make OK PHP 5.2.13 make : ... -o libphp5.la /usr/bin/ld: /usr/local/ssl/lib64/libssl.a(s2_srvr.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/ssl/lib64/libssl.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 I compare Makefile 5.2.12 and 5.2.13. Different is : #5.2.13 EXTRA_LDFLAGS = -avoid-version -module -L/usr/local/ssl/lib64 -L/usr/lib/oracle/11.2/client64/lib -L/usr/local/lib64 #5.2.12 EXTRA_LDFLAGS = -avoid-version -module -L/usr/lib64 -Wl,-rpath,/usr/local/ssl/lib64 -L/usr/local/ssl/lib64 -Wl,-rpath,/usr/lib /oracle/11.2/client64/lib -L/usr/lib/oracle/11.2/client64/lib -Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64 -L/usr/local/ssl/ lib64 -L/usr/lib/oracle/11.2/client64/lib -L/usr/local/lib64 I modify Makefile to EXTRA_LDFLAGS from 5.2.12 - make OK. -- Edit this bug report at http://bugs.php.net/bug.php?id=51260edit=1
Bug #51243 [Opn-Fbk]: syntax error in autoload causes segmentation fault
Edit report at http://bugs.php.net/bug.php?id=51243edit=1
ID: 51243
Updated by: tony2...@php.net
Reported by: tsamukawa at maru dot jp
Summary: syntax error in autoload causes segmentation fault
-Status: Open
+Status: Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: CentOS5.*
PHP Version: 5.3.2
New Comment:
Not reproducible.
The only result I'm able to get is this:
Parse error: syntax error, unexpected T_STRING, expecting T_FUNCTION in
/tmp/C.php on line 4
Previous Comments:
[2010-03-11 02:34:07] tsamukawa at maru dot jp
I have 2 different backtraces generated.
1st bt is geneated by running same script as the sample.
2nd bt is by script uses calling spl_autoload_register() from inside of
another user-defined function.
---
Program received signal SIGSEGV, Segmentation fault.
0xb77c8b44 in autoload_func_info_dtor (alfi=0x7373616c) at
/s/php-5.3.2/ext/spl/php_spl.c:362
362 if (alfi-obj) {
(gdb) bt
#0 0xb77c8b44 in autoload_func_info_dtor (alfi=0x7373616c) at
/s/php-5.3.2/ext/spl/php_spl.c:362
#1 0xb7966728 in zend_hash_destroy (ht=0x8412154) at
/s/php-5.3.2/Zend/zend_hash.c:526
#2 0xb77cb7a5 in zm_deactivate_spl (type=1, module_number=20) at
/s/php-5.3.2/ext/spl/php_spl.c:904
#3 0xb795fffc in module_registry_cleanup (module=0x82abd10) at
/s/php-5.3.2/Zend/zend_API.c:2150
#4 0xb7966f96 in zend_hash_reverse_apply (ht=0xb7ecaaa0,
apply_func=0xb795ffcd module_registry_cleanup) at /s/php-
5.3.2/Zend/zend_hash.c:755
#5 0xb7957950 in zend_deactivate_modules () at
/s/php-5.3.2/Zend/zend.c:866
#6 0xb78eb409 in php_request_shutdown (dummy=0x0) at
/s/php-5.3.2/main/main.c:1607
#7 0xb7a21b2d in php_apache_request_dtor (r=0x83971e0) at
/s/php-5.3.2/sapi/apache2handler/sapi_apache2.c:495
#8 0xb7a2241e in php_handler (r=0x83971e0) at
/s/php-5.3.2/sapi/apache2handler/sapi_apache2.c:667
#9 0x0807f629 in ap_run_handler (r=0x83971e0) at config.c:157
#10 0x08082797 in ap_invoke_handler (r=0x83971e0) at config.c:372
#11 0x080d64f8 in ap_process_request (r=0x83971e0) at
http_request.c:282
#12 0x080d36db in ap_process_http_connection (c=0x83d9810) at
http_core.c:190
#13 0x08086769 in ap_run_process_connection (c=0x83d9810) at
connection.c:43
#14 0x08104f1d in child_main (child_num_arg=value optimized out) at
prefork.c:662
#15 0x08105163 in make_child (s=0x8152c98, slot=0) at prefork.c:702
#16 0x08105f3c in ap_mpm_run (_pconf=0x814a550, plog=0x81a47f8,
s=0x8152c98) at prefork.c:978
#17 0x0806cf25 in main (argc=135562568, argv=0x83d7630) at main.c:740
---
Program received signal SIGSEGV, Segmentation fault.
0xb7ffb402 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7ffb402 in __kernel_vsyscall ()
#1 0x459e61b6 in kill () from /lib/libc.so.6
#2 0xb79e15a1 in zend_mm_panic (message=0xb7f3a690 zend_mm_heap
corrupted) at /s/php-5.3.2/Zend/zend_alloc.c:92
#3 0xb79e3a2e in _zend_mm_alloc_int (heap=0x8284880, size=49,
__zend_filename=0xb7f3834b Zend/zend_language_scanner.l,
__zend_lineno=690, __zend_orig_filename=0x0,
__zend_orig_lineno=0) at /s/php-5.3.2/Zend/zend_alloc.c:1827
#4 0xb79e50ff in _emalloc (size=49, __zend_filename=0xb7f3834b
Zend/zend_language_scanner.l, __zend_lineno=690,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /s/php-5.3.2/Zend/zend_alloc.c:2340
#5 0xb79cc147 in zend_multibyte_read_script (buf=0xb7fee000
?php\n\nclass C{\n functio pr(){ print 123; }\n}\n\n, n=48)
at Zend/zend_language_scanner.l:690
#6 0xb79cb083 in open_file_for_scanning (file_handle=0xbfe06a00) at
Zend/zend_language_scanner.l:263
#7 0xb79cb290 in compile_file (file_handle=0xbfe06a00, type=8) at
Zend/zend_language_scanner.l:331
#8 0xb77d6015 in phar_compile_file (file_handle=0xbfe06a00, type=8) at
/s/php-5.3.2/ext/phar/phar.c:3390
#9 0xb79cb46a in compile_filename (type=8, filename=0x844809c) at
Zend/zend_language_scanner.l:386
#10 0xb7a438d6 in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER
(execute_data=0x8448048) at /s/php-5.3.2/Zend/zend_vm_execute.h:5184
#11 0xb7a33be4 in execute (op_array=0x8413e2c) at
/s/php-5.3.2/Zend/zend_vm_execute.h:104
#12 0xb79f8f5c in zend_call_function (fci=0xbfe06d54,
fci_cache=0xbfe06d24) at /s/php-5.3.2/Zend/zend_execute_API.c:947
#13 0xb7a21e08 in zend_call_method (object_pp=0x841363c,
obj_ce=0x84139e4, fn_proxy=0x8413638, function_name=0x84113d4
loader::autoload\001, function_name_len=21,
retval_ptr_ptr=0xbfe06df4, param_count=1, arg1=0x8412060, arg2=0x0)
at /s/php-5.3.2/Zend/zend_interfaces.c:97
#14 0xb7877cfc in zif_spl_autoload_call (ht=1, return_value=0x8411fd0,
return_value_ptr=0xbfe06fe0, this_ptr=0x0,
return_value_used=1) at /s/php-5.3.2/ext/spl/php_spl.c:395
Bug #51225 [ReO-Asn]: cannot define a class with the same name as an interface
Edit report at http://bugs.php.net/bug.php?id=51225edit=1
ID: 51225
Updated by: tony2...@php.net
Reported by: tony at marston-home dot demon dot co dot uk
Summary: cannot define a class with the same name as an
interface
-Status: Re-Opened
+Status: Assigned
Type: Bug
Package: Class/Object related
Operating System: Windows XP
PHP Version: 5.2.13
-Assigned To:
+Assigned To: johannes
Previous Comments:
[2010-03-08 10:35:06] tony at marston-home dot demon dot co dot uk
I disagree. class_exists() SHOULD check if that name has already been
declared as an interface otherwise you get the following situation:
if (!class_exists('foobar') { // returns false
class foobar{} // fails because interface exists
}
On the one hand it is saying a class with the name 'foobar' does not
exist which is immediately followed by you cannot create a class with
the name 'foobar' as it already exists. That is not logical to me.
[2010-03-08 00:55:52] johan...@php.net
I think the error message (Cannot redeclare class) should be clearer
about classes and interfaces sharing the same namespace, which is needed
as type hints would be conflicting otherwise, but class_exists (by
default) should only check classes in my opinion. Any change should
consider that there's also interface_exists() and they should be
consistent.
[2010-03-08 00:28:39] der...@php.net
Yes, I agree.
[2010-03-08 00:23:50] tony at marston-home dot demon dot co dot uk
If an interface is a class, then it should show up in class_exists() and
get_declared_classes().
[2010-03-08 00:02:25] ka...@php.net
Thats how the OO is designed, internally is interfaces just a class with
an additional flag.
So no bug here
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=51225
--
Edit this bug report at http://bugs.php.net/bug.php?id=51225edit=1
Bug #50630 [Opn-Bgs]: Modulo on strings/floats won't work on huge numbers
Edit report at http://bugs.php.net/bug.php?id=50630edit=1 ID: 50630 Updated by: tony2...@php.net Reported by: bananen-joe at bananen-joe dot de Summary: Modulo on strings/floats won't work on huge numbers -Status: Open +Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: win32 only - Windows XP SP3 PHP Version: 5.3.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2010-01-06 06:46:18] federico dot lebron at gmail dot com The size of 90 is larger than PHP_INT_MAX, so when converting to integer (since you asked for modulo, and it gets converted to integer), you're getting undefined behavior, as per http://php.net/manual/en/language.types.integer.php . No warnings or notices will be triggered in such a case. Internally (and on this machine, with PHP compiled as 32 bit), strtol(90, NULL, 10) is being called for the string case, which is 2147483647. This is noted in the intval function's documentation, so it's expected. For the float case, (long) (unsigned long) (long long int) 90 is being casted, which is 1410065398, but this is undefined behavior. [2010-01-01 22:25:24] bananen-joe at bananen-joe dot de Description: If you use the modulo operator on huge numbers (which cannot be converted into integers) you get a strange result. Even not error is reported. Reproduce code: --- error_reporting(E_ALL); $number = '90'; echo $number % 10 = , $number % 10, br; $number = 90; echo $number % 10 = , $number % 10, br; $number = '0'; echo $number % 10 = , $number % 10, br; $number = (float) 0; echo $number % 10 = , $number % 10, br; Expected result: 90 % 10 = 0 (or even an error notice/warning) 90 % 10 = 0 (or even an error notice/warning) 0 % 10 = 0 0 % 10 = 0 Actual result: -- 90 % 10 = 7 90 % 10 = 8 0 % 10 = 0 0 % 10 = 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=50630edit=1
Bug #50432 [Opn-Fbk]: setting for display_errors not being honored
Edit report at http://bugs.php.net/bug.php?id=50432edit=1 ID: 50432 Updated by: tony2...@php.net Reported by: bill dot mcclendon at digiconllc dot com Summary: setting for display_errors not being honored -Status: Open +Status: Feedback Type: Bug Package: PHP options/info functions Operating System: win32 only - Windows Server 2008 PHP Version: 5.3.1 New Comment: Restart your web-server and check phpinfo() again. Previous Comments: [2009-12-13 01:19:05] bill dot mcclendon at digiconllc dot com It may be a Windows installation issue - but the installation was via the install version from the windows.php.net download link. So, it's built into it. [2009-12-11 22:35:36] j...@php.net Quite likely some installation issue on windows, works fine on *nix. [2009-12-11 20:42:18] bill dot mcclendon at digiconllc dot com Am I sure? You did see the reference to phpinfo() - right? It shows the one and only php.ini file that exists on this server and instance and it's the one I edited. Bill [2009-12-09 20:28:42] paj...@php.net Are you sure the right php.ini is loaded? [2009-12-09 20:11:04] bill dot mcclendon at digiconllc dot com Description: When using 5.3.1 for Windows (VC6 non thread safe) build, the php.ini settings for display_errors=Off is ignored and E_NOTICE messages display in the web page results from PHP. This can also be seen via phpinfo() which shows the setting On. If I run php -i from the command window, the setting correctly shows Off. Windows Server 2008 IIS 7.0 PHP 5.3.1 (binary .msi install from windows.php.net) Reproduce code: --- ? phpinfo();? Expected result: display_errors Off Actual result: -- display_errors On -- Edit this bug report at http://bugs.php.net/bug.php?id=50432edit=1
Bug #50101 [Opn-Csd]: [PATCH] - Avoid name clash between global and local variable
Edit report at http://bugs.php.net/bug.php?id=50101edit=1
ID: 50101
Updated by: tony2...@php.net
Reported by: yoarvi at gmail dot com
Summary: [PATCH] - Avoid name clash between global and local
variable
-Status: Open
+Status: Closed
Type: Bug
Package: Compile Failure
Operating System: Solaris 5.10 (SPARC)
PHP Version: 6SVN-2009-11-06 (SVN)
-Assigned To:
+Assigned To: tony2001
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:
[2010-06-08 15:27:31] tony2...@php.net
Automatic comment from SVN on behalf of tony2001
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=300276
Log: fix bug #50101 (name clash between global and local variable)
[2009-11-06 12:41:17] yoarvi at gmail dot com
Description:
TSRM/tsrm_virtual_cwd.c uses the same name for a global variable as well
as for arguments to a function (when #ifndef ZTS).
#ifdef ZTS
ts_rsrc_id cwd_globals_id;
#else
virtual_cwd_globals cwd_globals;
#endif
static void cwd_globals_ctor(virtual_cwd_globals *cwd_globals TSRMLS_DC)
/* {{{ */
static void cwd_globals_dtor(virtual_cwd_globals *cwd_globals TSRMLS_DC)
/* {{{ */
Reproduce code:
---
The following patch avoids the name clash:
diff -r f2728a22d214 TSRM/tsrm_virtual_cwd.c
--- a/TSRM/tsrm_virtual_cwd.c Fri Nov 06 18:07:39 2009 +0530
+++ b/TSRM/tsrm_virtual_cwd.c Fri Nov 06 18:13:55 2009 +0530
@@ -262,19 +262,19 @@
}
/* }}} */
-static void cwd_globals_ctor(virtual_cwd_globals *cwd_globals
TSRMLS_DC) /* {{{ */
+static void cwd_globals_ctor(virtual_cwd_globals *cwdg TSRMLS_DC) /*
{{{ */
{
- CWD_STATE_COPY(cwd_globals-cwd, main_cwd_state);
- cwd_globals-realpath_cache_size = 0;
- cwd_globals-realpath_cache_size_limit = REALPATH_CACHE_SIZE;
- cwd_globals-realpath_cache_ttl = REALPATH_CACHE_TTL;
- memset(cwd_globals-realpath_cache, 0,
sizeof(cwd_globals-realpath_cache));
+ CWD_STATE_COPY(cwdg-cwd, main_cwd_state);
+ cwdg-realpath_cache_size = 0;
+ cwdg-realpath_cache_size_limit = REALPATH_CACHE_SIZE;
+ cwdg-realpath_cache_ttl = REALPATH_CACHE_TTL;
+ memset(cwdg-realpath_cache, 0, sizeof(cwdg-realpath_cache));
}
/* }}} */
-static void cwd_globals_dtor(virtual_cwd_globals *cwd_globals
TSRMLS_DC) /* {{{ */
+static void cwd_globals_dtor(virtual_cwd_globals *cwdg TSRMLS_DC) /*
{{{ */
{
- CWD_STATE_FREE(cwd_globals-cwd);
+ CWD_STATE_FREE(cwdg-cwd);
realpath_cache_clean(TSRMLS_C);
}
/* }}} */
Expected result:
Disambiguity.
--
Edit this bug report at http://bugs.php.net/bug.php?id=50101edit=1
Bug #49479 [Opn-Fbk]: move_uploaded_file is dead
Edit report at http://bugs.php.net/bug.php?id=49479edit=1 ID: 49479 Updated by: tony2...@php.net Reported by: elmue at gmx dot de Summary: move_uploaded_file is dead -Status: Open +Status: Feedback Type: Bug Package: Filesystem function related Operating System: Windows PHP Version: 6SVN-2009-09-06 (snap) New Comment: 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. Previous Comments: [2009-09-06 01:13:27] elmue at gmx dot de Description: On PHP 6 VC6 from 3.sept.2009 the function move_uploaded_file() is completely dead. Tested on Windows XP with Xampp, Apache 2.2.9 is_file($_FILES[UploadFile][tmp_name]) returns true that means that the files has been uploaded correctly. The array $_FILES is filled with correct values. The destination file for move_uploaded_file() is a valid path with filename but the file is never moved. The same script works fine on PHP 5. -- Edit this bug report at http://bugs.php.net/bug.php?id=49479edit=1
Bug #49633 [Opn-Fbk]: $_FILES cannot be accessed
Edit report at http://bugs.php.net/bug.php?id=49633edit=1 ID: 49633 Updated by: tony2...@php.net Reported by: elmue at gmx dot de Summary: $_FILES cannot be accessed -Status: Open +Status: Feedback Type: Bug Package: Variables related Operating System: Windows PHP Version: 6SVN-2009-09-22 (snap) New Comment: 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. Previous Comments: [2009-09-22 21:23:17] elmue at gmx dot de Description: In version 22 sep 2009: print_r($_FILES); throws: Failed to decode _FILES array and Could not convert binary string to Unicode string (converter UTF-8 failed on bytes (0xF3) at offset 60) But there is no character F3 in the filename! -- Edit this bug report at http://bugs.php.net/bug.php?id=49633edit=1
Bug #49476 [Opn-Fbk]: $_ENV does not work
Edit report at http://bugs.php.net/bug.php?id=49476edit=1 ID: 49476 Updated by: tony2...@php.net Reported by: elmu at gmx dot de Summary: $_ENV does not work -Status: Open +Status: Feedback Type: Bug Package: Variables related Operating System: Windows PHP Version: 6SVN-2009-09-05 (snap) New Comment: Please try using this snapshot: http://snaps.php.net/php-trunk-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-09-22 21:19:57] elmue at gmx dot de Hello In version 22 sep 2009 it is even worse: print_r($_FILES); throws: Failed to decode _FILES array The last time I tested on PHP6 this did work. Now its broken. [2009-09-22 21:03:52] elmue at gmx dot de I repeated the test on build from 22 sep 2009 and the result is the same $_ENV[OS] $_ENV[PROCESSOR_IDENTIFIER] $_ENV[COMPUTERNAME] are empty. Even a print_r($_ENV) shows: Array ( ) This cannot be caused by input encoding because these variables have no special characters in them. On PHP5 the same array has plenty content! [2009-09-06 20:31:59] paj...@php.net ENV works just fine here. But there are changes about input encoding that have not been test at all. And all in all, the current status of php6 is not tested at all, unstable and needs heavy work to get to something usable (usable != stable). [2009-09-06 19:48:16] elmu at gmx dot de Note: It seems that the current PHP 6 has not yet been tested on Windows. All the bugs I found are related to filesystem or operation system. [2009-09-05 23:57:06] elmu at gmx dot de Sorry I wanted to say $_SERVER[SERVER_SIGNATURE] works on both. 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=49476 -- Edit this bug report at http://bugs.php.net/bug.php?id=49476edit=1
