[PHP-BUG] Bug #60909 [NEW]: custom error handler throwing Exception + fatal error = no shutdown function

[tyr...@php.net]

From: tyrael
Operating system: linux
PHP version:  5.4.0RC6
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:custom error handler throwing Exception + fatal error = no 
shutdown function

Description:

first of all sorry for the weird Summary, I couldn't come up with a better
one.
it is weird.

so it seems that if you have a shutdown function callback set and a custom
error 
handler which would throw and exception and you happen to have a fatal
error, 
the shutdown function won't be called. 

See the attached script, the error handler shouldn't really do anything
here, 
because it won't be called for the fatals, but somehow it still screw
things up.

If I remove the error handler, I will see the "!!!shutdown!!!" printed.
If I put a "return false;" before the throw I will see the "!!!shutdown!!!"

printed.
If I add E_NOTICE as the $error_type to the set_error_handler call I will
see 
the "!!!shutdown!!!" printed.
If I add E_WARNING as the $error_type to the set_error_handler call I will
NOT 
see the "!!!shutdown!!!" printed.

wtf?

Test script:
---
https://bugs.php.net/bug.php?id=60909&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60909&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60909&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60909&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60909&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60909&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60909&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60909&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60909&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60909&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60909&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60909&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60909&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60909&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60909&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60909&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60909&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60909&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60909&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60909&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60909&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60909&r=mysqlcfg

Bug #52078 [Com]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=52078&edit=1

 ID: 52078
 Comment by:     tyr...@php.net
 Reported by:glen at delfi dot ee
 Summary:fileinode overflow test
 ext/standard/tests/file/fileinode_variation3.phpt
 Status: Assigned
 Type:   Bug
 Package:Filesystem function related
 Operating System:   PLD Linux
 PHP Version:5.3.2
 Assigned To:tyrael
 Block user comment: N
 Private report: N

 New Comment:

applied the original patch to the 5.4 branch also.
if you can come up with patches for the other tests I can also apply then soon, 
if 
not I will try to go through the affected tests, but that will take longer.


Previous Comments:

[2012-02-06 22:47:22] tyr...@php.net

Automatic comment from SVN on behalf of tyrael
Revision: http://svn.php.net/viewvc/?view=revision&revision=323100
Log: merging the patch from bug #52078, fixes the test on disk with huge inode 
size(fileinode() can overflow and return negative values there).


[2012-01-20 23:56:28] glen at delfi dot ee

please note that the patch provided in bug was not complete (there are more 
tests 
suffering the same deficiency), because did not get any feedback to decide to 
proceed further.

"find -name '*.phpt' | xargs grep fileinode" in source tree should give ideas 
what more to patch (and of course all inode related functions: getmyinode, 
stat, 
...)

--------
[2012-01-19 19:09:44] tyr...@php.net

I commited the %d->%i changes to trunk and 5.3, waiting for approval to commit 
it 
to 5.4 as well, I will keep the ticket open until.

http://svn.php.net/viewvc?view=revision&revision=322460

----
[2012-01-17 10:18:51] tyr...@php.net

I will look into merging this, thanks for the patch and the heads up.


[2011-11-05 20:49:17] glen at delfi dot ee

any interest of getting it fixed?

i could supply patches, if i see any interest at all on this topic from upstream




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=52078


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=52078&edit=1

Bug #60981 [Com]: Shell environment inaccessible in tests

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60981&edit=1

 ID: 60981
 Comment by:     tyr...@php.net
 Reported by:david at davidfavor dot com
 Summary:Shell environment inaccessible in tests
 Status: Assigned
 Type:   Bug
 Package:Testing related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.10
 Assigned To:danielc
 Block user comment: N
 Private report: N

 New Comment:

AFAIK getenv does work independently from variable_orders:
foo=bar php -d variables_order=GPC -r 'echo $_ENV["foo"];echo getenv("foo");'
outputs "bar" for me, so it works.

Tyrael


Previous Comments:

[2012-02-07 14:11:31] david at davidfavor dot com

That works...

So there are two doc errors...

#1) http://php.net/manual/en/reserved.variables.environment.php contains 
comments
that getenv() returns environment variables, independent of variable_orders 
setting. I've submitted a note to clarify this.

#2 http://php.net/manual/en/ini.core.php states variables_order default setting 
is "EGPCS", which is incorrect.

Both php.ini-production and php.ini-development contain "GPCS".

Best to fix both php.ini files so they match the docs.

Let me know if I should open another bug request for the doc change.

Thanks for helping me get this to work!


[2012-02-06 21:30:59] s...@php.net

Try adding E to php.ini's variables_order.


[2012-02-06 20:12:20] david at davidfavor dot com

export var=foo is the same as sourcing a file that includes...
export var=foo

Problem is no shell environment is reaching the test scripts.

Please suggest a way to turn off clearing of the environment.


[2012-02-05 19:00:29] dani...@php.net

The environment variables need to be established in a scope available all shell 
scripts.  For example, them in the ~/.bashrc script of the user executing "make 
test".

Set the variables in ~/.bashrc
source ~/.bashrc
make test 

The "source" step is only necessary in the first shell since the variables were 
not available when the shell was opened.  All future shells will have them.


[2012-02-05 18:50:42] david at davidfavor dot com

Description:

Shell environment variables are not accessible via getenv() during tests.

Test script:
---
export MYSQL_TEST_PASSWD=...

make test TESTS=ext/mysql*/tests/001.phpt

Runs the mysql + mysqli connect tests and both are skipped.

Tests are skipped showing... (using password: NO)

Manually setting $passwd in connect.inc for both test sets runs all tests as 
expected.

So MYSQL_TEST_PASSWD is ignored.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1

Bug #60981 [Com]: Shell environment inaccessible in tests

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60981&edit=1

 ID: 60981
 Comment by:     tyr...@php.net
 Reported by:david at davidfavor dot com
 Summary:Shell environment inaccessible in tests
 Status: Assigned
 Type:   Bug
 Package:Testing related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.10
 Assigned To:danielc
 Block user comment: N
 Private report: N

 New Comment:

the problem is that the run-tests.php fetches the environment variables from 
$_ENV
http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l134
then passes the environment variables to the system_with_timeout call (which 
will 
proc_open using those environment variables).
so there is no documentation issue, only run-tests.php needs a change to either 
force the variable_orders to contain E(we could pass the --d 
variable_orders=EGPCS 
in the run-tests.php call in http://svn.php.net/viewvc/php/php-
src/trunk/Makefile.global) or changing run-tests.php to not use the $_ENV array 
for fetching all the environment vars.


Previous Comments:

[2012-02-07 14:18:14] tyr...@php.net

AFAIK getenv does work independently from variable_orders:
foo=bar php -d variables_order=GPC -r 'echo $_ENV["foo"];echo getenv("foo");'
outputs "bar" for me, so it works.

Tyrael


[2012-02-07 14:11:31] david at davidfavor dot com

That works...

So there are two doc errors...

#1) http://php.net/manual/en/reserved.variables.environment.php contains 
comments
that getenv() returns environment variables, independent of variable_orders 
setting. I've submitted a note to clarify this.

#2 http://php.net/manual/en/ini.core.php states variables_order default setting 
is "EGPCS", which is incorrect.

Both php.ini-production and php.ini-development contain "GPCS".

Best to fix both php.ini files so they match the docs.

Let me know if I should open another bug request for the doc change.

Thanks for helping me get this to work!


[2012-02-06 21:30:59] s...@php.net

Try adding E to php.ini's variables_order.


[2012-02-06 20:12:20] david at davidfavor dot com

export var=foo is the same as sourcing a file that includes...
export var=foo

Problem is no shell environment is reaching the test scripts.

Please suggest a way to turn off clearing of the environment.


[2012-02-05 19:00:29] dani...@php.net

The environment variables need to be established in a scope available all shell 
scripts.  For example, them in the ~/.bashrc script of the user executing "make 
test".

Set the variables in ~/.bashrc
source ~/.bashrc
make test 

The "source" step is only necessary in the first shell since the variables were 
not available when the shell was opened.  All future shells will have them.




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=60981


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1

Bug #60981 [Com]: Shell environment inaccessible in tests

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60981&edit=1

 ID: 60981
 Comment by:     tyr...@php.net
 Reported by:david at davidfavor dot com
 Summary:Shell environment inaccessible in tests
 Status: Assigned
 Type:   Bug
 Package:Testing related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.10
 Assigned To:danielc
 Block user comment: N
 Private report: N

 New Comment:

'Both php.ini-production and php.ini-development contain "GPCS".'
the default value means that what is the value if you don't set it any way 
(having 
no php.ini or using php -n for example)
unfortunately the default values and our developer/production inis aren't in 
sync, 
I brought that issue up on the mailing list in the past:
http://www.mail-archive.com/internals@lists.php.net/msg52262.html


Previous Comments:

[2012-02-07 14:59:11] jpa...@php.net

I confirm that getenv() works regardless any .ini config.
It proxies to SAPI/system getenv()

----
[2012-02-07 14:30:43] tyr...@php.net

the problem is that the run-tests.php fetches the environment variables from 
$_ENV
http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l134
then passes the environment variables to the system_with_timeout call (which 
will 
proc_open using those environment variables).
so there is no documentation issue, only run-tests.php needs a change to either 
force the variable_orders to contain E(we could pass the --d 
variable_orders=EGPCS 
in the run-tests.php call in http://svn.php.net/viewvc/php/php-
src/trunk/Makefile.global) or changing run-tests.php to not use the $_ENV array 
for fetching all the environment vars.

----
[2012-02-07 14:18:14] tyr...@php.net

AFAIK getenv does work independently from variable_orders:
foo=bar php -d variables_order=GPC -r 'echo $_ENV["foo"];echo getenv("foo");'
outputs "bar" for me, so it works.

Tyrael


[2012-02-07 14:11:31] david at davidfavor dot com

That works...

So there are two doc errors...

#1) http://php.net/manual/en/reserved.variables.environment.php contains 
comments
that getenv() returns environment variables, independent of variable_orders 
setting. I've submitted a note to clarify this.

#2 http://php.net/manual/en/ini.core.php states variables_order default setting 
is "EGPCS", which is incorrect.

Both php.ini-production and php.ini-development contain "GPCS".

Best to fix both php.ini files so they match the docs.

Let me know if I should open another bug request for the doc change.

Thanks for helping me get this to work!


[2012-02-06 21:30:59] s...@php.net

Try adding E to php.ini's variables_order.




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=60981


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1

Bug #60981 [PATCH]: Shell environment inaccessible in tests

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60981&edit=1

 ID: 60981
 Patch added by:     tyr...@php.net
 Reported by:david at davidfavor dot com
 Summary:Shell environment inaccessible in tests
 Status: Assigned
 Type:   Bug
 Package:Testing related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.10
 Assigned To:danielc
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: run-tests.php.diff
Revision:   1328630230
URL:
https://bugs.php.net/patch-display.php?bug=60981&patch=run-tests.php.diff&revision=1328630230


Previous Comments:

[2012-02-07 15:55:42] tyr...@php.net

"--d variable_orders=EGPCS to run-tests"
if you mean adding that to Makefile.global (the Makefile template, which will 
run run-tests.php when you execute make test) then yeah, it is an elegant 
solution, but I think it would be better to fix run-tests.php itself, so for 
those who call it directly (half of the core/qa people...) will also be fixed.
Pierre told me that there is no clean way to fetch all environment vars from a 
php script if $_ENV isn't populated (you could parse it from the output of 
phpinfo() but that would be error-prone and messy).
So I would propose calling another php instance and fetching the environment 
variables from there using shell_exec.
See the attached patch.
(If somebody has a better idea, I'm all for it.)


[2012-02-07 15:20:06] david at davidfavor dot com

Seems like adding --d variable_orders=EGPCS to run-tests is the most elegant.

What the next step to arrange for this bug to be fixed?

Also I notice there are 4 failures in the mysqli tests. Let me know how to 
register as a developer with php.net and I'll figure these out and supply 
patches to fix the test suite.

Thanks.

--------
[2012-02-07 15:03:35] tyr...@php.net

'Both php.ini-production and php.ini-development contain "GPCS".'
the default value means that what is the value if you don't set it any way 
(having 
no php.ini or using php -n for example)
unfortunately the default values and our developer/production inis aren't in 
sync, 
I brought that issue up on the mailing list in the past:
http://www.mail-archive.com/internals@lists.php.net/msg52262.html


[2012-02-07 14:59:11] jpa...@php.net

I confirm that getenv() works regardless any .ini config.
It proxies to SAPI/system getenv()

--------
[2012-02-07 14:30:43] tyr...@php.net

the problem is that the run-tests.php fetches the environment variables from 
$_ENV
http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l134
then passes the environment variables to the system_with_timeout call (which 
will 
proc_open using those environment variables).
so there is no documentation issue, only run-tests.php needs a change to either 
force the variable_orders to contain E(we could pass the --d 
variable_orders=EGPCS 
in the run-tests.php call in http://svn.php.net/viewvc/php/php-
src/trunk/Makefile.global) or changing run-tests.php to not use the $_ENV array 
for fetching all the environment vars.




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=60981


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1

Bug #60981 [PATCH]: Shell environment inaccessible in tests

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60981&edit=1

 ID: 60981
 Patch added by:     tyr...@php.net
 Reported by:david at davidfavor dot com
 Summary:Shell environment inaccessible in tests
 Status: Assigned
 Type:   Bug
 Package:Testing related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.10
 Assigned To:danielc
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: run-tests.php.diff
Revision:   1328646999
URL:
https://bugs.php.net/patch-display.php?bug=60981&patch=run-tests.php.diff&revision=1328646999


Previous Comments:

[2012-02-07 17:08:03] david at davidfavor dot com

Just tested supplied patch and seems to work well.


[2012-02-07 15:57:10] tyr...@php.net

The following patch has been added/updated:

Patch Name: run-tests.php.diff
Revision:   1328630230
URL:
https://bugs.php.net/patch-display.php?bug=60981&patch=run-tests.php.diff&revision=1328630230


[2012-02-07 15:55:42] tyr...@php.net

"--d variable_orders=EGPCS to run-tests"
if you mean adding that to Makefile.global (the Makefile template, which will 
run run-tests.php when you execute make test) then yeah, it is an elegant 
solution, but I think it would be better to fix run-tests.php itself, so for 
those who call it directly (half of the core/qa people...) will also be fixed.
Pierre told me that there is no clean way to fetch all environment vars from a 
php script if $_ENV isn't populated (you could parse it from the output of 
phpinfo() but that would be error-prone and messy).
So I would propose calling another php instance and fetching the environment 
variables from there using shell_exec.
See the attached patch.
(If somebody has a better idea, I'm all for it.)


[2012-02-07 15:20:06] david at davidfavor dot com

Seems like adding --d variable_orders=EGPCS to run-tests is the most elegant.

What the next step to arrange for this bug to be fixed?

Also I notice there are 4 failures in the mysqli tests. Let me know how to 
register as a developer with php.net and I'll figure these out and supply 
patches to fix the test suite.

Thanks.

--------
[2012-02-07 15:03:35] tyr...@php.net

'Both php.ini-production and php.ini-development contain "GPCS".'
the default value means that what is the value if you don't set it any way 
(having 
no php.ini or using php -n for example)
unfortunately the default values and our developer/production inis aren't in 
sync, 
I brought that issue up on the mailing list in the past:
http://www.mail-archive.com/internals@lists.php.net/msg52262.html




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=60981


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1

Bug #60981 [Com]: Shell environment inaccessible in tests

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60981&edit=1

 ID: 60981
 Comment by:     tyr...@php.net
 Reported by:david at davidfavor dot com
 Summary:Shell environment inaccessible in tests
 Status: Assigned
 Type:   Bug
 Package:Testing related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.10
 Assigned To:danielc
 Block user comment: N
 Private report: N

 New Comment:

I've just noticed that I got the patch reversed, I fixed it, now it should 
apply 
without the "Reversed (or previously applied) patch detected!  Assume -R? [n]" 
question.


Previous Comments:

[2012-02-07 20:36:39] tyr...@php.net

The following patch has been added/updated:

Patch Name: run-tests.php.diff
Revision:   1328646999
URL:
https://bugs.php.net/patch-display.php?bug=60981&patch=run-tests.php.diff&revision=1328646999


[2012-02-07 17:08:03] david at davidfavor dot com

Just tested supplied patch and seems to work well.

----
[2012-02-07 15:57:10] tyr...@php.net

The following patch has been added/updated:

Patch Name: run-tests.php.diff
Revision:   1328630230
URL:
https://bugs.php.net/patch-display.php?bug=60981&patch=run-tests.php.diff&revision=1328630230

----
[2012-02-07 15:55:42] tyr...@php.net

"--d variable_orders=EGPCS to run-tests"
if you mean adding that to Makefile.global (the Makefile template, which will 
run run-tests.php when you execute make test) then yeah, it is an elegant 
solution, but I think it would be better to fix run-tests.php itself, so for 
those who call it directly (half of the core/qa people...) will also be fixed.
Pierre told me that there is no clean way to fetch all environment vars from a 
php script if $_ENV isn't populated (you could parse it from the output of 
phpinfo() but that would be error-prone and messy).
So I would propose calling another php instance and fetching the environment 
variables from there using shell_exec.
See the attached patch.
(If somebody has a better idea, I'm all for it.)


[2012-02-07 15:20:06] david at davidfavor dot com

Seems like adding --d variable_orders=EGPCS to run-tests is the most elegant.

What the next step to arrange for this bug to be fixed?

Also I notice there are 4 failures in the mysqli tests. Let me know how to 
register as a developer with php.net and I'll figure these out and supply 
patches to fix the test suite.

Thanks.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=60981


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60981&edit=1

Bug #52078 [Com]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=52078&edit=1

 ID: 52078
 Comment by:     tyr...@php.net
 Reported by:glen at delfi dot ee
 Summary:fileinode overflow test
 ext/standard/tests/file/fileinode_variation3.phpt
 Status: Assigned
 Type:   Bug
 Package:Filesystem function related
 Operating System:   PLD Linux
 PHP Version:5.3.2
 Assigned To:tyrael
 Block user comment: N
 Private report: N

 New Comment:

I would prefer the a (%i) solution, there is no reason to skip tests (and miss 
regression) on 32bit only because the values (whom excat values we don't really 
care) can overflow on some configurations.


Previous Comments:

[2012-02-06 23:51:23] glen at delfi dot ee

i could supply the patches, if i get answer WHICH WAY TO GO!

a) %i in formats like in initial patch?
b) PHP_INT_SIZE check, like asked in comment #3?
c) something else???


[2012-02-06 22:50:44] tyr...@php.net

applied the original patch to the 5.4 branch also.
if you can come up with patches for the other tests I can also apply then soon, 
if 
not I will try to go through the affected tests, but that will take longer.


[2012-02-06 22:47:22] tyr...@php.net

Automatic comment from SVN on behalf of tyrael
Revision: http://svn.php.net/viewvc/?view=revision&revision=323100
Log: merging the patch from bug #52078, fixes the test on disk with huge inode 
size(fileinode() can overflow and return negative values there).


[2012-01-20 23:56:28] glen at delfi dot ee

please note that the patch provided in bug was not complete (there are more 
tests 
suffering the same deficiency), because did not get any feedback to decide to 
proceed further.

"find -name '*.phpt' | xargs grep fileinode" in source tree should give ideas 
what more to patch (and of course all inode related functions: getmyinode, 
stat, 
...)

--------
[2012-01-19 19:09:44] tyr...@php.net

I commited the %d->%i changes to trunk and 5.3, waiting for approval to commit 
it 
to 5.4 as well, I will keep the ticket open until.

http://svn.php.net/viewvc?view=revision&revision=322460




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=52078


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=52078&edit=1

[PHP-BUG] Bug #64987 [NEW]: unexpected result for call_user_func() in the debug_backtrace()

[tyr...@php.net]

From: tyrael
Operating system: irrelevant
PHP version:  5.3.26
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:unexpected result for call_user_func() in the debug_backtrace()

Description:

call_user_func() generates two entry to the backtrace: one for the call of
the 
call_user_func with the callable arg and one for the call of the callable.
the problem is that the entry only has function and args entry, but no file
or 
line.
This happens because the execution reaches the break here:
http://lxr.php.net/xref/PHP_5_3/Zend/zend_builtin_functions.c#2161
Which based on the comment above is there to prevent touching the stack
when we 
are inside the error handler, which isn't the case here.

When discussing this with Nikita on irc he said that we shouldn't have two
entry 
in the result in the first place for call_user_func, but I think that
removing 
one entry would have bigger impact on userland (there is a chance that some

people already remove the entry manually and this change would make it
remove o 
valid entry) compared to the change to fill out the information that was
ommited 
before.

btw it seems that the suggested behavior was present between 5.0.0 and
5.0.5:
http://3v4l.org/jI9VI#v430
5.0.5 had two debug_backtrace related fix mentioned in the changelog(#30828
and 
#28377) but from a quick glance on the description it seems to be
irrelevant 
from this behavior change.

In case if we decide to not change the current behavior, please turn this
report 
into a documentation problem as it would be nice if the docs would reflect
what 
information will present (or missing) in which case.
Currently we only hint that the type and args can be missing in some case.

ps: the issue is still present in master and commenting out the if with
that 
break produces the expected result but ofc. that isn't the proper fix.

Test script:
---

  array(4) {
["file"]=>
string(9) "/in/jI9VI"
["line"]=>
int(3)
["function"]=>
string(3) "bar"
["args"]=>
array(0) {
}
  }
  [1]=>
  array(4) {
["file"]=>
string(9) "/in/jI9VI"
["line"]=>
int(8)
["function"]=>
string(3) "foo"
["args"]=>
array(0) {
}
  }
  [2]=>
  array(4) {
["file"]=>
string(9) "/in/jI9VI"
["line"]=>
int(8)
["function"]=>
string(14) "call_user_func"
["args"]=>
array(1) {
  [0]=>
  &string(3) "foo"
}
  }
}

Actual result:
--
array(3) {
  [0]=>
  array(4) {
["file"]=>
string(9) "/in/jI9VI"
["line"]=>
int(3)
["function"]=>
string(3) "bar"
["args"]=>
array(0) {
}
  }
  [1]=>
  array(2) {
["function"]=>
string(3) "foo"
["args"]=>
array(0) {
}
  }
  [2]=>
  array(4) {
["file"]=>
string(9) "/in/jI9VI"
["line"]=>
int(8)
["function"]=>
string(14) "call_user_func"
["args"]=>
array(1) {
  [0]=>
  &string(3) "foo"
}
  }
}

-- 
Edit bug report at https://bugs.php.net/bug.php?id=64987&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=64987&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=64987&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=64987&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=64987&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=64987&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64987&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=64987&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=64987&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64987&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=64987&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64987&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64987&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=64987&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64987&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=64987&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=64987&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64987&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64987&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64987&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=64987&r=mysqlcfg

[PHP-BUG] Bug #65317 [NEW]: spl autoload won't work inside an autoload

[tyr...@php.net]

From: tyrael
Operating system: linux
PHP version:  5.4.17
Package:  SPL related
Bug Type: Bug
Bug description:spl autoload won't work inside an autoload

Description:

I just bumped into an issue, where we had a Strict error triggered about an

abstract class, which caused our autoloader to fail.
It seems that the autoloader won't be called when you try to reference a
not-yet-
loaded class from an error handler triggered by an autoloader function.
I think that the attached test script makes the scenario more clear(sorry
for the 
eval part, I didn't wanted to upload multiple scripts), but feel free to
ask me if 
you need more info.

ps: it seems that this never worked http://3v4l.org/AQCue but I couldn't
find any 
previous reports or notes/docs on the topic.

Test script:
---
https://bugs.php.net/bug.php?id=65317&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65317&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65317&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65317&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65317&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65317&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65317&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65317&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65317&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65317&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65317&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65317&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65317&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65317&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65317&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65317&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65317&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65317&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65317&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65317&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65317&r=mysqlcfg

[PHP-BUG] Bug #65322 [NEW]: compile time errors won't trigger auto loading

[tyr...@php.net]

From: tyrael
Operating system: irrelevant
PHP version:  5.4.17
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:compile time errors won't trigger auto loading

Description:

I originally reported this under #65317 but after looking into it a bit
more 
(thanks laruence) it turned out that the original report was a little bit 
misleading:
the autoloader isn't prevented because we are already in an autoload call,
but 
because the engine won't call the autoloaders for errors from compilation 
time(zend_lookup_class_ex):

/* The compiler is not-reentrant. Make sure we __autoload() only during
run-
time
 * (doesn't impact fuctionality of __autoload()
*/
if (!use_autoload || zend_is_compiling(TSRMLS_C)) {
if (!key) {
free_alloca(lc_free, use_heap);
}
return FAILURE;
}

I would be curious how come that it is safe to call the autoloader (which
in 
turn can do anything, include other files or call the autoloaders
manually), but 
not safe to call the autoloader in this case.

Test script:
---
https://bugs.php.net/bug.php?id=65322&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=65322&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=65322&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=65322&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=65322&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=65322&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65322&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=65322&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=65322&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65322&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=65322&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65322&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65322&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=65322&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65322&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=65322&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=65322&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65322&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65322&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65322&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=65322&r=mysqlcfg

Req #54564 [Com]: extension_dir should be used for loading zend_extensions

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=54564&edit=1

 ID: 54564
 Comment by:     tyr...@php.net
 Reported by:tyra3l at gmail dot com
 Summary:extension_dir should be used for loading
 zend_extensions
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

Stas, I'm not sure I'm following your reasoning here.
extension_dir exists, and it is pretty standard in each and every distribution 
to 
rely on this behavior, so bringing this issue against my proposal means that 
you 
either missed my point (extension_dir is honored for zend_extension= like it 
does 
for extension=) or you somehow think that loading a rouge zend extension has 
bigger security implications, which I can't see.

ps: Binary Planting isn't really similar with what we have here, the issue with 
that is that it allows loading dll's from the current directory, while we would 
only allow loading extensions from the paths listed in extension_dir.


Previous Comments:

[2012-09-16 06:54:57] s...@php.net

I think loading extensions through relative path opens a way to all kinds of 
dangerous behavior and may have problematic security implications - like ones 
described here: http://arstechnica.com/information-technology/2010/08/new-
windows-dll-security-flaw-everything-old-is-new-again/. I'm not sure also why 
it 
is necessary - why can't PHP extension be installed in extension dir and run 
from 
there? If one needs multiple ones, multiple php.ini files can always be used.


[2011-04-18 23:05:25] tyra3l at gmail dot com

Description:

I've brought this topic on the internals
http://marc.info/?l=php-internals&m=130314285822279&w=2
and I think that it would be useful and more consistent, if this could be 
changed, 
so one could easily load both "normal" and zend extensions without the need to 
use 
absolute paths.


Test script:
---
php -n -d zend_extension=xdebug.so -r ''

Actual result:
--
Failed loading xdebug.so:  xdebug.so: cannot open shared object file: No such 
file 
or directory






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54564&edit=1

Bug #55475 [Com]: is_a() triggers autoloader

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=55475&edit=1

 ID: 55475
 Comment by:     tyr...@php.net
 Reported by:mads at gartneriet dot dk
 Summary:is_a() triggers autoloader
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.3.7
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

"note the "FALSE otherwise" ..."

note "if the object" ...

Tyrael


Previous Comments:

[2011-08-26 10:24:39] kkaminski at itens dot pl

+1 for reverting change in 5.3 branch and implementing it in 5.4 (or giving up 
as it really CHANGES BEHAVIOR)
Currently __autoload throws Exceptions to break code execution on some 
frameworks. This is clean solution as if developer makes a typo, code still can 
handle missing class and for instance - display a dedicated error report.

Unfortunately, with your latest 'fix' all PEAR packages are now broken on 
frameworks with __autoload + exceptions - due to isError implementation.

Are you really sure is it MY duty to rewrite / repatch all code (external) code 
to work around your 'fix' ?
How I am supposed to handle missing classes in this case? With exceptions I can 
catch everything and handle myself. Whats the other way?


[2011-08-24 05:16:11] jha dot rajeev at gmail dot com

I have a question re. the correct behavior of custom __autoload() functions 
when 
called from is_a() in 5.3.7. How do we handle/report missing classes? is is_a() 
prepared to handle any sort of exceptions or does it assume that __autoload 
will 
return TRUE/FALSE only?

what if I just did something like is_a("",ABCD)?


[2011-08-24 01:59:04] alan at akbkhome dot com

For reference: 
The workaround is to do this 

if (is_a($a, 'B')) {

becomes

if (is_object($a) && is_a($a, 'B')) {


[2011-08-23 14:24:59] jha dot rajeev at gmail dot com

This also affects HTML_Template_Flexy pear package that uses is_a to check 
returned object against PEAR_Error class. No matter what behavior is right it 
looks broken to me because I am patching this pear packages files right now!


[2011-08-23 08:25:33] alan at akbkhome dot com

@stas - the point of un-depreciating and working with a string was the second 
argument, not the first one. 

eg.

is_a($something, 'might_be_not_loaded_class') 
rather than
$something instanceof might_be_not_loaded_class




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=55475


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55475&edit=1

Bug #48770 [Com]: call_user_func_array() fails to call parent from inheriting class

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=48770&edit=1

 ID: 48770
 Comment by:     tyr...@php.net
 Reported by:lumeet at yahoo dot com
 Summary:call_user_func_array() fails to call parent from
 inheriting class
 Status: Verified
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.3, 6 (2009-08-01)
 Block user comment: N
 Private report: N

 New Comment:

for the record: the segfault is caused by an infinite recursion (B->func), and 
that happens, because the $this in the B->func() points to C, which causes 
parent::func to point to itself.
btw. I find it really unintentional that call_user_func can be used with both 
passing an object instance and a static call reference as a method name.
we also have failing tests for this particular bug:
Zend/tests/bug48770.phpt
Zend/tests/bug48770_2.phpt
Zend/tests/bug48770_3.phpt

imo as we have this behavior for some time now, I think we should keep it, and 
update the tests.

Tyrael


Previous Comments:

[2009-09-25 12:12:12] dmitry dot revenko at businessmedia dot ru

I'm sorry.
The solution is:

call_user_func_array('parent::func', $args);

instead of

call_user_func_array(array($this, 'parent::func'), $args);


[2009-09-25 08:08:07] dmitry dot revenko at businessmedia dot ru

I also used this pattern in some critical moments, and it proved to be very 
useful.
Yes, I know about PHP 3's "call_user_func() now propagates $this even if the 
callee is the parent class". But I don't know - why? Why so simple working 
logic was ruined in new version? Isn't it straght that 
call_user_func_array(array( $this, 'parent::func' ), $args) should call first 
found parent method func?


[2009-08-01 01:51:07] j...@php.net

Also note: This works fine with PHP_5_2 :)


[2009-07-02 07:38:03] sjoerd-php at linuxonly dot nl

Thank you for your bug report. I could reproduce it and added some more data:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7d03b80 (LWP 6726)]
0x082dee15 in zend_is_callable_ex (callable=0x9e3cdc0, object_ptr=0x0, 
check_flags=0, callable_name=0x0, callable_name_len=0x0, fcc=0xbf49d190, 
error=0xbf49d0e8) at /home/sjoerd/dev/php/trunk/php5/Zend/zend_API.c:2624
2624{
#0  0x082dee15 in zend_is_callable_ex (callable=0x9e3cdc0, object_ptr=0x0, 
check_flags=0, callable_name=0x0, callable_name_len=0x0, fcc=0xbf49d190, 
error=0xbf49d0e8) at /home/sjoerd/dev/php/trunk/php5/Zend/zend_API.c:2624
#1  0x082df489 in zend_fcall_info_init (callable=0x9e3cdc0, check_flags=0, 
fci=0xbf49d16c, fcc=0xbf49d190, callable_name=0x0, error=0xbf49d0e8)
at /home/sjoerd/dev/php/trunk/php5/Zend/zend_API.c:2858
#2  0x082e35a2 in zend_parse_va_args (num_args=2, type_spec=0x85b0091 "a/", 
va=0xbf49d13c, flags=0)
at /home/sjoerd/dev/php/trunk/php5/Zend/zend_API.c:592
#3  0x082e3d12 in zend_parse_parameters (num_args=2, type_spec=0xbf49d0e8 "")
at /home/sjoerd/dev/php/trunk/php5/Zend/zend_API.c:870
#4  0x08220dd1 in zif_call_user_func_array (ht=2, return_value=0x9e3ce7c, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
at /home/sjoerd/dev/php/trunk/php5/ext/standard/basic_functions.c:4748
#5  0x083259b9 in zend_do_fcall_common_helper_SPEC (execute_data=0x9de07bc)
at /home/sjoerd/dev/php/trunk/php5/Zend/zend_vm_execute.h:313
#6  0x08302dbe in execute (op_array=0x9448e90)
at /home/sjoerd/dev/php/trunk/php5/Zend/zend_vm_execute.h:104
#7  0x082d0c77 in zend_call_function (fci=0xbf49d37c, fci_cache=0xbf49d3a0)
at /home/sjoerd/dev/php/trunk/php5/Zend/zend_execute_API.c:936
#8  0x08220df7 in zif_call_user_func_array (ht=2, return_value=0x9e3ccb0, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
at /home/sjoerd/dev/php/trunk/php5/ext/standard/basic_functions.c:4755
#9  0x083259b9 in zend_do_fcall_common_helper_SPEC (execute_data=0x9de06fc)
at /home/sjoerd/dev/php/trunk/php5/Zend/zend_vm_execute.h:313
#10 0x08302dbe in execute (op_array=0x9448e90)
at /home/sjoerd/dev/php/trunk/php5/Zend/zend_vm_execute.h:104
#11 0x082d0c77 in zend_call_function (fci=0xbf49d58c, fci_cache=0xbf49d5b0)
at /home/sjoerd/dev/php/trunk/php5/Zend/zend_execute_API.c:936
#12 0x08220df7 in zif_call_user_func_array (ht=2, return_value=0x9e3cae4, 
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
at /home/sjoerd/dev/php/trunk/php5/ext/standard/basic_functions.c:4755

...

#11213 0x083259b9 in zend_do_fcall_common_helper_SPEC (execute_data=0x9c1d004)
at /home/sjoerd/dev/

[PHP-BUG] Bug #55671 [NEW]: clean up the php 6 references in run-tests.php

[tyr...@php.net]

From: tyrael
Operating system: 
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Bug
Bug description:clean up the php 6 references in run-tests.php

Description:

there are mentions and special cases for working with php6, which isn't
valid 
anymore.
we should remove those(unicode string/binary string types), and there are
some, 
which should be enabled for >= 504000:
magic_quotes, safe_mode check, as those are removed with 5.4


-- 
Edit bug report at https://bugs.php.net/bug.php?id=55671&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55671&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55671&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55671&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55671&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55671&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55671&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55671&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55671&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55671&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55671&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55671&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55671&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55671&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55671&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55671&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55671&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55671&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55671&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55671&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55671&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55671&r=mysqlcfg

Bug #53574 [Com]: Integer overflow in SdnToJulian

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=53574&edit=1

 ID: 53574
 Comment by:     tyr...@php.net
 Reported by:m dot kocielski at gmail dot com
 Summary:Integer overflow in SdnToJulian
 Status: Re-Opened
 Type:   Bug
 Package:Calendar related
 Operating System:   Linux
 PHP Version:5.5.0-dev
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

on 64bit:

tyrael@phpize:~/checkouts/php-src/trunk$ ./sapi/cli/php -r 
'print_r(cal_from_jd(9223372036854743639, CAL_GREGORIAN));'
Segmentation fault


Previous Comments:

[2011-09-26 20:56:50] tyr...@php.net

on 32bit with the current trunk:

tyrael@phpize32:~/checkouts/php-src/trunk$ ./sapi/cli/php -r 
'print_r(cal_from_jd(882858030, CAL_GREGORIAN));'
Segmentation fault

I will split the test(ext/calendar/tests/bug53574.log) into two separate test, 
one 
for 32bit, one for 64bit, as the EXPECT cannot test both case in one test 
easily.


[2010-12-20 00:47:19] cataphr...@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-12-20 00:47:02] cataphr...@php.net

Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=306475
Log: - Fixed bug #53574 (Integer overflow in SdnToJulian, sometimes leading to
  segfault).


[2010-12-19 15:08:51] m dot kocielski at gmail dot com

Description:

*cut*
void SdnToJulian(
long int sdn,
int *pYear,
int *pMonth,
int *pDay)
{
int year;
int month;
int day;
long int temp;
int dayOfYear;

if (sdn <= 0) {
*pYear = 0;
*pMonth = 0;
*pDay = 0;
return;
}

temp = (sdn + JULIAN_SDN_OFFSET) * 4 - 1;
*cut*

temp could here be less then 0 due to integer overflow (when sdn is large 
enough).

Test script:
---



Expected result:

Sigsegv:

$ php core1.php 
758413092
1698116908
42935006
988939165
101976420
1332880082
882858043
Naruszenie ochrony pamięci (SIGSEGV)








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=53574&edit=1

[PHP-BUG] Req #55788 [NEW]: test redirects should abide SHOW_ONLY_GROUPS in run-tests.php

[tyr...@php.net]

From: tyrael
Operating system: 
PHP version:  Irrelevant
Package:  Testing related
Bug Type: Feature/Change Request
Bug description:test redirects should abide SHOW_ONLY_GROUPS in run-tests.php

Description:

currently the test redirects(show_redirect_start() and
show_redirect_ends()) will 
always print two lines to the output, ignoring the value of
SHOW_ONLY_GROUPS.
I think that it would be more consistent, if those lines could be
controlled the 
same way, as we do with everything else.
this change would only noticeable for those who run the test suite with
custom 
options (passing the SHOW_ONLY_GROUPS environment variable to make test or
the 
argument -g to run-tests.php).
the attached patch is pretty straightforward, you can pass the ---> if you
need 
the ---> lines in your testsuite output.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=55788&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55788&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55788&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55788&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55788&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55788&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55788&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55788&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55788&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55788&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55788&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55788&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55788&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55788&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55788&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55788&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55788&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55788&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55788&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55788&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55788&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55788&r=mysqlcfg

Req #55672 [Com]: Autoguessing TEST_PHP_EXECUTABLE if none is provided in run-tests.php

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=55672&edit=1

 ID: 55672
 Comment by:     tyr...@php.net
 Reported by:sh...@php.net
 Summary:Autoguessing TEST_PHP_EXECUTABLE if none is provided
 in run-tests.php
 Status: Open
 Type:   Feature/Change Request
 Package:Testing related
 PHP Version:trunk-SVN-2011-09-12 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Alex, maybe you should submit the getenv part of the patch separately to 
https://bugs.php.net/bug.php?id=53617 as it seems that we have a general 
agreement 
on fixing that.

Tyrael


Previous Comments:

[2011-09-15 20:38:23] sh...@php.net

This patch is not about guessing php executable that runs run-tests.php, but is 
about php binary to be tested, these are often different binaries.


[2011-09-12 14:19:26] larue...@php.net

how about use $0 ?


[2011-09-12 12:29:48] sh...@php.net

Description:

Hello!
I've made some improvements to run-tests.php:
1) Autoguessing TEST_PHP_EXECUTABLE and TEST_PHP_CGI_EXECUTABLE if
they're not provided, i.e. assume they have value 'auto'. You can
still pass your own value as usual.

Autoguessing is done this way:
Looking for ./sapi/cli/php from the current directory, and, if not found
from directory where run-tests.php script is resides (Christofer Jones 
suggestion). 
php-cgi is looked for the same way.

2) Added option -n (use no php.ini) to the shebang line
(#!/usr/bin/php -n) so it would run more reliably on some hosts. My
Ubuntu setup did not have E letter in variables_order (i.e.
variables_order=GPCS) so $_ENV array was empty and some tests were
skipped when they could be run.
3) Some better error handling of wrong paths

So now you can run run-tests.php with just
$ ./run-tests.php ext
instead of
$ TEST_PHP_EXECUTABLE=auto php -n run-tests.php ext

You can also run run-tests.php from sub-dir, it will correctly guess
'auto' as well:
$ cd ext/
$ ../run-tests.php zlib









-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55672&edit=1

Bug #53251 [Com]: bindtextdomain with null directory doesn't return the previously set

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=53251&edit=1

 ID: 53251
 Comment by:     tyr...@php.net
 Reported by:jeanseb at au-fil-du dot net
 Summary:bindtextdomain with null directory doesn't return
 the previously set
 Status: Assigned
 Type:   Bug
 Package:Gettext related
 Operating System:   Debian 5.0.6
 PHP Version:5.3.3
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

what is missing here to move forward with the fix?

Tyrael


Previous Comments:

[2010-11-26 23:12:03] greno at verizon dot net

Please, I do read and consider all of your comments.

And I understand the concern about the TS build.  

I was merely trying to convey that I have not seen or read about any evidence 
that is convincing that using gettext in threads would be successful given the 
current state of the underlying GNU gettext library.

I based this on things like this:

Checking latest gettext manual here:
http://www.gnu.org/software/gettext/manual/gettext.html#PHP

It shows that PHP 'uses' not 'emulates' the GNU underlying gettext library.  
The GNU library is not thread-safe.

Checking PHP gettext in the manual:
http://www.php.net/manual/en/gettext.requirements.php

It shows a comment stating that PHP gettext is not thread-safe and even gives 
an example of one of the environment variables that can drive the underlying 
GNU gettext library.  The comment supports other places of information that 
basically assert the same thing.



I certainly agree, if you need to put some type of ifdef TSMODE or whatever in 
the patch OK, please by all means put it in there.  That only would apply to 
the threaded model so it would be a NOP to those using the non-threaded model.  
If you need to force the fact that the bound directory must exist for whatever 
reason in the threaded model, OK, that's some limitation of the threaded model. 
It deviates from the defined GNU bindtextdomain behavior but to get a threaded 
model working maybe that's a necessary tradeoff.


My only goal is to get a patch in PHP 5.2 and 5.3 asap to fix the current 
brokenness of bindtextdomain.


.


[2010-11-26 21:03:57] paj...@php.net

I really appreciate your feedback but it tends to be a monologue. You totally 
ignore any comment you disagree with or don't care about.

I explained already many times why and when we should care about that. I even 
pointed to the gettext documentation telling that. So let say that unless you 
have something new to say, the problem is identified and will be fixed asap.


[2010-11-26 20:51:39] greno at verizon dot net

Gettext is not thread-safe.  You shouldn't need to worry about trying to get 
gettext working in threads.  The underlying gettext library would first have to 
be made thread-safe and no longer able to be driven by environment variables.

Gettext can be driven by environment variables and unless you have a way to set 
up completely different environments for each thread, then there is never going 
to be a way to reliably use gettext in threads.  One thread could set an env 
var to one value and another thread in the same process set the env var to a 
different value and both of these threads would see the value set by the latest 
thread.  And gettext would behave according to the latest setting which would 
totally screw up the earlier thread.


.


[2010-11-26 20:43:18] paj...@php.net

Thanks for the patch. But it is sadly not correct. We have to get the realpath 
of the directory argument in TS mode.


[2010-11-26 20:37:50] greno at verizon dot net

I've attached a patch (fix_broken_bindtextdomain) to the bug which should 
correct the bindtextdomain problem.  

And I prepared phpt tests (see my second set of phpt tests zip file in a 
previous posting) that can test the bindtextdomain NULL arg functionality.  

So everything is here and available to fix bindtextdomain in PHP 5.2.15 and 
5.3.3.


.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=53251


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=53251&edit=1

Bug #46683 [Com]: fopen() file name in warning is upper cased if the arguments are invalid

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=46683&edit=1

 ID: 46683
 Comment by:     tyr...@php.net
 Reported by:a...@php.net
 Summary:fopen() file name in warning is upper cased if the
 arguments are invalid
 Status: Assigned
 Type:   Bug
 Package:Filesystem function related
 Operating System:   win32 only
 PHP Version:5.3CVS-2008-11-26 (snap)
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

is this still an issue?


Previous Comments:

[2009-08-14 13:10:14] paj...@php.net

stupid! stupid! auto no feedback.


[2009-03-12 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 able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


[2009-03-04 12:30:06] a...@php.net

Yes I agree the updated error message is better than the previous 
invalid argument message. On the subject of clear tests I don't 
actually find this test too bad. The code has logic to test a bunch 
of different conditions and so requires some eye balling to 
understand. Each iteration includes the current item (see below). 

I find this approach preferable to unrolling the loop and duplicating 
the code as I think that would make the test significantly less 
maintainable.

--c:\/--
file in root

--c:\fopen11.tmpdirTwo\/--
file in fopen11.tmpdirTwo

--c:\fopen11.tmpdirTwo\--
file in fopen11.tmpdirTwo


[2009-03-02 21:06:42] paj...@php.net

UNC path begins with \\, that's why it was necessary to upper case the path.

However, why do you expect an invalid argument in this case? Here is what I 
get, which makes more sense (after the fix for the correct path in the error 
message):

018+ Warning: fopen(\\fopen_variation11.tmp): failed to open stream: No such 
file or directory in ext\standard\test\file\fopen_variation11-win32.php on line 
52
018- Warning: fopen(\\fopen_variation11.tmp): failed to open stream: Invalid 
argument in %s on line %d
025+ Warning: fopen(/\fopen_variation11.tmp): failed to open stream: No such 
file or directory in ext\standard\tests\file\fopen_variation11-win32.php on 
line 52
025- Warning: fopen(\\fopen_variation11.tmp): failed to open stream: Invalid 
argument in %s on line %d




[2009-03-02 20:28:05] paj...@php.net

Side note:

Please (PLEASE!!) try to create tests we can read. Like having an index telling 
which iteration we are or other similar tricks to ease the debugging. I already 
asked for cleaner tests many times on php-qa, without much success :)




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=46683


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=46683&edit=1

Bug #55665 [Com]: Segmentation fault in gc_mark_roots()

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=55665&edit=1

 ID: 55665
 Comment by:     tyr...@php.net
 Reported by:mbecc...@php.net
 Summary:Segmentation fault in gc_mark_roots()
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   FreeBSD 6.2
 PHP Version:5.3SVN-2011-09-10 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

is it still reproducible with 5.3.8?


Previous Comments:

[2011-09-10 11:17:29] mbecc...@php.net

Description:

As usual with bugs related to garbage collection, I don't have a short 
reproduce code. The segmentation fault happens when running a pretty heavy 
integration test and is currently reproducible on PHP 5.3 (tested 5.3.4, 
5.3.6RC3, 5.3.8 and PHP_5_3 svn HEAD). Unfortunately garbage collection is a 
bit too much for me to be able to make sense of it and debug the issue.

Interestingly enough I couldn't reproduce it on PHP 5.2 or PHP 5.4.

Happens both with gcc 3.4.6 and 4.2.5 with -O0.

SSH Access to the machine is available for anyone interested in investigating.



Actual result:
--
Here is the relevant portion of backtrace and some other gdb commands:

#0  0x0094a060 in gc_mark_roots () at 
/array1/compile/php-src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:434
434 if (GC_ZVAL_GET_COLOR(current->u.pz) == 
GC_PURPLE) {
(gdb) bt full
#0  0x0094a060 in gc_mark_roots () at 
/array1/compile/php-src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:434
current = (gc_root_buffer *) 0x11121a0
#1  0x0094a90c in gc_collect_cycles () at 
/array1/compile/php-src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:664
p = (zval_gc_info *) 0x1e8fbd0
q = (zval_gc_info *) 0x7fffccd8
orig_free_list = (zval_gc_info *) 0x377c42d8edc99ee
orig_next_to_free = (zval_gc_info *) 0x901e88190
count = 0
#2  0x009495c2 in gc_zval_possible_root (zv=0x3e37620) at 
/array1/compile/php-src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:166
newRoot = (gc_root_buffer *) 0x0
#3  0x009bb104 in ZEND_FETCH_DIM_W_SPEC_VAR_CV_HANDLER 
(execute_data=0x1390810) at zend_gc.h:183
opline = (zend_op *) 0x1e8fbf8
free_op1 = {var = 0x0}
dim = (zval *) 0x3e37708
container = (zval **) 0x3057850
#4  0x00953c58 in execute (op_array=0x1e8be08) at zend_vm_execute.h:107
ret = 0
execute_data = (zend_execute_data *) 0x1390810
nested = 1 '\001'
original_in_execution = 0 '\0'
...
(gdb) print current->u.pz
$1 = (zval *) 0x3e9fd38
(gdb) print *current->u.pz
Cannot access memory at address 0x3e9fd38
(gdb) frame 4
#4  0x00953c58 in execute (op_array=0x1e8be08) at zend_vm_execute.h:107
107 if ((ret = EX(opline)->handler(execute_data TSRMLS_CC)) 
> 0) {
(gdb) dump_bt executor_globals.current_execute_data
[0x01390810] addItem() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container.php:153
[0x013905c0] addItem() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container.php:108
[0x01390450] createItem() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container.php:196
[0x01390008] createDirective() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container/PHPArray.php:113
[0x0138fbc0] _parseArray() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container/PHPArray.php:111
[0x0138f5a0] _parseArray() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container/PHPArray.php:75
[0x0138ef48] parseDatasrc() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config.php:197
[0x0138ebd8] parseConfig() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/OA/Admin/Settings.php:364
[0x0138b9b0] writeConfigArrayToFile() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/OA/Admin/Settings.php:173
[0x0138b7a0] writeConfigChange() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/OX/Plugin/PluginManager.php:870
[0x0138ac18] _setPackage() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/OX/Plugin/PluginManager.php:518
[0x0138a0e8] enablePackage() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/tests/testClasses/TestEnv.php:183
[0x01389198] installPluginPackage() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/plugins_repo/apRetargetingDriverExternal/plugins/apRetargeting/lib/Dal/Drivers/tests/integration/External.plg.test.php:28
[0x01388f80] setUp() 
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/simpletest/invoker.php:67
[0x01388e50] inv

Req #55788 [Com]: test redirects should abide SHOW_ONLY_GROUPS in run-tests.php

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=55788&edit=1

 ID: 55788
 Comment by:     tyr...@php.net
 Reported by:    tyr...@php.net
 Summary:test redirects should abide SHOW_ONLY_GROUPS in
 run-tests.php
 Status: Open
 Type:   Feature/Change Request
 Package:Testing related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

as Hannes asked, I update the patch with the following:
the groupname for redirect is REDIRECT, as it is more clear what it does than 
-->
I also updated the code, so now it prints 
REDIRECT $tests ($tested [$tested_file]) begin\n
instead of
--> $tests ($tested [$tested_file]) begin\n
so the group name, and the ouput is consistent as for the other groupnames.
I also updated the help to list the possible values for -g (aka 
SHOW_ONLY_GROUPS)


Previous Comments:

[2011-09-26 21:55:08] tyr...@php.net

Description:

currently the test redirects(show_redirect_start() and show_redirect_ends()) 
will 
always print two lines to the output, ignoring the value of SHOW_ONLY_GROUPS.
I think that it would be more consistent, if those lines could be controlled 
the 
same way, as we do with everything else.
this change would only noticeable for those who run the test suite with custom 
options (passing the SHOW_ONLY_GROUPS environment variable to make test or the 
argument -g to run-tests.php).
the attached patch is pretty straightforward, you can pass the ---> if you need 
the ---> lines in your testsuite output.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55788&edit=1

Req #55788 [PATCH]: test redirects should abide SHOW_ONLY_GROUPS in run-tests.php

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=55788&edit=1

 ID: 55788
 Patch added by:     tyr...@php.net
 Reported by:    tyr...@php.net
 Summary:test redirects should abide SHOW_ONLY_GROUPS in
 run-tests.php
 Status: Open
 Type:   Feature/Change Request
 Package:Testing related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: run-tests.php.diff
Revision:   1317252015
URL:
https://bugs.php.net/patch-display.php?bug=55788&patch=run-tests.php.diff&revision=1317252015


Previous Comments:

[2011-09-28 23:18:46] tyr...@php.net

as Hannes asked, I update the patch with the following:
the groupname for redirect is REDIRECT, as it is more clear what it does than 
-->
I also updated the code, so now it prints 
REDIRECT $tests ($tested [$tested_file]) begin\n
instead of
--> $tests ($tested [$tested_file]) begin\n
so the group name, and the ouput is consistent as for the other groupnames.
I also updated the help to list the possible values for -g (aka 
SHOW_ONLY_GROUPS)


[2011-09-26 21:55:08] tyr...@php.net

Description:

currently the test redirects(show_redirect_start() and show_redirect_ends()) 
will 
always print two lines to the output, ignoring the value of SHOW_ONLY_GROUPS.
I think that it would be more consistent, if those lines could be controlled 
the 
same way, as we do with everything else.
this change would only noticeable for those who run the test suite with custom 
options (passing the SHOW_ONLY_GROUPS environment variable to make test or the 
argument -g to run-tests.php).
the attached patch is pretty straightforward, you can pass the ---> if you need 
the ---> lines in your testsuite output.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55788&edit=1

[PHP-BUG] Bug #60074 [NEW]: Stack trace truncated for long paths

[tyr...@php.net]

From: tyrael
Operating system: 
PHP version:  5.4.0beta1
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Stack trace truncated for long paths

Description:

running the test script(via php -n -f test.php) in my home directory gives
me:

Fatal error: Uncaught exception 'Exception' with message 'Foo' in 
/home/tyrael/test.php:8
Stack trace:
#0 /home/tyrael/test.php(4): b()
#1 /home/tyrael/test.php(11): a()
#2 {main}
  thrown in /home/tyrael/test.php on line 8

running the same script in a directory with a long path gives me:

Fatal error: Uncaught exception 'Exception' with message 'Foo' in 
/home/tyrael/12345678901234567890123456789012345678901234567890/1234567890123456
7890123456789012345678901234567890/123456789012345678901234567890123456789012345
67890/12345678901234567890123456789012345678901234567890/12345678901234567890123
456789012345678901234567890/12345678901234567890123456789012345678901234567890/1
2345678901234567890123456789012345678901234567890/123456789012345678901234567890
12345678901234567890/foo/12345678901234567890123456789012345678901234567890/1234
5678901234567890123456789012345678901234567890/123456789012345678901234567890123
45678901234567890/12345678901234567890123456789012345678901234567890/12345678901
234567890123456789012345678901234567890/1234567890123456789012345678901234567890
1234567890/12345678901234567890123456789012345678901234567890/123456789012345678
90123456789012345678901234567890/12345678901234567890123456789012345678901234567
890/12345678901234567890123456789012345678901234567890/1234567890123456789012345
67890123456 in 
/home/tyrael/12345678901234567890123456789012345678901234567890/1234567890123456
7890123456789012345678901234567890/123456789012345678901234567890123456789012345
67890/12345678901234567890123456789012345678901234567890/12345678901234567890123
456789012345678901234567890/12345678901234567890123456789012345678901234567890/1
2345678901234567890123456789012345678901234567890/123456789012345678901234567890
12345678901234567890/foo/12345678901234567890123456789012345678901234567890/1234
5678901234567890123456789012345678901234567890/123456789012345678901234567890123
45678901234567890/12345678901234567890123456789012345678901234567890/12345678901
234567890123456789012345678901234567890/1234567890123456789012345678901234567890
1234567890/12345678901234567890123456789012345678901234567890/123456789012345678
90123456789012345678901234567890/12345678901234567890123456789012345678901234567
890/12345678901234567890123456789012345678901234567890/1234567890123456789012345
6789012345678901234567890/12345678901234567890123456789012345678901234567890/123
45678901234567890123456789012345678901234567890/12345678901234567890123456789012
345678901234567890/12345678901234567890123456789012345678901234567890/1234567890
1234567890123456789012345678901234567890/123456789012345678901234567890123456789
01234567890/12345678901234567890123456789012345678901234567890/test.php on
line 
8

As you can see, the output doesn't contain the Stack trace anymore.

Test script:
---
// create a directory with a long path and run this script from that
directory 

https://bugs.php.net/bug.php?id=60074&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60074&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60074&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60074&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60074&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60074&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60074&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60074&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60074&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60074&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60074&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60074&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60074&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60074&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60074&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60074&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60074&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60074&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60074&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60074&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60074&r

Bug #60074 [Com]: Stack trace truncated for long paths

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60074&edit=1

 ID: 60074
 Comment by:     tyr...@php.net
 Reported by:    tyr...@php.net
 Summary:Stack trace truncated for long paths
 Status: Bogus
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.4.0beta1
 Block user comment: N
 Private report: N

 New Comment:

"When would you ever need a thousand character path, honestly?!"
the problem is reproducible with a much shorter path, as Felipe pointed out the 
log_errors_max_len defaults to 1024, so you can easily bump into this either 
with 
a moderately long path, or with a long error/stack trace.
I purposely used a very long path in my report to point out that it is possible 
to 
completely truncate the stack trace.


Previous Comments:

[2011-10-19 03:00:42] anon at anon dot anon

When would you ever need a thousand character path, honestly?!


[2011-10-18 23:03:15] fel...@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

You have to change the log_errors_max_len INI entry. (defaults to 1024)


[2011-10-16 22:44:04] tyr...@php.net

Description:

running the test script(via php -n -f test.php) in my home directory gives me:

Fatal error: Uncaught exception 'Exception' with message 'Foo' in 
/home/tyrael/test.php:8
Stack trace:
#0 /home/tyrael/test.php(4): b()
#1 /home/tyrael/test.php(11): a()
#2 {main}
  thrown in /home/tyrael/test.php on line 8

running the same script in a directory with a long path gives me:

Fatal error: Uncaught exception 'Exception' with message 'Foo' in 
/home/tyrael/12345678901234567890123456789012345678901234567890/1234567890123456
7890123456789012345678901234567890/123456789012345678901234567890123456789012345
67890/12345678901234567890123456789012345678901234567890/12345678901234567890123
456789012345678901234567890/12345678901234567890123456789012345678901234567890/1
2345678901234567890123456789012345678901234567890/123456789012345678901234567890
12345678901234567890/foo/12345678901234567890123456789012345678901234567890/1234
5678901234567890123456789012345678901234567890/123456789012345678901234567890123
45678901234567890/12345678901234567890123456789012345678901234567890/12345678901
234567890123456789012345678901234567890/1234567890123456789012345678901234567890
1234567890/12345678901234567890123456789012345678901234567890/123456789012345678
90123456789012345678901234567890/12345678901234567890123456789012345678901234567
890/12345678901234567890123456789012345678901234567890/1234567890123456789012345
67890123456 in 
/home/tyrael/12345678901234567890123456789012345678901234567890/1234567890123456
7890123456789012345678901234567890/123456789012345678901234567890123456789012345
67890/12345678901234567890123456789012345678901234567890/12345678901234567890123
456789012345678901234567890/12345678901234567890123456789012345678901234567890/1
2345678901234567890123456789012345678901234567890/123456789012345678901234567890
12345678901234567890/foo/12345678901234567890123456789012345678901234567890/1234
5678901234567890123456789012345678901234567890/123456789012345678901234567890123
45678901234567890/12345678901234567890123456789012345678901234567890/12345678901
234567890123456789012345678901234567890/1234567890123456789012345678901234567890
1234567890/12345678901234567890123456789012345678901234567890/123456789012345678
90123456789012345678901234567890/12345678901234567890123456789012345678901234567
890/12345678901234567890123456789012345678901234567890/1234567890123456789012345
6789012345678901234567890/12345678901234567890123456789012345678901234567890/123
45678901234567890123456789012345678901234567890/12345678901234567890123456789012
345678901234567890/12345678901234567890123456789012345678901234567890/1234567890
1234567890123456789012345678901234567890/123456789012345678901234567890123456789
01234567890/12345678901234567890123456789012345678901234567890/test.php on line 
8

As you can see, the output doesn't contain the Stack trace anymore.

Test script:
---
// create a directory with a long path and run this script from that directory 

https://bugs.php.net/bug.php?id=60074&edit=1

[PHP-BUG] Bug #60106 [NEW]: stream_socket_server + long unix socket path = 'Unknown error'

[tyr...@php.net]

From: tyrael
Operating system: linux debian squeeze 64 bit
PHP version:  5.4.0beta2
Package:  Streams related
Bug Type: Bug
Bug description:stream_socket_server + long unix socket path = 'Unknown error'

Description:

this works:
./sapi/cli/php -r '$file = "/tmp/".str_repeat("a", 
101);stream_socket_server("unix://".$file) && unlink($file);'

this isn't:
./sapi/cli/php -r '$file = "/tmp/".str_repeat("a", 
102);stream_socket_server("unix://".$file) && unlink($file);'

gives me an:

Warning: stream_socket_server(): unable to connect to 
unix:///tmp/
aa (Unknown error) in Command line code on
line 
1

I didn't found any mention in the documentation about restrictions on the
length 
of the socket file.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=60106&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60106&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60106&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60106&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60106&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60106&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60106&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60106&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60106&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60106&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60106&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60106&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60106&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60106&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60106&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60106&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60106&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60106&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60106&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60106&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60106&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60106&r=mysqlcfg

[PHP-BUG] Bug #60186 [NEW]: stream_select ignores the timeout on freebsd

[tyr...@php.net]

From: tyrael
Operating system: freebsd
PHP version:  5.3SVN-2011-11-01 (SVN)
Package:  Streams related
Bug Type: Bug
Bug description:stream_select ignores the timeout on freebsd

Description:

I was running the php testsuite on FreeBSD 8.2, when I noticed that 
ext/spl/tests/bug60082.phpt hangs the whole test.
That test reproduces a bug where the php executor will be pushed into an
infinite 
loop, so the timeout should kick-in, and proc_terminate the runaway test.
but it doesn't happen on FreeBSD.
for the record, I'm going to change the test to be skipped on FreeBSD,
because it 
is now not possible to run the testsuite, as it requires manually killing
that 
test on each run. PITA.

Test script:
---
see ext/spl/tests/bug60082.phpt, basically proc_open-ing a process with an
infinite loop and calling stream_select on it passing a timeout through the
tv_sec argument.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=60186&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60186&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60186&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60186&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60186&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60186&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60186&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60186&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60186&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60186&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60186&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60186&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60186&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60186&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60186&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60186&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60186&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60186&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60186&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60186&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60186&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60186&r=mysqlcfg

[PHP-BUG] Bug #60222 [NEW]: time_nanosleep won't throw a warning for negative second

[tyr...@php.net]

From: tyrael
Operating system: freebsd
PHP version:  Irrelevant
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:time_nanosleep won't throw a warning for negative second

Description:

time_nanosleep(-1, 0); should trigger "Warning: time_nanosleep():
nanoseconds was 
not in the range 0 to 999 999 999 or seconds was negative" but on FreeBSD
8.2 it 
will just sleep 0 sec.
this also makes ext/standard/tests/misc/time_nanosleep_error3.phpt fail on
FreeBSD

Test script:
---
https://bugs.php.net/bug.php?id=60222&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60222&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60222&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60222&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60222&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60222&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60222&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60222&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60222&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60222&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60222&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60222&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60222&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60222&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60222&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60222&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60222&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60222&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60222&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60222&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60222&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60222&r=mysqlcfg

[PHP-BUG] Bug #60223 [NEW]: 5.4 and trunk segfaults when running the symfony2 testsuite

[tyr...@php.net]

From: tyrael
Operating system: linux
PHP version:  5.4SVN-2011-11-05 (SVN)
Package:  Reproducible crash
Bug Type: Bug
Bug description:5.4 and trunk segfaults when running the symfony2 testsuite

Description:

5.4 and trunk segfaults running the testsuite:
http://ci.qa.php.net/view/php-userland/job/php-symfony2/75/label=debian-
amd64,phpversion=5.4/console
http://ci.qa.php.net/view/php-userland/job/php-symfony2/75/label=debian-
amd64,phpversion=trunk/console
while 5.3 runs the suite successfully:
http://ci.qa.php.net/view/php-userland/job/php-symfony2/75/label=debian-
amd64,phpversion=5.3/console
I rerun the command with --debug for phpunit, and the last test before the

segfault is 
Symfony\Tests\Bridge\Doctrine\Form\Type\EntityTypeTest::testSubmitMultipleExpand
ed.
I rerun the test only for that test 
class(Symfony\Tests\Bridge\Doctrine\Form\Type\EntityTypeTest), and it is 
passing, no segfault.
The segfault also goes away, if I use --process-isolation for phpunit (will
run 
each test in a separate process, instead of running them in the same
process 
that is running phpunit), so it seems that there is no single snippet to 
reproduce the error.

here is the backtrace from the coredump that I got:

#0  0x008cdef5 in ZEND_SEND_VAR_SPEC_CV_HANDLER 
(execute_data=0x7f676823fa48) at
/home/jenkins/workspace/php-src-5.4-matrix-
build/architecture/x86-64/os/linux-debian-6.0/Zend/zend_vm_execute.h:26859
26859   && ARG_SHOULD_BE_SENT_BY_REF(EX(fbc), opline-
>op2.opline_num)) {
(gdb) bt
#0  0x008cdef5 in ZEND_SEND_VAR_SPEC_CV_HANDLER 
(execute_data=0x7f676823fa48) at
/home/jenkins/workspace/php-src-5.4-matrix-
build/architecture/x86-64/os/linux-debian-6.0/Zend/zend_vm_execute.h:26859
#1  0x007fcfa0 in execute (op_array=0x4d2b118) at 
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/Zend/zend_vm_execute.h:410
#2  0x007be329 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /home/jenkins/workspace/php-src-5.4-matrix-
build/architecture/x86-64/os/linux-debian-6.0/Zend/zend.c:1272
#3  0x00731b6b in php_execute_script (primary_file=0x7fff101430b0)
at 
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/main/main.c:2414
#4  0x0090e88a in do_cli (argc=10, argv=0x7fff10143468) at 
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/sapi/cli/php_cli.c:983
#5  0x0090f786 in main (argc=10, argv=0x7fff10143468) at 
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/sapi/cli/php_cli.c:1356


if you need any help to further debug this, just ping me.

Test script:
---
git clone git://github.com/symfony/symfony.git;
cd symfony;
./PATH_TO_5.4_BINARY -d include_path=.:/usr/share/php:/usr/share/pear -d
date.timezone=UTC -d memory_limit=512M ./vendors.php;
./PATH_TO_5.4_BINARY -d include_path=.:/usr/share/php:/usr/share/pear -d
date.timezone=UTC -d memory_limit=512M /usr/bin/phpunit
--log-junit=junit.xml;

Expected result:

no segfault

Actual result:
--
segfault

-- 
Edit bug report at https://bugs.php.net/bug.php?id=60223&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60223&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60223&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60223&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60223&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60223&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60223&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60223&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60223&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60223&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60223&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60223&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60223&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60223&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60223&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60223&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60223&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60223&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60223&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60223&r=float
No Zend Extensions:  
https://b

Bug #60223 [Com]: 5.4 and trunk segfaults when running the symfony2 testsuite

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60223&edit=1

 ID: 60223
 Comment by:     tyr...@php.net
 Reported by:    tyr...@php.net
 Summary:5.4 and trunk segfaults when running the symfony2
 testsuite
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   linux
 PHP Version:5.4SVN-2011-11-05 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

yeah, it seems as http://svn.php.net/viewvc?view=revision&revision=318907 fixed 
this one too.


Previous Comments:

[2011-11-06 16:10:42] fel...@php.net

Probably related to bug #60104


[2011-11-05 12:15:07] tyr...@php.net

Description:

5.4 and trunk segfaults running the testsuite:
http://ci.qa.php.net/view/php-userland/job/php-symfony2/75/label=debian-
amd64,phpversion=5.4/console
http://ci.qa.php.net/view/php-userland/job/php-symfony2/75/label=debian-
amd64,phpversion=trunk/console
while 5.3 runs the suite successfully:
http://ci.qa.php.net/view/php-userland/job/php-symfony2/75/label=debian-
amd64,phpversion=5.3/console
I rerun the command with --debug for phpunit, and the last test before the 
segfault is 
Symfony\Tests\Bridge\Doctrine\Form\Type\EntityTypeTest::testSubmitMultipleExpand
ed.
I rerun the test only for that test 
class(Symfony\Tests\Bridge\Doctrine\Form\Type\EntityTypeTest), and it is 
passing, no segfault.
The segfault also goes away, if I use --process-isolation for phpunit (will run 
each test in a separate process, instead of running them in the same process 
that is running phpunit), so it seems that there is no single snippet to 
reproduce the error.

here is the backtrace from the coredump that I got:

#0  0x008cdef5 in ZEND_SEND_VAR_SPEC_CV_HANDLER 
(execute_data=0x7f676823fa48) at /home/jenkins/workspace/php-src-5.4-matrix-
build/architecture/x86-64/os/linux-debian-6.0/Zend/zend_vm_execute.h:26859
26859   && ARG_SHOULD_BE_SENT_BY_REF(EX(fbc), opline-
>op2.opline_num)) {
(gdb) bt
#0  0x008cdef5 in ZEND_SEND_VAR_SPEC_CV_HANDLER 
(execute_data=0x7f676823fa48) at /home/jenkins/workspace/php-src-5.4-matrix-
build/architecture/x86-64/os/linux-debian-6.0/Zend/zend_vm_execute.h:26859
#1  0x007fcfa0 in execute (op_array=0x4d2b118) at 
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/Zend/zend_vm_execute.h:410
#2  0x007be329 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /home/jenkins/workspace/php-src-5.4-matrix-
build/architecture/x86-64/os/linux-debian-6.0/Zend/zend.c:1272
#3  0x00731b6b in php_execute_script (primary_file=0x7fff101430b0) at 
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/main/main.c:2414
#4  0x0090e88a in do_cli (argc=10, argv=0x7fff10143468) at 
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/sapi/cli/php_cli.c:983
#5  0x0090f786 in main (argc=10, argv=0x7fff10143468) at 
/home/jenkins/workspace/php-src-5.4-matrix-build/architecture/x86-64/os/linux-
debian-6.0/sapi/cli/php_cli.c:1356


if you need any help to further debug this, just ping me.

Test script:
---
git clone git://github.com/symfony/symfony.git;
cd symfony;
./PATH_TO_5.4_BINARY -d include_path=.:/usr/share/php:/usr/share/pear -d 
date.timezone=UTC -d memory_limit=512M ./vendors.php;
./PATH_TO_5.4_BINARY -d include_path=.:/usr/share/php:/usr/share/pear -d 
date.timezone=UTC -d memory_limit=512M /usr/bin/phpunit --log-junit=junit.xml;

Expected result:

no segfault

Actual result:
--
segfault






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60223&edit=1

[PHP-BUG] Bug #60285 [NEW]: setting REPORT_EXIT_STATUS for make test won't work

[tyr...@php.net]

From: tyrael
Operating system: 
PHP version:  trunk-SVN-2011-11-13 (SVN)
Package:  Testing related
Bug Type: Bug
Bug description:setting REPORT_EXIT_STATUS for make test won't work

Description:

when setting up the ci environment, I noticed, that passing the
REPORT_EXIT_STATUS 
environment variable to run-tests.php works, but passing the same thing to
make 
test won't.
after some debugging with Hannes, we figured out, that the test target in
the 
Makefile overuses the error suppression 
operator(http://sunsite.ualberta.ca/Documentation/Gnu/make-
3.79/html_chapter/make_5.html#SEC48).
if you check the test target (http://svn.php.net/viewvc/php/php-
src/trunk/Makefile.global?view=markup#l88) you can see that the whole
target is a 
one-liner prefixed with -
which means that anything can fail in the target, it will still report
success. :/

the same pattern is used for many of the targets.
Could somebody look into this?

Test script:
---
REPORT_EXIT_STATUS=1 make test;
echo $?;

Expected result:

should print non-zero if there are failed tests.

Actual result:
--
always prints 0

-- 
Edit bug report at https://bugs.php.net/bug.php?id=60285&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60285&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60285&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60285&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60285&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60285&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60285&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60285&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60285&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60285&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60285&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60285&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60285&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60285&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60285&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60285&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60285&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60285&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60285&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60285&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60285&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60285&r=mysqlcfg

Bug #60285 [Com]: setting REPORT_EXIT_STATUS for make test won't work

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60285&edit=1

 ID: 60285
 Comment by:     tyr...@php.net
 Reported by:    tyr...@php.net
 Summary:setting REPORT_EXIT_STATUS for make test won't work
 Status: Open
 Type:   Bug
 Package:Testing related
 PHP Version:trunk-SVN-2011-11-13 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

I just checked, it was introduced way back in 2003:
http://svn.php.net/viewvc?view=revision&revision=135844


Previous Comments:

[2011-11-13 18:35:57] tyr...@php.net

Description:

when setting up the ci environment, I noticed, that passing the 
REPORT_EXIT_STATUS 
environment variable to run-tests.php works, but passing the same thing to make 
test won't.
after some debugging with Hannes, we figured out, that the test target in the 
Makefile overuses the error suppression 
operator(http://sunsite.ualberta.ca/Documentation/Gnu/make-
3.79/html_chapter/make_5.html#SEC48).
if you check the test target (http://svn.php.net/viewvc/php/php-
src/trunk/Makefile.global?view=markup#l88) you can see that the whole target is 
a 
one-liner prefixed with -
which means that anything can fail in the target, it will still report success. 
:/

the same pattern is used for many of the targets.
Could somebody look into this?

Test script:
---
REPORT_EXIT_STATUS=1 make test;
echo $?;

Expected result:

should print non-zero if there are failed tests.

Actual result:
--
always prints 0






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60285&edit=1

Req #60360 [Com]: Add a phpinfo() somewhere on GCOV

[tyr...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60360&edit=1

 ID: 60360
 Comment by:     tyr...@php.net
 Reported by:pierr...@php.net
 Summary:Add a phpinfo() somewhere on GCOV
 Status: Open
 Type:   Feature/Change Request
 Package:Unknown/Other Function
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

It should be generated per build basis, so we can check it for each execution.
If Nuno doesn't mind, I can do this, as it seems trivial to implement.


Previous Comments:

[2011-11-22 20:09:17] pierr...@php.net

Description:

It would be nice to have a phpinfo() somewhere on the gcov server to know which 
version of a specific lib is used.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60360&edit=1