Bug #51580 [Fbk-Opn]: socket_select randomly crashes when used together with fork and Unix signals
Edit report at http://bugs.php.net/bug.php?id=51580edit=1 ID: 51580 User updated by: marco at vmsoft-gbr dot de Reported by: marco at vmsoft-gbr dot de Summary: socket_select randomly crashes when used together with fork and Unix signals -Status: Feedback +Status: Open Type: Bug Package: PCNTL related Operating System: Debian Linux PHP Version: 5.3.2 New Comment: PHP itself doesn't crash, the error is not fatal - and how do I make a gdb backtrace on a forked process, anyway? Previous Comments: [2010-04-17 03:51:06] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2010-04-17 02:11:01] marco at vmsoft-gbr dot de Description: When firing unix signals onto a forked process with pcntl_signal handlers active and a socket_select currently running, socket_select may crash. Run the test script with php test.php 1339, and then launch some kill -s 10 child pid on it. After some, maybe just one, kill's, the script will crash. Test script: --- http://php.pastebin.com/Td68vtMn Expected result: Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 (etc) Actual result: -- Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 ma...@vs932:~/php_daemon$ PHP Warning: socket_select(): unable to select [4]: Interrupted system call in /home/marco/php_daemon/test.php on line 39 socket_select failed: Interrupted system call end ma...@vs932:~/php_daemon$ -- Edit this bug report at http://bugs.php.net/bug.php?id=51580edit=1
Bug #51580 [Opn]: socket_select randomly crashes when used together with fork and Unix signals
Edit report at http://bugs.php.net/bug.php?id=51580edit=1 ID: 51580 User updated by: marco at vmsoft-gbr dot de Reported by: marco at vmsoft-gbr dot de Summary: socket_select randomly crashes when used together with fork and Unix signals Status: Open Type: Bug Package: PCNTL related Operating System: Debian Linux PHP Version: 5.3.2 New Comment: just ran it under gdb, it fails as expected, but as it's not segfaulting, no backtrace can be made. Previous Comments: [2010-04-17 11:06:53] marco at vmsoft-gbr dot de PHP itself doesn't crash, the error is not fatal - and how do I make a gdb backtrace on a forked process, anyway? [2010-04-17 03:51:06] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2010-04-17 02:11:01] marco at vmsoft-gbr dot de Description: When firing unix signals onto a forked process with pcntl_signal handlers active and a socket_select currently running, socket_select may crash. Run the test script with php test.php 1339, and then launch some kill -s 10 child pid on it. After some, maybe just one, kill's, the script will crash. Test script: --- http://php.pastebin.com/Td68vtMn Expected result: Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 (etc) Actual result: -- Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 ma...@vs932:~/php_daemon$ PHP Warning: socket_select(): unable to select [4]: Interrupted system call in /home/marco/php_daemon/test.php on line 39 socket_select failed: Interrupted system call end ma...@vs932:~/php_daemon$ -- Edit this bug report at http://bugs.php.net/bug.php?id=51580edit=1
Bug #49490 [Com]: XPath namespace prefix conflict
Edit report at http://bugs.php.net/bug.php?id=49490edit=1
ID: 49490
Comment by: thomas at weinert dot info
Reported by: olav dot morken at uninett dot no
Summary: XPath namespace prefix conflict
Status: Open
Type: Bug
Package: DOM XML related
Operating System: Linux (Debian)
PHP Version: 5.3.0
New Comment:
It looks like DOMXPath-evaluate()/DOMXPath-query() registers the
namespace prefixes of the given context and overrides any definition
from DOMXPath-registerNamespace(). PHP should not register any
namespaces from the context or at least prefer manual registrations over
automatic.
Reproduce code:
---
$dom = new DOMDocument();
$dom-loadXML(
'foobara:foo xmlns:a=urn:a'.
'b:bar xmlns:b=urn:b//a:foo'.
'/foobar'
);
$xpath = new DOMXPath($dom);
//get context node and check a:foo
$context = $dom-documentElement-firstChild;
var_dump($context-tagName);
// try to override the context node
$xpath-registerNamespace('a', 'urn:b');
var_dump(
$xpath-evaluate(
'descendant-or-self::a:*',
$context
)-item(0)-tagName
);
// use a prefix not used in context
$xpath-registerNamespace('prefix', 'urn:b');
var_dump(
$xpath-evaluate(
'descendant-or-self::prefix:*',
$context
)-item(0)-tagName
);
Expected result:
string(5) a:foo
string(5) b:bar
string(5) b:bar
Actual result:
string(5) a:foo
string(5) a:foo
string(5) b:bar
Previous Comments:
[2009-09-07 08:41:26] olav dot morken at uninett dot no
Description:
When processing an XML document with namespaces, an XPath query for a
node with a different namespace but the same namespace prefix fails.
This appears to be a conflict between the XPath namespaces and the
document namespaces. It works if either:
- The prefix in the query is replaced with a prefix that doesn't
exist in the document.
- If the prefix in the query matches the prefix in the document.
This was tested with:
- PHP 5.3 from debian experimental: 5.3.0-3
- libxml2 2.7.3.dfsg-2.1
Reproduce code:
---
$doc = new DOMDocument();
$doc-loadXML('prefix:root xmlns:prefix=urn:a /');
$xp = new DOMXPath($doc);
$xp-registerNamespace('prefix', 'urn:b');
echo($xp-query('//prefix:root')-length . \n);
Expected result:
It should not find the root node, since we ask for a node in a different
prefix. I.e. it should print '0'.
Actual result:
--
It finds the root node, i.e. it prints '1'.
--
Edit this bug report at http://bugs.php.net/bug.php?id=49490edit=1
Bug #51580 [Opn-Fbk]: socket_select randomly crashes when used together with fork and Unix signals
Edit report at http://bugs.php.net/bug.php?id=51580edit=1 ID: 51580 Updated by: paj...@php.net Reported by: marco at vmsoft-gbr dot de Summary: socket_select randomly crashes when used together with fork and Unix signals -Status: Open +Status: Feedback Type: Bug Package: PCNTL related Operating System: Debian Linux PHP Version: 5.3.2 New Comment: Can you try to generate a coredump and use it later to get a bt: http://stackoverflow.com/questions/17965/generate-a-core-dump-in-linux Previous Comments: [2010-04-17 11:13:18] marco at vmsoft-gbr dot de just ran it under gdb, it fails as expected, but as it's not segfaulting, no backtrace can be made. [2010-04-17 11:06:53] marco at vmsoft-gbr dot de PHP itself doesn't crash, the error is not fatal - and how do I make a gdb backtrace on a forked process, anyway? [2010-04-17 03:51:06] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2010-04-17 02:11:01] marco at vmsoft-gbr dot de Description: When firing unix signals onto a forked process with pcntl_signal handlers active and a socket_select currently running, socket_select may crash. Run the test script with php test.php 1339, and then launch some kill -s 10 child pid on it. After some, maybe just one, kill's, the script will crash. Test script: --- http://php.pastebin.com/Td68vtMn Expected result: Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 (etc) Actual result: -- Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 ma...@vs932:~/php_daemon$ PHP Warning: socket_select(): unable to select [4]: Interrupted system call in /home/marco/php_daemon/test.php on line 39 socket_select failed: Interrupted system call end ma...@vs932:~/php_daemon$ -- Edit this bug report at http://bugs.php.net/bug.php?id=51580edit=1
Bug #51580 [Fbk-Opn]: socket_select randomly crashes when used together with fork and Unix signals
Edit report at http://bugs.php.net/bug.php?id=51580edit=1 ID: 51580 User updated by: marco at vmsoft-gbr dot de Reported by: marco at vmsoft-gbr dot de Summary: socket_select randomly crashes when used together with fork and Unix signals -Status: Feedback +Status: Open Type: Bug Package: PCNTL related Operating System: Debian Linux PHP Version: 5.3.2 New Comment: Uh, the PHP *process* doesn't crash, so no corefile. Sorry, was bad choice of words by me. Anyway, whatever happens with socket_select there should not happen... but how to backtrace that one without an actual crash? Previous Comments: [2010-04-17 13:23:08] paj...@php.net Can you try to generate a coredump and use it later to get a bt: http://stackoverflow.com/questions/17965/generate-a-core-dump-in-linux [2010-04-17 11:13:18] marco at vmsoft-gbr dot de just ran it under gdb, it fails as expected, but as it's not segfaulting, no backtrace can be made. [2010-04-17 11:06:53] marco at vmsoft-gbr dot de PHP itself doesn't crash, the error is not fatal - and how do I make a gdb backtrace on a forked process, anyway? [2010-04-17 03:51:06] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2010-04-17 02:11:01] marco at vmsoft-gbr dot de Description: When firing unix signals onto a forked process with pcntl_signal handlers active and a socket_select currently running, socket_select may crash. Run the test script with php test.php 1339, and then launch some kill -s 10 child pid on it. After some, maybe just one, kill's, the script will crash. Test script: --- http://php.pastebin.com/Td68vtMn Expected result: Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 (etc) Actual result: -- Installing signal handlers Installing handler for signal 15 Installing handler for signal 10 child-pid 20030 running ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 got signal 10 ma...@vs932:~/php_daemon$ kill -s 10 20030 ma...@vs932:~/php_daemon$ PHP Warning: socket_select(): unable to select [4]: Interrupted system call in /home/marco/php_daemon/test.php on line 39 socket_select failed: Interrupted system call end ma...@vs932:~/php_daemon$ -- Edit this bug report at http://bugs.php.net/bug.php?id=51580edit=1
Bug #51580 [Opn-Fbk]: socket_select randomly crashes when used together with fork and Unix signals
Edit report at http://bugs.php.net/bug.php?id=51580edit=1 ID: 51580 Updated by: paj...@php.net Reported by: marco at vmsoft-gbr dot de Summary: socket_select randomly crashes when used together with fork and Unix signals -Status: Open +Status: Feedback Type: Bug Package: PCNTL related Operating System: Debian Linux PHP Version: 5.3.2 New Comment: If it crashes then linux should be able to generate a core dump file (without gdb). You can then use it to generate a back trace. Previous Comments: [2010-04-17 13:39:33] marco at vmsoft-gbr dot de Uh, the PHP *process* doesn't crash, so no corefile. Sorry, was bad choice of words by me. Anyway, whatever happens with socket_select there should not happen... but how to backtrace that one without an actual crash? [2010-04-17 13:23:08] paj...@php.net Can you try to generate a coredump and use it later to get a bt: http://stackoverflow.com/questions/17965/generate-a-core-dump-in-linux [2010-04-17 11:13:18] marco at vmsoft-gbr dot de just ran it under gdb, it fails as expected, but as it's not segfaulting, no backtrace can be made. [2010-04-17 11:06:53] marco at vmsoft-gbr dot de PHP itself doesn't crash, the error is not fatal - and how do I make a gdb backtrace on a forked process, anyway? [2010-04-17 03:51:06] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. 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=51580 -- Edit this bug report at http://bugs.php.net/bug.php?id=51580edit=1
Bug #51580 [Fbk-Opn]: socket_select randomly crashes when used together with fork and Unix signals
Edit report at http://bugs.php.net/bug.php?id=51580edit=1 ID: 51580 User updated by: marco at vmsoft-gbr dot de Reported by: marco at vmsoft-gbr dot de Summary: socket_select randomly crashes when used together with fork and Unix signals -Status: Feedback +Status: Open Type: Bug Package: PCNTL related Operating System: Debian Linux PHP Version: 5.3.2 New Comment: It doesn't crash in the literal sense, as I said before this was a mistake in word choosing. So it's technically something other than a crash, but I dunno how to properly call it. It's a bug, that's the only thing thats sure. Previous Comments: [2010-04-17 13:46:57] paj...@php.net If it crashes then linux should be able to generate a core dump file (without gdb). You can then use it to generate a back trace. [2010-04-17 13:39:33] marco at vmsoft-gbr dot de Uh, the PHP *process* doesn't crash, so no corefile. Sorry, was bad choice of words by me. Anyway, whatever happens with socket_select there should not happen... but how to backtrace that one without an actual crash? [2010-04-17 13:23:08] paj...@php.net Can you try to generate a coredump and use it later to get a bt: http://stackoverflow.com/questions/17965/generate-a-core-dump-in-linux [2010-04-17 11:13:18] marco at vmsoft-gbr dot de just ran it under gdb, it fails as expected, but as it's not segfaulting, no backtrace can be made. [2010-04-17 11:06:53] marco at vmsoft-gbr dot de PHP itself doesn't crash, the error is not fatal - and how do I make a gdb backtrace on a forked process, anyway? 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=51580 -- Edit this bug report at http://bugs.php.net/bug.php?id=51580edit=1
[PHP-BUG] Bug #51582 [NEW]: Don't assume UINT64_C it's ever available
From: Operating system: OpenBSD 3.8 PHP version: 5.3.2 Package: Compile Failure Bug Type: Bug Bug description:Don't assume UINT64_C it's ever available Description: The new crypt_sha512.c fails to build because UINT64_C macro doesn't exist. Test script: --- Try to compile it in a OpenBSD 3.8 system. It's an oudated system, but I guess this problem can affect other POSIX systems. Expected result: Configure should check for UINT64_C macro and provide it if not found. Actual result: -- ..while compiling... .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: error: (near initialization for `K[2]') .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: warning: integer constant is too large for long type .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: error: initializer element is not constant .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: error: (near initialization for `K[3]') .../php/php-5.3.2/ext/standard/crypt_sha512.c:89: warning: integer constant is too large for long type .../php/php-5.3.2/ext/standard/crypt_sha512.c:89: error: initializer element is not constant ..etc... and build fails. -- Edit bug report at http://bugs.php.net/bug.php?id=51582edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51582r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51582r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51582r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51582r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51582r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51582r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51582r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51582r=needscript Try newer version: http://bugs.php.net/fix.php?id=51582r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51582r=support Expected behavior: http://bugs.php.net/fix.php?id=51582r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51582r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51582r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51582r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51582r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51582r=dst IIS Stability: http://bugs.php.net/fix.php?id=51582r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51582r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51582r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51582r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51582r=mysqlcfg
Bug #51582 [Opn-Fbk]: Don't assume UINT64_C it's ever available
Edit report at http://bugs.php.net/bug.php?id=51582edit=1 ID: 51582 Updated by: paj...@php.net Reported by: reidrac at usebox dot net Summary: Don't assume UINT64_C it's ever available -Status: Open +Status: Feedback Type: Bug Package: Compile Failure Operating System: OpenBSD 3.8 PHP Version: 5.3.2 -Assigned To: +Assigned To: pajoye New Comment: If you can provide a patch to fix it for openbsd 3.8, please do. I don't have access to this version and it works with more decent releases. Previous Comments: [2010-04-17 17:06:45] reidrac at usebox dot net Description: The new crypt_sha512.c fails to build because UINT64_C macro doesn't exist. Test script: --- Try to compile it in a OpenBSD 3.8 system. It's an oudated system, but I guess this problem can affect other POSIX systems. Expected result: Configure should check for UINT64_C macro and provide it if not found. Actual result: -- ..while compiling... .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: error: (near initialization for `K[2]') .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: warning: integer constant is too large for long type .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: error: initializer element is not constant .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: error: (near initialization for `K[3]') .../php/php-5.3.2/ext/standard/crypt_sha512.c:89: warning: integer constant is too large for long type .../php/php-5.3.2/ext/standard/crypt_sha512.c:89: error: initializer element is not constant ..etc... and build fails. -- Edit this bug report at http://bugs.php.net/bug.php?id=51582edit=1
Bug #51582 [Fbk-Opn]: Don't assume UINT64_C it's ever available
Edit report at http://bugs.php.net/bug.php?id=51582edit=1 ID: 51582 User updated by: reidrac at usebox dot net Reported by: reidrac at usebox dot net Summary: Don't assume UINT64_C it's ever available -Status: Feedback +Status: Open Type: Bug Package: Compile Failure Operating System: OpenBSD 3.8 PHP Version: 5.3.2 Assigned To: pajoye New Comment: I just put the macro definition from a Linux include file in the beginning of the crypt_sha512.c file, just for the record: #define UINT64_C(value) __CONCAT(value, ULL) If it builds in recent versions I think it's not worth the effort of modifying configure just for an outdated version of OpenBSD. I hope that if someone has a similar problem can find this bug report, so you can close the bug. Thank! Previous Comments: [2010-04-17 17:09:15] paj...@php.net If you can provide a patch to fix it for openbsd 3.8, please do. I don't have access to this version and it works with more decent releases. [2010-04-17 17:06:45] reidrac at usebox dot net Description: The new crypt_sha512.c fails to build because UINT64_C macro doesn't exist. Test script: --- Try to compile it in a OpenBSD 3.8 system. It's an oudated system, but I guess this problem can affect other POSIX systems. Expected result: Configure should check for UINT64_C macro and provide it if not found. Actual result: -- ..while compiling... .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: error: (near initialization for `K[2]') .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: warning: integer constant is too large for long type .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: error: initializer element is not constant .../php/php-5.3.2/ext/standard/crypt_sha512.c:88: error: (near initialization for `K[3]') .../php/php-5.3.2/ext/standard/crypt_sha512.c:89: warning: integer constant is too large for long type .../php/php-5.3.2/ext/standard/crypt_sha512.c:89: error: initializer element is not constant ..etc... and build fails. -- Edit this bug report at http://bugs.php.net/bug.php?id=51582edit=1
Bug #21513 [Com]: shutdown functions not executed if timed out
Edit report at http://bugs.php.net/bug.php?id=21513edit=1
ID: 21513
Comment by: reidrac at usebox dot net
Reported by: ceeam at mail dot ru
Summary: shutdown functions not executed if timed out
Status: Closed
Type: Bug
Package: Scripting Engine problem
Operating System: win32 (only)
PHP Version: 4CVS, 5CVS
Assigned To: zeev
New Comment:
I'm having the freeze problem in PHP 5.3.2 (was PASS in 5.3.1).
Previous Comments:
[2004-02-12 13:07:46] xuefer at 21cn dot com
compiled under cygwin
[Xuefer php4]$ ./sapi/cli/php.exe -v
PHP 4.3.5RC3-dev (cli) (built: Feb 13 2004 01:29:25)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
[Xuefer php4]$ make test
.
PASS Testing register_shutdown_function() [tests/func/005.phpt]
- freeze here
it's running 005a.phpt
[Xuefer php4]$ sapi/cli/php -d max_execution_time=1 -r
'set_time_limit(1); for(;;) {}'
[Xuefer php4]$ sapi/cli/php test/func/005a.phpt
both is frozen
[2004-01-19 04:52:58] z...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2003-08-04 00:24:07] wmeler at wp-sa dot pl
This is related to http://bugs.php.net/bug.php?id=16820 (see comment
from 21 Jul 2:46am CDT)
You can find my patch at http://strony.wp.pl/wp/wmeler/.
These are old issues ...
[2003-01-22 22:44:36] sni...@php.net
I can not reproduce this with PHP CGI/CLI/Apache DSO,
but Steph tested the script under windows and
got the same results as ce...@mail.ru did so this is
definately a windows-only bug.
[2003-01-22 02:09:49] ceeam at mail dot ru
sni...@php.net:
This script works just fine for me (using CLI):
[skipped]
I tested your script. The output is:
PHP Fatal error: Maximum execution time of 1 second exceeded in
c:\exp.php on line 16
PHP Fatal error: Maximum execution time of 1 second exceeded in
c:\exp.php on line 7
test.log contains only one Start line.
I tried with both my own (pretty much cleaned up) php.ini and
recommended php.ini.
I suspect it is only Windows-related problem.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=21513
--
Edit this bug report at http://bugs.php.net/bug.php?id=21513edit=1
[PHP-BUG] Bug #51583 [NEW]: Bus error due to wrong alignment in mysqlnd
From:
Operating system: Solaris Sparc
PHP version: 5.3.2
Package: MySQL related
Bug Type: Bug
Bug description:Bus error due to wrong alignment in mysqlnd
Description:
Using any of pdo-mysql, mysqli or mysql against mysqlnd results in a bus
error on Solaris Sparc. This is due to a wrong alignment assumption that
produces crashes because Sparc is strict about alignment.
The resulting core inspected via GDB shows:
Core was generated by `bin/php -c lib/php.ini mysql.php'.
Program terminated with signal 10, Bus error.
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928, buf=0xffbeee63
, count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
281 STORE_HEADER_SIZE(safe_storage, p);
(gdb) bt full
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928, buf=0xffbeee63
, count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
safe_buf = \000\000\000
net = (MYSQLND_NET *) 0x669370
old_chunk_size = 8192
ret = 0
packets_sent = 1
left = 1
p = (zend_uchar *) 0xffbeee63
compress_buf = (zend_uchar *) 0x0
to_be_sent = 1
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8, conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
buffer = \000\000\000\000\001
net = (MYSQLND_NET *) 0x669370
written = value optimized out
#2 0x00272154 in php_mysqlnd_conn_simple_command_pub (conn=0x669928,
command=COM_QUIT, arg=value optimized out, arg_len=value optimized out,
ok_packet=PROT_LAST,
silent=1 '\001', ignore_upsert_status=1 '\001') at
/some/path/php53/ext/mysqlnd/mysqlnd.c:380
_p_s = (MYSQLND_STATS *) 0x7efa10
ret = value optimized out
cmd_packet = (MYSQLND_PACKET_COMMAND *) 0x6692b8
#3 0x0026f920 in mysqlnd_send_close (conn=0x669928) at
/some/path/php53/ext/mysqlnd/mysqlnd.c:1393
ret = value optimized out
#4 0x00270560 in php_mysqlnd_conn_close_pub (conn=0x669928,
close_type=value optimized out)
at /some/path/php53/ext/mysqlnd/mysqlnd.c:1461
_p_s = (MYSQLND_STATS *) 0x7dafb8
stat = STAT_CLOSE_EXPLICIT
close_type_to_stat_map = {STAT_CLOSE_EXPLICIT, STAT_CLOSE_IMPLICIT,
STAT_CLOSE_DISCONNECT}
#5 0xfee47a70 in _close_mysql_link (rsrc=0x672150) at
/some/path/php53/ext/mysql/php_mysql.c:355
link = (php_mysql_conn *) 0x669358
handler = (void (*)(int)) 0x1
...
(gdb) print p
$1 = (zend_uchar *) 0xffbeee63
(gdb) up
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8, conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
683 written = conn-net-m.send(conn, buffer, 1
TSRMLS_CC);
(gdb) print buffer
$2 = (char (*)[5]) 0xffbeee63
Further Analysis shows:
- STORE_HEADER_SIZE() is a macro defined in the same file as:
int4store((safe_storage), (*(uint32_t *)(buffer)))
Note that buffer gets cast via (uint32_t *)
- buffer is not aligned on a 4 byte boundary, in fact it is an odd
address.
In the above example it was allocated in line 680 of
mysqlnd_wireprotocol.c,
without any alignment enforcement: char buffer[MYSQLND_HEADER_SIZE +
1];
- thus casting buffer to an (unsigned int *) crashes
Since both macros STORE_HEADER_SIZE and RESTORE_HEADER_SIZE seem to be used
in places, where there can be made no assumption about the alignment of the
buffer, the attached patch proposes to copy the header bytes as four
individual byte operations. Platform specific optimizations might be
applied, but at least the patch seems to be a robust solution. The patch
was done against trunk, same patch applies with offset to 5_3 branch.
Test script:
---
h2MySQL Test/h2
?php
ini_set ('display_errors', true);
// Enter your database connection info here
$db_server = 'myserv';
$db_port = '3306';
$db_name = 'mysql';
$db_username = 'myuser';
$db_password = 'mypass';
echo 'Connecting ...br';
$connection = mysql_connect($db_server:$db_port, $db_username,
$db_password, $db_name);
if (! $connection) {
echo brbERROR - Unable to connect to database server
'$db_server:$db_port': . mysql_error() . '/bbr';
return FALSE;
}
echo 'Host Info: ' . mysql_get_host_info() . 'br';
echo 'Server Info: ' . mysql_get_server_info() . 'br';
echo 'Protocol Info: ' . mysql_get_proto_info() . 'br';
echo 'Client Info: ' . mysql_get_client_info() . 'br';
mysql_close($connection);
?
Expected result:
h2MySQL Test/h2
Connecting ...brHost Info: sorbus-07 via TCP/IPbrServer Info:
5.0.27-standardbrProtocol Info: 10brClient Info: mysqlnd 5.0.7-dev -
091210 - $Revision: 294543 $br
Actual result:
--
h2MySQL Test/h2
Connecting ...brHost Info: sorbus-07 via TCP/IPbrServer Info:
5.0.27-standardbrProtocol Info: 10brClient Info: mysqlnd 5.0.7-dev -
091210 - $Revision: 294543 $brBus
Bug #51583 [Opn-Fbk]: Bus error due to wrong alignment in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=51583edit=1
ID: 51583
Updated by: fel...@php.net
Reported by: rainer dot jung at kippdata dot de
Summary: Bus error due to wrong alignment in mysqlnd
-Status: Open
+Status: Feedback
Type: Bug
Package: MySQL related
Operating System: Solaris Sparc
PHP Version: 5.3.2
-Assigned To:
+Assigned To: mysql
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-04-17 17:44:54] rainer dot jung at kippdata dot de
Description:
Using any of pdo-mysql, mysqli or mysql against mysqlnd results in a bus
error on Solaris Sparc. This is due to a wrong alignment assumption that
produces crashes because Sparc is strict about alignment.
The resulting core inspected via GDB shows:
Core was generated by `bin/php -c lib/php.ini mysql.php'.
Program terminated with signal 10, Bus error.
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928,
buf=0xffbeee63 , count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
281 STORE_HEADER_SIZE(safe_storage, p);
(gdb) bt full
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928,
buf=0xffbeee63 , count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
safe_buf = \000\000\000
net = (MYSQLND_NET *) 0x669370
old_chunk_size = 8192
ret = 0
packets_sent = 1
left = 1
p = (zend_uchar *) 0xffbeee63
compress_buf = (zend_uchar *) 0x0
to_be_sent = 1
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8,
conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
buffer = \000\000\000\000\001
net = (MYSQLND_NET *) 0x669370
written = value optimized out
#2 0x00272154 in php_mysqlnd_conn_simple_command_pub (conn=0x669928,
command=COM_QUIT, arg=value optimized out, arg_len=value optimized
out, ok_packet=PROT_LAST,
silent=1 '\001', ignore_upsert_status=1 '\001') at
/some/path/php53/ext/mysqlnd/mysqlnd.c:380
_p_s = (MYSQLND_STATS *) 0x7efa10
ret = value optimized out
cmd_packet = (MYSQLND_PACKET_COMMAND *) 0x6692b8
#3 0x0026f920 in mysqlnd_send_close (conn=0x669928) at
/some/path/php53/ext/mysqlnd/mysqlnd.c:1393
ret = value optimized out
#4 0x00270560 in php_mysqlnd_conn_close_pub (conn=0x669928,
close_type=value optimized out)
at /some/path/php53/ext/mysqlnd/mysqlnd.c:1461
_p_s = (MYSQLND_STATS *) 0x7dafb8
stat = STAT_CLOSE_EXPLICIT
close_type_to_stat_map = {STAT_CLOSE_EXPLICIT,
STAT_CLOSE_IMPLICIT, STAT_CLOSE_DISCONNECT}
#5 0xfee47a70 in _close_mysql_link (rsrc=0x672150) at
/some/path/php53/ext/mysql/php_mysql.c:355
link = (php_mysql_conn *) 0x669358
handler = (void (*)(int)) 0x1
...
(gdb) print p
$1 = (zend_uchar *) 0xffbeee63
(gdb) up
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8,
conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
683 written = conn-net-m.send(conn, buffer, 1
TSRMLS_CC);
(gdb) print buffer
$2 = (char (*)[5]) 0xffbeee63
Further Analysis shows:
- STORE_HEADER_SIZE() is a macro defined in the same file as:
int4store((safe_storage), (*(uint32_t *)(buffer)))
Note that buffer gets cast via (uint32_t *)
- buffer is not aligned on a 4 byte boundary, in fact it is an odd
address.
In the above example it was allocated in line 680 of
mysqlnd_wireprotocol.c,
without any alignment enforcement: char buffer[MYSQLND_HEADER_SIZE +
1];
- thus casting buffer to an (unsigned int *) crashes
Since both macros STORE_HEADER_SIZE and RESTORE_HEADER_SIZE seem to be
used in places, where there can be made no assumption about the
alignment of the buffer, the attached patch proposes to copy the header
bytes as four individual byte operations. Platform specific
optimizations might be applied, but at least the patch seems to be a
robust solution. The patch was done against trunk, same patch applies
with offset to 5_3 branch.
Test script:
---
h2MySQL Test/h2
?php
ini_set ('display_errors', true);
// Enter your database connection info here
$db_server = 'myserv';
$db_port = '3306';
$db_name = 'mysql';
$db_username = 'myuser';
$db_password = 'mypass';
echo 'Connecting ...br';
$connection = mysql_connect($db_server:$db_port, $db_username,
$db_password, $db_name);
if (! $connection) {
echo brbERROR - Unable to connect to database server
'$db_server:$db_port': . mysql_error() . '/bbr';
return FALSE;
}
echo 'Host Info: ' . mysql_get_host_info() . 'br';
echo 'Server Info: ' . mysql_get_server_info() . 'br';
echo 'Protocol
[PHP-BUG] Bug #51584 [NEW]: FPM configure build fails to honor --with-config-file-path option
From: Operating system: Linux PHP version: 5.3SVN-2010-04-17 (SVN) Package: FPM related Bug Type: Bug Bug description:FPM configure build fails to honor --with-config-file-path option Description: When configuring FPM with --with-config-file-path it doesn't look for config file in specified location location. Instead it looks for its config in --sysconfdir. Test script: --- './configure' '--prefix=/usr' '--build=i686-pc-linux-gnu' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--prefix=/usr/lib/php5' '--mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info' '--libdir=/usr/lib/php5/lib' '--without-pear' '--disable-maintainer-zts' '--enable-bcmath' '--with-bz2' '--disable-calendar' '--with-curl' '--without-curlwrappers' '--without-enchant' '--disable-exif' '--enable-ftp' '--with-gettext' '--without-gmp' '--disable-intl' '--without-kerberos' '--enable-mbstring' '--with-mcrypt' '--without-mssql' '--with-onig=/usr' '--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl' '--without-pgsql' '--without-pspell' '--without-recode' '--enable-shmop' '--without-snmp' '--disable-soap' '--enable-sockets' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy' '--disable-tokenizer' '--disable-wddx' '--disable-xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--with-xsl' '--enable-zip' '--with-zlib' '--disable-debug' '--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile' '--with-gdbm' '--disable-inifile' '--without-qdbm' '--without-freetype-dir' '--without-t1lib' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--without-xpm-dir' '--with-gd' '--without-interbase' '--with-mysql=mysqlnd' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=mysqlnd' '--without-oci8' '--without-pdo-dblib' '--with-pdo-mysql=mysqlnd' '--without-pdo-pgsql' '--with-pdo-sqlite=/usr' '--without-pdo-odbc' '--with-readline' '--without-libedit' '--with-mm' '--with-sqlite=/usr' '--enable-sqlite-utf8' '--with-pcre-regex=/usr' '--with-pcre-dir=/usr' '--disable-cli' '--enable-fpm' '--with-libevent-dir=shared,/usr/lib' '--disable-cgi' '--disable-embed' '--without-apxs2' '--with-config-file-path=/etc/php/fpm-php5' '--with-config-file-scan-dir=/etc/php/fpm-php5/ext-active' Expected result: FPM to default look for its config file in --with-config-file-path by default Actual result: -- Looks for its config file in --sysconfdir -- Edit bug report at http://bugs.php.net/bug.php?id=51584edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51584r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51584r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51584r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51584r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51584r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51584r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51584r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51584r=needscript Try newer version: http://bugs.php.net/fix.php?id=51584r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51584r=support Expected behavior: http://bugs.php.net/fix.php?id=51584r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51584r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51584r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51584r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51584r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51584r=dst IIS Stability: http://bugs.php.net/fix.php?id=51584r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51584r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51584r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51584r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51584r=mysqlcfg
Bug #51583 [Fbk-Opn]: Bus error due to wrong alignment in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=51583edit=1
ID: 51583
User updated by: rainer dot jung at kippdata dot de
Reported by: rainer dot jung at kippdata dot de
Summary: Bus error due to wrong alignment in mysqlnd
-Status: Feedback
+Status: Open
Type: Bug
Package: MySQL related
Operating System: Solaris Sparc
PHP Version: 5.3.2
Assigned To: mysql
New Comment:
I checked the snapshot. Exactly the same problem. Please have a look at
my analysis and patch proposal. Thanks!
Previous Comments:
[2010-04-17 18:29:20] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-04-17 17:44:54] rainer dot jung at kippdata dot de
Description:
Using any of pdo-mysql, mysqli or mysql against mysqlnd results in a bus
error on Solaris Sparc. This is due to a wrong alignment assumption that
produces crashes because Sparc is strict about alignment.
The resulting core inspected via GDB shows:
Core was generated by `bin/php -c lib/php.ini mysql.php'.
Program terminated with signal 10, Bus error.
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928,
buf=0xffbeee63 , count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
281 STORE_HEADER_SIZE(safe_storage, p);
(gdb) bt full
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928,
buf=0xffbeee63 , count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
safe_buf = \000\000\000
net = (MYSQLND_NET *) 0x669370
old_chunk_size = 8192
ret = 0
packets_sent = 1
left = 1
p = (zend_uchar *) 0xffbeee63
compress_buf = (zend_uchar *) 0x0
to_be_sent = 1
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8,
conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
buffer = \000\000\000\000\001
net = (MYSQLND_NET *) 0x669370
written = value optimized out
#2 0x00272154 in php_mysqlnd_conn_simple_command_pub (conn=0x669928,
command=COM_QUIT, arg=value optimized out, arg_len=value optimized
out, ok_packet=PROT_LAST,
silent=1 '\001', ignore_upsert_status=1 '\001') at
/some/path/php53/ext/mysqlnd/mysqlnd.c:380
_p_s = (MYSQLND_STATS *) 0x7efa10
ret = value optimized out
cmd_packet = (MYSQLND_PACKET_COMMAND *) 0x6692b8
#3 0x0026f920 in mysqlnd_send_close (conn=0x669928) at
/some/path/php53/ext/mysqlnd/mysqlnd.c:1393
ret = value optimized out
#4 0x00270560 in php_mysqlnd_conn_close_pub (conn=0x669928,
close_type=value optimized out)
at /some/path/php53/ext/mysqlnd/mysqlnd.c:1461
_p_s = (MYSQLND_STATS *) 0x7dafb8
stat = STAT_CLOSE_EXPLICIT
close_type_to_stat_map = {STAT_CLOSE_EXPLICIT,
STAT_CLOSE_IMPLICIT, STAT_CLOSE_DISCONNECT}
#5 0xfee47a70 in _close_mysql_link (rsrc=0x672150) at
/some/path/php53/ext/mysql/php_mysql.c:355
link = (php_mysql_conn *) 0x669358
handler = (void (*)(int)) 0x1
...
(gdb) print p
$1 = (zend_uchar *) 0xffbeee63
(gdb) up
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8,
conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
683 written = conn-net-m.send(conn, buffer, 1
TSRMLS_CC);
(gdb) print buffer
$2 = (char (*)[5]) 0xffbeee63
Further Analysis shows:
- STORE_HEADER_SIZE() is a macro defined in the same file as:
int4store((safe_storage), (*(uint32_t *)(buffer)))
Note that buffer gets cast via (uint32_t *)
- buffer is not aligned on a 4 byte boundary, in fact it is an odd
address.
In the above example it was allocated in line 680 of
mysqlnd_wireprotocol.c,
without any alignment enforcement: char buffer[MYSQLND_HEADER_SIZE +
1];
- thus casting buffer to an (unsigned int *) crashes
Since both macros STORE_HEADER_SIZE and RESTORE_HEADER_SIZE seem to be
used in places, where there can be made no assumption about the
alignment of the buffer, the attached patch proposes to copy the header
bytes as four individual byte operations. Platform specific
optimizations might be applied, but at least the patch seems to be a
robust solution. The patch was done against trunk, same patch applies
with offset to 5_3 branch.
Test script:
---
h2MySQL Test/h2
?php
ini_set ('display_errors', true);
// Enter your database connection info here
$db_server = 'myserv';
$db_port = '3306';
$db_name = 'mysql';
$db_username = 'myuser';
$db_password = 'mypass';
echo 'Connecting ...br';
$connection = mysql_connect($db_server:$db_port, $db_username,
$db_password, $db_name);
if (! $connection) {
echo brbERROR - Unable to connect to
[PHP-BUG] Doc #51585 [NEW]: wrong description for is_prefix in SimpleXMLElement::children
From: Operating system: Irrelevant PHP version: Irrelevant Package: SimpleXML related Bug Type: Documentation Problem Bug description:wrong description for is_prefix in SimpleXMLElement::children Description: see http://jp.php.net/manual/en/simplexmlelement.children.php Test script: --- ?php $a = ab:c xmlns:b='http://www.example.com/'xyz/b:c/a; $xml = simplexml_load_string($a); print_r(1: . (string)($xml-children(b,false)-c). \n); print_r(2: . (string)($xml-children(b,true)-c) . \n); ? this correctly outputs: 1: 2:xyz Expected result: Description of is_prefix should be as follows: If is_prefix is TRUE, ns will be regarded as a prefix. If FALSE, ns will be regarded as a namespace URL. Actual result: -- Description of is_prefix is as follows: If is_prefix is TRUE, ns will be regarded as a namespace URL. If FALSE, ns will be regarded as a prefix. -- Edit bug report at http://bugs.php.net/bug.php?id=51585edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51585r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51585r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51585r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51585r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51585r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51585r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51585r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51585r=needscript Try newer version: http://bugs.php.net/fix.php?id=51585r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51585r=support Expected behavior: http://bugs.php.net/fix.php?id=51585r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51585r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51585r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51585r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51585r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51585r=dst IIS Stability: http://bugs.php.net/fix.php?id=51585r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51585r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51585r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51585r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51585r=mysqlcfg
Doc #51585 [Opn-Csd]: wrong description for is_prefix in SimpleXMLElement::children
Edit report at http://bugs.php.net/bug.php?id=51585edit=1 ID: 51585 Updated by: degeb...@php.net Reported by: himajin10 at gmail dot com Summary: wrong description for is_prefix in SimpleXMLElement::children -Status: Open +Status: Closed Type: Documentation Problem Package: SimpleXML related Operating System: Irrelevant PHP Version: Irrelevant -Assigned To: +Assigned To: degeberg 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-04-17 23:13:22] degeb...@php.net Automatic comment from SVN on behalf of degeberg Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=298133 Log: Fixed PHP bug #51585 (wrong description for is_prefix in SimpleXMLElement::children) [2010-04-17 23:03:29] himajin10 at gmail dot com Description: see http://jp.php.net/manual/en/simplexmlelement.children.php Test script: --- ?php $a = ab:c xmlns:b='http://www.example.com/'xyz/b:c/a; $xml = simplexml_load_string($a); print_r(1: . (string)($xml-children(b,false)-c). \n); print_r(2: . (string)($xml-children(b,true)-c) . \n); ? this correctly outputs: 1: 2:xyz Expected result: Description of is_prefix should be as follows: If is_prefix is TRUE, ns will be regarded as a prefix. If FALSE, ns will be regarded as a namespace URL. Actual result: -- Description of is_prefix is as follows: If is_prefix is TRUE, ns will be regarded as a namespace URL. If FALSE, ns will be regarded as a prefix. -- Edit this bug report at http://bugs.php.net/bug.php?id=51585edit=1
Bug #48387 [Com]: ArrayObject and properties serialization
Edit report at http://bugs.php.net/bug.php?id=48387edit=1
ID: 48387
Comment by: jhominal at gmail dot com
Reported by: david at grudl dot com
Summary: ArrayObject and properties serialization
Status: Assigned
Type: Bug
Package: SPL related
Operating System: *
PHP Version: 5.2.9
Assigned To: colder
New Comment:
I believe I had the same problem on PHP 5.2.13, on Debian Lenny (package
provided
by dotdeb)
Previous Comments:
[2010-02-28 10:55:10] s...@php.net
For what it's worth, the reproduce code works perfectly fine with
php5.3.0
[2009-05-25 15:46:56] david at grudl dot com
Description:
In PHP 5.2.x there are not serialized any public/protected/private
properies of ArrayObject descendants.
Reproduce code:
---
class Test extends ArrayObject
{
public $var;
}
$test = new Test;
$test-var = 'hello';
$dolly = unserialize(serialize($test));
echo $dolly-var;
Expected result:
- hello
Actual result:
--
none
--
Edit this bug report at http://bugs.php.net/bug.php?id=48387edit=1
Bug #48781 [Asn]: Cyclical garbage collector memory leak
Edit report at http://bugs.php.net/bug.php?id=48781edit=1
ID: 48781
Updated by: j...@php.net
Reported by: nate at frickenate dot com
Summary: Cyclical garbage collector memory leak
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: Debian 5.0 kernel 2.6.24-23-xen
PHP Version: 5.3.0
Assigned To: dmitry
New Comment:
I am unable to duplicate this behaviour using 5.3.2. The code given
below consistently uses 0.65 MB even up to 10 million iterations - I
pasted the output of up to 6 million, with the extended GC reporting
turned on:
?php
class User {
protected $profile;
public function __construct () {
$this-profile = new UserProfile($this);
}
public function dispose() {
$this-profile-dispose();
$this-profile = null;
}
}
class UserProfile {
private $user;
public function __construct ($user) {
$this-user = $user;
}
public function dispose() {
$this-user = null;
}
}
for ($userid = 1; ; $userid++) {
if(isset($user)) {
$user-dispose();
}
$user = new User;
if ($userid % 10 == 0)
printf(memory usage after %s users: %s MB.\n,
number_format($userid), number_format(memory_get_usage() / 1024 / 1024,
2));
continue;
}
?
memory usage after 100,000 users: 0.65 MB.
memory usage after 200,000 users: 0.65 MB.
memory usage after 300,000 users: 0.65 MB.
[snip]
memory usage after 5,700,000 users: 0.65 MB.
memory usage after 5,800,000 users: 0.65 MB.
memory usage after 5,900,000 users: 0.65 MB.
GC Statistics
-
Runs: 0
Collected: 0
Root buffer length: 0
Root buffer peak: 9
PossibleRemove from Marked
RootBuffered buffer grey
--- --
ZVAL16 7 7 0
ZOBJ 7784 1198 1198 0
Previous Comments:
[2010-01-05 19:31:01] nightstorm at tlen dot pl
I confirm, there is a true memory leak. Consider the following script,
where the references are unmounted manually with an extra dispose()
method:
?php
/*
How to use:
a) run test 1 by running code as-is
b) run test 2 by commenting out test 1, uncomment test 2
c) run test 3 by commenting out test 1 2, uncomment test 3
*/
class User {
protected
$profile;
public function __construct () {
$this-profile = new UserProfile($this);
}
public function dispose()
{
$this-profile-dispose();
$this-profile = null;
} // end dispose();
}
class UserProfile {
private
$user;
public function __construct ($user) {
$this-user = $user;
}
public function dispose()
{
$this-user = null;
} // end dispose();
}
for ($userid = 1; ; $userid++) {
if(isset($user))
{
$user-dispose();
}
$user = new User;
if ($userid % 10 == 0)
printf(memory usage after %s users: %s MB.\n,
number_format($userid), number_format(memory_get_usage() / 1024 / 1024,
2));
continue;
}
~
In this case the result is still the same (PHP 5.3.1):
memory usage after 100,000 users: 0.61 MB.
memory usage after 200,000 users: 0.61 MB.
memory usage after 300,000 users: 0.61 MB.
memory usage after 400,000 users: 0.61 MB.
memory usage after 500,000 users: 0.61 MB.
memory usage after 600,000 users: 0.61 MB.
memory usage after 700,000 users: 0.61 MB.
memory usage after 800,000 users: 0.61 MB.
memory usage after 900,000 users: 0.61 MB.
memory usage after 1,000,000 users: 0.61 MB.
memory usage after 1,100,000 users: 0.61 MB.
memory usage after 1,200,000 users: 0.61 MB.
If we enable the garbage collector and remove the dispose() method, the
used memory level begins to increase, and if we call gc_collect_cycles()
after creating a new object, the used memory increases even much faster.
On my PC, it is not able to perform display even a single control
message after 10 iterations. It stopped after approx. 33000 users:
memory usage after 30,000 users: 25.37 MB.
memory usage after 31,000 users: 26.07 MB.
memory usage after 32,000 users: 26.76 MB.
memory usage after 33,000 users: 31.46 MB.
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to
allocate 89 bytes) in /home/me/test/memleak.php on line 17
[2009-12-15 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are
