Bug #61873 [Com]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873&edit=1
ID: 61873
Comment by: phpmpan at mpan dot pl
Reported by:dcb at insomniacsoft dot com
Summary:proc_get_status always returns exitcode -1
Status: Feedback
Type: Bug
Package:Program Execution
Operating System: Linux
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
Maybe strace shows something interesting?
strace -f php -r '$descriptorspec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("file", "/tmp/error-output.txt", "a")
);
$p = proc_open("/tmp/te", $descriptorspec, $pipes, "/tmp");
sleep(1);
fclose($pipes[0]);fclose($pipes[1]);
$s = proc_get_status($p);
print_r($s);' 2>&1 | grep '/tmp/te'
Previous Comments:
[2012-04-29 03:51:46] larue...@php.net
what about call "/bin/ls" instead of /tmp/te?
[2012-04-29 00:18:47] dcb at insomniacsoft dot com
I've checked that, the script executes fine and besides I actually discovered
the
issue while working with the symfony/Process classes. On php 5.3.6 all the
tests
pass, but on the same machine, with the same config (just different paths) all
versions starting from 5.4.0 fail the symfony/Process unit tests related to the
exit code.
[2012-04-28 14:22:18] reeze dot xia at gmail dot com
I can't reproduce it either. Any error log in /tmp/error-output.txt?
maybe /tmp/te did't have execution permission?
[2012-04-28 11:30:29] dcb at insomniacsoft dot com
I forgot to mention that on the same machines php 5.3 gives the expected
results.
[2012-04-28 11:25:59] dcb at insomniacsoft dot com
I've just tried now with latest snapshot and I'm getting the same result.
I have this problem occurring on 2 64bit Ubuntu machines.
What OS have you tried to reproduce this on?
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=61873
--
Edit this bug report at https://bugs.php.net/bug.php?id=61873&edit=1
Bug #61873 [Opn->Fbk]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873&edit=1 ID: 61873 Updated by: larue...@php.net Reported by:dcb at insomniacsoft dot com Summary:proc_get_status always returns exitcode -1 -Status: Open +Status: Feedback Type: Bug Package:Program Execution Operating System: Linux PHP Version:5.4.1 Block user comment: N Private report: N Previous Comments: [2012-04-29 03:51:46] larue...@php.net what about call "/bin/ls" instead of /tmp/te? [2012-04-29 00:18:47] dcb at insomniacsoft dot com I've checked that, the script executes fine and besides I actually discovered the issue while working with the symfony/Process classes. On php 5.3.6 all the tests pass, but on the same machine, with the same config (just different paths) all versions starting from 5.4.0 fail the symfony/Process unit tests related to the exit code. [2012-04-28 14:22:18] reeze dot xia at gmail dot com I can't reproduce it either. Any error log in /tmp/error-output.txt? maybe /tmp/te did't have execution permission? [2012-04-28 11:30:29] dcb at insomniacsoft dot com I forgot to mention that on the same machines php 5.3 gives the expected results. [2012-04-28 11:25:59] dcb at insomniacsoft dot com I've just tried now with latest snapshot and I'm getting the same result. I have this problem occurring on 2 64bit Ubuntu machines. What OS have you tried to reproduce this on? 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=61873 -- Edit this bug report at https://bugs.php.net/bug.php?id=61873&edit=1
Bug #61873 [Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873&edit=1 ID: 61873 Updated by: larue...@php.net Reported by:dcb at insomniacsoft dot com Summary:proc_get_status always returns exitcode -1 Status: Open Type: Bug Package:Program Execution Operating System: Linux PHP Version:5.4.1 Block user comment: N Private report: N New Comment: what about call "/bin/ls" instead of /tmp/te? Previous Comments: [2012-04-29 00:18:47] dcb at insomniacsoft dot com I've checked that, the script executes fine and besides I actually discovered the issue while working with the symfony/Process classes. On php 5.3.6 all the tests pass, but on the same machine, with the same config (just different paths) all versions starting from 5.4.0 fail the symfony/Process unit tests related to the exit code. [2012-04-28 14:22:18] reeze dot xia at gmail dot com I can't reproduce it either. Any error log in /tmp/error-output.txt? maybe /tmp/te did't have execution permission? [2012-04-28 11:30:29] dcb at insomniacsoft dot com I forgot to mention that on the same machines php 5.3 gives the expected results. [2012-04-28 11:25:59] dcb at insomniacsoft dot com I've just tried now with latest snapshot and I'm getting the same result. I have this problem occurring on 2 64bit Ubuntu machines. What OS have you tried to reproduce this on? [2012-04-28 04:00:11] larue...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I can not reproduce this with php5.4-trunk. 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=61873 -- Edit this bug report at https://bugs.php.net/bug.php?id=61873&edit=1
Bug #61873 [Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873&edit=1
ID: 61873
User updated by:dcb at insomniacsoft dot com
Reported by:dcb at insomniacsoft dot com
Summary:proc_get_status always returns exitcode -1
Status: Open
Type: Bug
Package:Program Execution
Operating System: Linux
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
I've checked that, the script executes fine and besides I actually discovered
the
issue while working with the symfony/Process classes. On php 5.3.6 all the
tests
pass, but on the same machine, with the same config (just different paths) all
versions starting from 5.4.0 fail the symfony/Process unit tests related to the
exit code.
Previous Comments:
[2012-04-28 14:22:18] reeze dot xia at gmail dot com
I can't reproduce it either. Any error log in /tmp/error-output.txt?
maybe /tmp/te did't have execution permission?
[2012-04-28 11:30:29] dcb at insomniacsoft dot com
I forgot to mention that on the same machines php 5.3 gives the expected
results.
[2012-04-28 11:25:59] dcb at insomniacsoft dot com
I've just tried now with latest snapshot and I'm getting the same result.
I have this problem occurring on 2 64bit Ubuntu machines.
What OS have you tried to reproduce this on?
[2012-04-28 04:00:11] larue...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this with php5.4-trunk.
[2012-04-28 03:13:59] dcb at insomniacsoft dot com
Description:
Since PHP 5.4.0 the proc_get_status and proc_close functions always return -1
as
exitcode.
Test script:
---
$descriptorspec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("file", "/tmp/error-output.txt", "a")
);
$p = proc_open('/tmp/te', $descriptorspec, $pipes, '/tmp');
sleep(1);
fclose($pipes[0]);fclose($pipes[1]);
$s = proc_get_status($p);
print_r($s);
/tmp/te is simply:
#!/bin/bash
exit 0
Expected result:
Array
(
[command] => /tmp/te
[pid] => 12376
[running] =>
[signaled] =>
[stopped] =>
[exitcode] => 0
[termsig] => 0
[stopsig] => 0
)
Actual result:
--
Array
(
[command] => /tmp/te
[pid] => 12376
[running] =>
[signaled] =>
[stopped] =>
[exitcode] => -1
[termsig] => 0
[stopsig] => 0
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61873&edit=1
Bug #61873 [Com]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873&edit=1
ID: 61873
Comment by: reeze dot xia at gmail dot com
Reported by:dcb at insomniacsoft dot com
Summary:proc_get_status always returns exitcode -1
Status: Open
Type: Bug
Package:Program Execution
Operating System: Linux
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
I can't reproduce it either. Any error log in /tmp/error-output.txt?
maybe /tmp/te did't have execution permission?
Previous Comments:
[2012-04-28 11:30:29] dcb at insomniacsoft dot com
I forgot to mention that on the same machines php 5.3 gives the expected
results.
[2012-04-28 11:25:59] dcb at insomniacsoft dot com
I've just tried now with latest snapshot and I'm getting the same result.
I have this problem occurring on 2 64bit Ubuntu machines.
What OS have you tried to reproduce this on?
[2012-04-28 04:00:11] larue...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this with php5.4-trunk.
[2012-04-28 03:13:59] dcb at insomniacsoft dot com
Description:
Since PHP 5.4.0 the proc_get_status and proc_close functions always return -1
as
exitcode.
Test script:
---
$descriptorspec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("file", "/tmp/error-output.txt", "a")
);
$p = proc_open('/tmp/te', $descriptorspec, $pipes, '/tmp');
sleep(1);
fclose($pipes[0]);fclose($pipes[1]);
$s = proc_get_status($p);
print_r($s);
/tmp/te is simply:
#!/bin/bash
exit 0
Expected result:
Array
(
[command] => /tmp/te
[pid] => 12376
[running] =>
[signaled] =>
[stopped] =>
[exitcode] => 0
[termsig] => 0
[stopsig] => 0
)
Actual result:
--
Array
(
[command] => /tmp/te
[pid] => 12376
[running] =>
[signaled] =>
[stopped] =>
[exitcode] => -1
[termsig] => 0
[stopsig] => 0
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61873&edit=1
Bug #51580 [Com]: socket_select randomly fails when used together with fork and Unix signals
Edit report at https://bugs.php.net/bug.php?id=51580&edit=1 ID: 51580 Comment by: lykillerl at gmail dot com Reported by:marco at vmsoft-gbr dot de Summary:socket_select randomly fails when used together with fork and Unix signals Status: Not a bug Type: Bug Package:PCNTL related Operating System: Debian Linux PHP Version:5.3.2 Block user comment: N Private report: N New Comment: I also have this problem, the php no crash, still running, and i use the socket_select() time out to become the looping interval, but sometime the the socket_select() failed and no wait the time out, at the same time my client cannot connect to the server during the socket_select() function was failed. Previous Comments: [2010-05-12 15:48:43] m...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php See the restart_syscalls parameter. [2010-04-17 14:50:51] marco at vmsoft-gbr dot de 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. [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 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=51580 -- Edit this bug report at https://bugs.php.net/bug.php?id=51580&edit=1
Bug #61873 [Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873&edit=1
ID: 61873
User updated by:dcb at insomniacsoft dot com
Reported by:dcb at insomniacsoft dot com
Summary:proc_get_status always returns exitcode -1
Status: Open
Type: Bug
Package:Program Execution
Operating System: Linux
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
I forgot to mention that on the same machines php 5.3 gives the expected
results.
Previous Comments:
[2012-04-28 11:25:59] dcb at insomniacsoft dot com
I've just tried now with latest snapshot and I'm getting the same result.
I have this problem occurring on 2 64bit Ubuntu machines.
What OS have you tried to reproduce this on?
[2012-04-28 04:00:11] larue...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this with php5.4-trunk.
[2012-04-28 03:13:59] dcb at insomniacsoft dot com
Description:
Since PHP 5.4.0 the proc_get_status and proc_close functions always return -1
as
exitcode.
Test script:
---
$descriptorspec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("file", "/tmp/error-output.txt", "a")
);
$p = proc_open('/tmp/te', $descriptorspec, $pipes, '/tmp');
sleep(1);
fclose($pipes[0]);fclose($pipes[1]);
$s = proc_get_status($p);
print_r($s);
/tmp/te is simply:
#!/bin/bash
exit 0
Expected result:
Array
(
[command] => /tmp/te
[pid] => 12376
[running] =>
[signaled] =>
[stopped] =>
[exitcode] => 0
[termsig] => 0
[stopsig] => 0
)
Actual result:
--
Array
(
[command] => /tmp/te
[pid] => 12376
[running] =>
[signaled] =>
[stopped] =>
[exitcode] => -1
[termsig] => 0
[stopsig] => 0
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61873&edit=1
Bug #61873 [Fbk->Opn]: proc_get_status always returns exitcode -1
Edit report at https://bugs.php.net/bug.php?id=61873&edit=1
ID: 61873
User updated by:dcb at insomniacsoft dot com
Reported by:dcb at insomniacsoft dot com
Summary:proc_get_status always returns exitcode -1
-Status: Feedback
+Status: Open
Type: Bug
Package:Program Execution
Operating System: Linux
PHP Version:5.4.1
Block user comment: N
Private report: N
New Comment:
I've just tried now with latest snapshot and I'm getting the same result.
I have this problem occurring on 2 64bit Ubuntu machines.
What OS have you tried to reproduce this on?
Previous Comments:
[2012-04-28 04:00:11] larue...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this with php5.4-trunk.
[2012-04-28 03:13:59] dcb at insomniacsoft dot com
Description:
Since PHP 5.4.0 the proc_get_status and proc_close functions always return -1
as
exitcode.
Test script:
---
$descriptorspec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("file", "/tmp/error-output.txt", "a")
);
$p = proc_open('/tmp/te', $descriptorspec, $pipes, '/tmp');
sleep(1);
fclose($pipes[0]);fclose($pipes[1]);
$s = proc_get_status($p);
print_r($s);
/tmp/te is simply:
#!/bin/bash
exit 0
Expected result:
Array
(
[command] => /tmp/te
[pid] => 12376
[running] =>
[signaled] =>
[stopped] =>
[exitcode] => 0
[termsig] => 0
[stopsig] => 0
)
Actual result:
--
Array
(
[command] => /tmp/te
[pid] => 12376
[running] =>
[signaled] =>
[stopped] =>
[exitcode] => -1
[termsig] => 0
[stopsig] => 0
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61873&edit=1
Bug #61875 [Opn->Fbk]: mbsring frequently crashing httpd.exe
Edit report at https://bugs.php.net/bug.php?id=61875&edit=1 ID: 61875 Updated by: paj...@php.net Reported by:robertassaf1 at gmail dot com Summary:mbsring frequently crashing httpd.exe -Status: Open +Status: Feedback Type: Bug Package:Apache2 related Operating System: Windows 2003 R2 SP2 32bits PHP Version:5.3.11 Block user comment: N Private report: N New Comment: Please try to increase the apache stack (httpd.conf or changing the binary default stack). Previous Comments: [2012-04-28 09:55:44] robertassaf1 at gmail dot com Description: We are facing frequent httpd.exe crashes reported in Windows 2003 event manager. It happens at least 4 to 10 times a day at random. The cause of the issue is unknown. The event manager reports the following: "Faulting application httpd.exe, version 2.2.21.0, faulting module php_mbstring.dll, version 5.3.10.0, fault address 0x0002c94c." Test script: --- Unfortunately we don't have any script to reproduce the issue as we don't know what is causing it. Actual result: -- Type of Analysis Performed Crash Analysis Machine Name INTRASRV1 Operating System Windows Server 2003 Service Pack 2 Number Of Processors 4 Process ID 3236 Process Image C:\wamp\bin\apache\apache2.2.21\bin\httpd.exe System Up-Time 9 day(s) 16:05:13 Process Up-Time 1 day(s) 21:20:02 Thread 107 - System ID 4544 Entry point msvcr90!_threadstartex Create time 4/26/2012 9:44:34 AM Time spent in user mode 0 Days 0:0:51.890 Time spent in kernel mode 0 Days 0:0:21.843 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source php_mbstring!node_new_str+c 375b82af 375b82b0 03a4e8e0 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 1463 + c php_mbstring!parse_exp+79a 03a4e940 375b8378 03a4e968 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 4835 + c php_mbstring!parse_branch+94 03a4e908 03a4e940 375b8378 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 5181 + 1d php_mbstring!parse_subexp+b2 05eff5b0 03a4e908 03a4e940 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 5223 + 12 php_mbstring!onig_parse_make_tree+c1 03a4e958 375b82a0 375b8378 375b82b0 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 5279 + 3e php_mbstring!onig_compile+87 20074780 375b82a0 375b8378 03a4ea2c c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regcomp.c @ 5169 php_mbstring!onig_new+4c 03a4ea1c 375b82a0 375b8378 000d c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regcomp.c @ 5399 + 14 php_mbstring!php_mbregex_compile_pattern+ba 000d 01794440 0001 16cb4568 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\php_mbregex.c @ 458 + 25 php_mbstring!_php_mb_regex_ereg_replace_exec+239 0003 0001 00df756a 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\php_mbregex.c @ 857 + 27 php_mbstring!zif_mb_eregi_replace+14 0003 375b7fa0 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\php_mbregex.c @ 980 + 14 php5ts!execute_internal+3a 12296958 0001 16cd77d8 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\zend\zend_execute.c @ 1273 + 2c php_xdebug_2_1_2_5_3_vc9!get_module+205c Exception Information PHP_MBSTRING!NODE_NEW_STR+CIn httpd__PID__3236__Date__04_28_2012__Time_07_04_35AM__700__First Chance Access Violation.dmp the assembly instruction at php_mbstring!node_new_str+c in c:\wamp\bin\php\php5.3.11\ext\php_mbstring.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x0100 on thread 107 Module Information Image Name: c:\wamp\bin\php\php5.3.11\ext\php_mbstring.dll Symbol Type: PDB Base address: 0x00905a4d Time Stamp: Wed Apr 25 02:20:45 2012 Checksum: 0x3100 Comments: Thanks to Tsukada Takuya, Rui Hirokawa COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: Multibyte String Functions ISAPIFilter: False File Version: 5.3.11 Managed DLL: False Internal Name: MBSTRING extension VB DLL: False Legal Copyright: Copyright © 1997-2010 The PHP Group Loaded Image Name: php_mbstring.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php_mbstring.dll Module name: php_mbstring Private Build: Single Threaded: False Product Name: PHP
[PHP-BUG] Bug #61875 [NEW]: mbsring frequently crashing httpd.exe
From: Operating system: Windows 2003 R2 SP2 32bits PHP version: 5.3.11 Package: Apache2 related Bug Type: Bug Bug description:mbsring frequently crashing httpd.exe Description: We are facing frequent httpd.exe crashes reported in Windows 2003 event manager. It happens at least 4 to 10 times a day at random. The cause of the issue is unknown. The event manager reports the following: "Faulting application httpd.exe, version 2.2.21.0, faulting module php_mbstring.dll, version 5.3.10.0, fault address 0x0002c94c." Test script: --- Unfortunately we don't have any script to reproduce the issue as we don't know what is causing it. Actual result: -- Type of Analysis Performed Crash Analysis Machine Name INTRASRV1 Operating System Windows Server 2003 Service Pack 2 Number Of Processors 4 Process ID 3236 Process Image C:\wamp\bin\apache\apache2.2.21\bin\httpd.exe System Up-Time 9 day(s) 16:05:13 Process Up-Time 1 day(s) 21:20:02 Thread 107 - System ID 4544 Entry point msvcr90!_threadstartex Create time 4/26/2012 9:44:34 AM Time spent in user mode 0 Days 0:0:51.890 Time spent in kernel mode 0 Days 0:0:21.843 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source php_mbstring!node_new_str+c 375b82af 375b82b0 03a4e8e0 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 1463 + c php_mbstring!parse_exp+79a 03a4e940 375b8378 03a4e968 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 4835 + c php_mbstring!parse_branch+94 03a4e908 03a4e940 375b8378 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 5181 + 1d php_mbstring!parse_subexp+b2 05eff5b0 03a4e908 03a4e940 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 5223 + 12 php_mbstring!onig_parse_make_tree+c1 03a4e958 375b82a0 375b8378 375b82b0 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regparse.c @ 5279 + 3e php_mbstring!onig_compile+87 20074780 375b82a0 375b8378 03a4ea2c c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regcomp.c @ 5169 php_mbstring!onig_new+4c 03a4ea1c 375b82a0 375b8378 000d c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\oniguruma\regcomp.c @ 5399 + 14 php_mbstring!php_mbregex_compile_pattern+ba 000d 01794440 0001 16cb4568 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\php_mbregex.c @ 458 + 25 php_mbstring!_php_mb_regex_ereg_replace_exec+239 0003 0001 00df756a 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\php_mbregex.c @ 857 + 27 php_mbstring!zif_mb_eregi_replace+14 0003 375b7fa0 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\ext\mbstring\php_mbregex.c @ 980 + 14 php5ts!execute_internal+3a 12296958 0001 16cd77d8 0003 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.11-ts\zend\zend_execute.c @ 1273 + 2c php_xdebug_2_1_2_5_3_vc9!get_module+205c Exception Information PHP_MBSTRING!NODE_NEW_STR+CIn httpd__PID__3236__Date__04_28_2012__Time_07_04_35AM__700__First Chance Access Violation.dmp the assembly instruction at php_mbstring!node_new_str+c in c:\wamp\bin\php\php5.3.11\ext\php_mbstring.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x0100 on thread 107 Module Information Image Name: c:\wamp\bin\php\php5.3.11\ext\php_mbstring.dll Symbol Type: PDB Base address: 0x00905a4d Time Stamp: Wed Apr 25 02:20:45 2012 Checksum: 0x3100 Comments: Thanks to Tsukada Takuya, Rui Hirokawa COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: Multibyte String Functions ISAPIFilter: False File Version: 5.3.11 Managed DLL: False Internal Name: MBSTRING extension VB DLL: False Legal Copyright: Copyright © 1997-2010 The PHP Group Loaded Image Name: php_mbstring.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php_mbstring.dll Module name: php_mbstring Private Build: Single Threaded: False Product Name: PHP Module Size: 1.98 MBytes Product Version: 5.3.11 Symbol File Name: c:\wamp\bin\php\php-debug-pack-5.3.11\php_mbstring.pdb Special Build: & -- Edit bug report at https://bugs.php.net/bug.php?id=61875&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61875&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61875&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61875&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fi
Bug #61685 [Fbk->Csd]: putenv('TZ=UTC') doesn't update timezone for localtime()
Edit report at https://bugs.php.net/bug.php?id=61685&edit=1
ID: 61685
Updated by: a...@php.net
Reported by:mattfic...@php.net
Summary:putenv('TZ=UTC') doesn't update timezone for
localtime()
-Status: Feedback
+Status: Closed
Type: Bug
Package:Calendar related
Operating System: Windows
PHP Version:5.4.0
Assigned To:ab
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-04-27 23:01:22] paj...@php.net
Anatolyi, please apply it when you can :)
[2012-04-27 22:50:14] der...@php.net
Laruence, unixtojd is not part of the date extension, so this is a value bug
report. The patch looks good, can you make a pull request against 5.3?
[2012-04-27 22:27:13] mattfic...@php.net
Newest patch fixes test to work around the new behavior of putenv("TZ=UTC") and
includes some more info about this problem.
This patch works on 5.3.11 and 5.4.1 on Windows 7 and Gentoo (both x86 and x64).
[2012-04-27 22:26:07] mattfic...@php.net
The following patch has been added/updated:
Patch Name: 61685
Revision: 1335565567
URL:
https://bugs.php.net/patch-display.php?bug=61685&patch=61685&revision=1335565567
[2012-04-10 04:38:52] larue...@php.net
- Date extension
463 - Setting the timezone with the TZ environment variable is no
longer
464supported, instead date.timezone and/or
date_default_timezone_set()
465have to be used.
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/UPGRADING?view=markup
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=61685
--
Edit this bug report at https://bugs.php.net/bug.php?id=61685&edit=1
Bug #61413 [Asn->Csd]: ext\openssl\tests\openssl_encrypt_crash.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61413&edit=1 ID: 61413 Updated by: a...@php.net Reported by:a...@php.net Summary:ext\openssl\tests\openssl_encrypt_crash.phpt fails -Status: Assigned +Status: Closed Type: Bug Package:OpenSSL related Operating System: windows PHP Version:5.3.10 -Assigned To:mattficken +Assigned To:ab 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-04-24 12:09:34] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=270a406ac94b5fc5cc9ef59fc61e3b4b95648a3e Log: Fix bug #61413 ext\openssl\tests\openssl_encrypt_crash.phpt fails 5.3 only [2012-04-02 22:55:48] mattfic...@php.net This patch passes on PHP5.3.11rc1 on Windows 7 sp1x64. It does not break for me on Linux x64 (Gentoo and Fedora 16) with PHP5.3.11rc1. [2012-03-16 11:07:56] a...@php.net fixed initializing i to zero [2012-03-16 11:07:27] a...@php.net The following patch has been added/updated: Patch Name: 61413.diff Revision: 1331896047 URL: https://bugs.php.net/patch-display.php?bug=61413&patch=61413.diff&revision=1331896047 [2012-03-16 10:41:58] a...@php.net Description: The test fails with the message "variable 'i' used without being initialized" Expected result: test pass Actual result: -- test fail, the diff is: 002- string(4) "done" -- Edit this bug report at https://bugs.php.net/bug.php?id=61413&edit=1
Bug #51329 [Nab->Wfx]: call_user_func_array() crashes with autoload in recursive calls
Edit report at https://bugs.php.net/bug.php?id=51329&edit=1
ID: 51329
Updated by: larue...@php.net
Reported by:gergely dot fabian at radix-technologies dot com
Summary:call_user_func_array() crashes with autoload in
recursive calls
-Status: Not a bug
+Status: Wont fix
Type: Bug
Package:Reproducible crash
Operating System: Ubuntu
PHP Version:5.2.13
Block user comment: N
Private report: N
New Comment:
Since 5.2 is not supported anymore, so I only commit the patch here.
You should always upgrade to a decent version of PHP :)
Previous Comments:
[2012-04-28 07:25:15] larue...@php.net
The following patch has been added/updated:
Patch Name: bug51329.patch
Revision: 1335597915
URL:
https://bugs.php.net/patch-display.php?bug=51329&patch=bug51329.patch&revision=1335597915
[2010-07-09 09:48:01] ivo at danihelka dot net
I simplified the test case.
It is not needed to create the classes on disk.
Test script:
$limit = 50;
function __autoload($class_name) {
eval("
echo \"$class_name loaded\\n\";
class $class_name {
public static function execute_me(){
return \"$class_name executed\\n\";
}
}");
}
function go_deeper($limit, $i = 1){
echo call_user_func_array(array("P$i", 'execute_me'), array());
if($i < $limit) go_deeper($limit, $i+1);
}
go_deeper($limit);
echo "Success\n";
[2010-07-09 08:34:12] denis at bitrix dot ru
I have the same problem. Why is it bogus? There is no unlimit recursion!
The only workaround I found is not to use autoload.
[2010-03-22 07:40:00] gergely dot fabian at radix-technologies dot com
I have to emphasize that the use case where this bug came out was not infinite
recursion.
It is in an MVC web application framework (symfony) that a given amount of
filters (let's say 15) are one-by-one called by the filterChain's execute()
method, and then call back to filterChain->execute() (thus making a sort of
indirect recursion).
In our case if we have certain conditions true and have a 7th filter, then a
later call_user_func_array call will cause a segfault. Having less number of
filters (disabling any of them) "fixes" the bug (not reaching that amount of
recursion), as also having one more filter (making an additional recursion
step).
The second testcase reproduces this with plain PHP code.
[2010-03-22 07:24:26] gergely dot fabian at radix-technologies dot com
The infinite recursion that you mentioned also causes segfault, but it's
another case. If I remove the call_user_func_array call, and the limit of 50,
then it will segfault after around 14860 recursive calls (on my machine).
My original code (and the second version I posted) segfaults at 25/31st
recursion. That's a different amount I'd say.
If I change the second version of my testcase to jump call_user_func_array call
at 25th recursion, then it runs until 208th recursion and dies again on
call_user_func_array.
If enable though class_exists() before call_user_func_array(), then recursion
is successful for both 25th and 208th.
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=51329
--
Edit this bug report at https://bugs.php.net/bug.php?id=51329&edit=1
Bug #51329 [PATCH]: call_user_func_array() crashes with autoload in recursive calls
Edit report at https://bugs.php.net/bug.php?id=51329&edit=1
ID: 51329
Patch added by: larue...@php.net
Reported by:gergely dot fabian at radix-technologies dot com
Summary:call_user_func_array() crashes with autoload in
recursive calls
Status: Not a bug
Type: Bug
Package:Reproducible crash
Operating System: Ubuntu
PHP Version:5.2.13
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug51329.patch
Revision: 1335597915
URL:
https://bugs.php.net/patch-display.php?bug=51329&patch=bug51329.patch&revision=1335597915
Previous Comments:
[2010-07-09 09:48:01] ivo at danihelka dot net
I simplified the test case.
It is not needed to create the classes on disk.
Test script:
$limit = 50;
function __autoload($class_name) {
eval("
echo \"$class_name loaded\\n\";
class $class_name {
public static function execute_me(){
return \"$class_name executed\\n\";
}
}");
}
function go_deeper($limit, $i = 1){
echo call_user_func_array(array("P$i", 'execute_me'), array());
if($i < $limit) go_deeper($limit, $i+1);
}
go_deeper($limit);
echo "Success\n";
[2010-07-09 08:34:12] denis at bitrix dot ru
I have the same problem. Why is it bogus? There is no unlimit recursion!
The only workaround I found is not to use autoload.
[2010-03-22 07:40:00] gergely dot fabian at radix-technologies dot com
I have to emphasize that the use case where this bug came out was not infinite
recursion.
It is in an MVC web application framework (symfony) that a given amount of
filters (let's say 15) are one-by-one called by the filterChain's execute()
method, and then call back to filterChain->execute() (thus making a sort of
indirect recursion).
In our case if we have certain conditions true and have a 7th filter, then a
later call_user_func_array call will cause a segfault. Having less number of
filters (disabling any of them) "fixes" the bug (not reaching that amount of
recursion), as also having one more filter (making an additional recursion
step).
The second testcase reproduces this with plain PHP code.
[2010-03-22 07:24:26] gergely dot fabian at radix-technologies dot com
The infinite recursion that you mentioned also causes segfault, but it's
another case. If I remove the call_user_func_array call, and the limit of 50,
then it will segfault after around 14860 recursive calls (on my machine).
My original code (and the second version I posted) segfaults at 25/31st
recursion. That's a different amount I'd say.
If I change the second version of my testcase to jump call_user_func_array call
at 25th recursion, then it runs until 208th recursion and dies again on
call_user_func_array.
If enable though class_exists() before call_user_func_array(), then recursion
is successful for both 25th and 208th.
[2010-03-21 21:59:57] gergely dot fabian at radix-technologies dot com
This is not infinite recursion (is 31/25 recursion too deep?).
See my comment with putting one element to call stack "fixing" later
autoloading (2010-03-19 09:38 UTC).
This is an autoloading/call_user_func_array bug imho. Otherwise if it would be
normal for this to happen, why does class_exists() call right before the
segfaulting place fix 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
https://bugs.php.net/bug.php?id=51329
--
Edit this bug report at https://bugs.php.net/bug.php?id=51329&edit=1
Bug #52065 [Com]: Warning about open_basedir restriction while accessing a file as directory
Edit report at https://bugs.php.net/bug.php?id=52065&edit=1
ID: 52065
Comment by: nick at aussiecom dot com
Reported by:manuel at mausz dot at
Summary:Warning about open_basedir restriction while
accessing a file as directory
Status: Open
Type: Bug
Package:Safe Mode/open_basedir
Operating System: Unix
PHP Version:5.3SVN-2010-06-12 (SVN)
Block user comment: N
Private report: N
New Comment:
Why hasn't this bug been resolved? It's nearly 2 years old...
Previous Comments:
[2010-08-11 12:20:11] manuel at mausz dot at
Can someone please finally take a look at this?
[2010-06-12 14:58:01] manuel at mausz dot at
Description:
fopen_wrappers raise warning about open_basedir restriction in effect while
accessing a file as a directory. This only occurs if the file exists.
Test script:
---
# sapi/cli/php -n -d open_basedir="$(pwd)" -r
'var_dump(is_readable("myfile/doesntexist"));'
# touch myfile
# sapi/cli/php -n -d open_basedir="$(pwd)" -r
'var_dump(is_readable("myfile/doesntexist"));'
Expected result:
bool(false)
bool(false)
Actual result:
--
bool(false)
Warning: is_readable(): open_basedir restriction in effect.
File(myfile/doesntexist) is not within the allowed path(s):
(/home/manuel/php5.3-201006120030) in Command line code on line 1
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=52065&edit=1
