Bug #55497 [Com]: Credits URL Security ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000

[support at ecommercewebsites dot com dot au]

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

 ID: 55497
 Comment by: support at ecommercewebsites dot com dot au
 Reported by:mhaisley at gmail dot com
 Summary:Credits URL Security
 ?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1
 Status: Not a bug
 Type:   Bug
 Package:PHP options/info functions
 Operating System:   Any
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Nope - this is not a bug.
Just disable it in your config file.


Previous Comments:

[2011-08-25 03:27:29] mhaisley at gmail dot com

Sorry, but it is a real issue. 

It should be disabled by default.


[2011-08-25 00:19:08] johan...@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

Attackers can easily brute force without knowing the version. But if youfear 
this makes things insecure you can set expose_php=Off in php.ini.


[2011-08-24 02:35:55] mhaisley at gmail dot com

Description:

?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 displays php credits, it also 
displays 
credits for all modules.

This effectively makes it a security issue since it allows an attacker to scan 
for 
a specific vulnerable module and then exploit it. 

Test script:
---
http://php.net/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1

Expected result:

?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C1 should be disabled by default, or 
display generic information only.   The current behavior is unacceptable. 

Actual result:
--
Specific information regarding installed modules is displayed. 






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

Bug #61045 [Csd]: fpm don't send error log to fastcgi clients(nginx)

[laruence]

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

 ID: 61045
 Updated by: larue...@php.net
 Reported by:lxlight at gmail dot com
 Summary:fpm don't send error log to fastcgi clients(nginx)
 Status: Closed
 Type:   Bug
 Package:FPM related
 Operating System:   Linux
 PHP Version:5.3.10
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

you can patch that patch your self.. if you really want to insist to 5.3.10


Previous Comments:

[2012-09-11 22:07:11] ryan dot pendergast at gmail dot com

Is there a work around for us that are stuck on 5.3.10?


[2012-06-15 06:00:41] f...@php.net

yes this fix will go live in the next 5.3 and 5.4 release.


[2012-06-15 05:25:40] hb at peytz dot dk

Any news about when this will see a release? Maybe 5.3.15 ? 5.4.5?


[2012-05-22 17:46:33] arohter at gmail dot com

Does this mean the fix will go live in the official 5.3.14 release?


[2012-05-22 16:54:43] a...@php.net

Automatic comment on behalf of fat
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=faca4e08b4dffbf00b1bc20fc5d4e310b3f99c13
Log: - Fixed bug #61045 (fpm don't send error log to fastcgi clients)




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


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

Bug #63055 [Asn]: Segfault in zend_gc with SF2 testsuite

[laruence]

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

 ID: 63055
 Updated by: larue...@php.net
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
 Status: Assigned
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

still can not reproduce it,

php at wallbash.com ,  could you give me a access to your testing box? that 
will 
be useful.. :)


Previous Comments:

[2012-09-11 14:28:16] php at wallbash dot com

Fixed reproduce instructions: https://gist.github.com/3690351; Maybe that helps 
you laruence.

I've misspelled the phpunit mock object dependency and it doesn't work with 
newer versions (as it, i assume, involves object cloning that newer versions 
have turned off). Any other minor versions don't lead to the segfault.


@reeze,

(gdb) zbacktrace

(gdb) [0x7ff1428d4ea8] 
preg_match_all("/@requires\s+(?Pfunction|extension)\s(?P([^\40]+))\r?$/m",
 
"/**\12\40*\40Note\40that\40there\40are\40some\40values\40written\40like\40-2147483647\40-\401.\40This\40is\40the\40lower\4032bit\40int\40max\40and\40is\40a\40known\12\40*\40behavior\40of\40PHP.\12\40*/\12/**\12\40\40\40\40\40*\40@dataProvider\40formatCurrencyWithCurrencyStyleBrazilianRealRoundingProvider\12\40\40\40\40\40*/",
 array(7)[0x14916c30]) /usr/share/pear/PHPUnit/Util/Test.php:126 
[0x7ff1428d4ab0] 
getRequirements("Symfony\Component\Locale\Tests\Stub\StubNumberFormatterTest", 
"testFormatCurrencyWithCurrencyStyleBrazilianRealRoundingStub") 
/usr/share/pear/PHPUnit/Framework/TestCase.php:558 
[0x7ff1428d4378] setRequirementsFromAnnotation() 
/usr/share/pear/PHPUnit/Framework/TestCase.php:586 
[0x7ff1428d31b0] checkRequirements() 
/usr/share/pear/PHPUnit/Framework/TestCase.php:823 
[0x7ff1428d1d38] runBare() /usr/share/pear/PHPUnit/Framework/TestResult.php:649 
[0x7ff1428d0dd8] run(object[0x747e368]) 
/usr/share/pear/PHPUnit/Framework/TestCase.php:770 
[0x7ff1428d0cd8] run(object[0xa6fcfe0]) 
/usr/share/pear/PHPUnit/Framework/TestSuite.php:776 
[0x7ff1428cf980] runTest(object[0x747e368], object[0xa6fcfe0]) 
/usr/share/pear/PHPUnit/Framework/TestSuite.php:746 
[0x7ff1428ce610] run(object[0xa6fcfe0], false, array(0)[0xa6fa9e8], 
array(1)[0xa7390a8], false) /usr/share/pear/PHPUnit/Framework/TestSuite.php:706 
[0x7ff1428cd2a0] run(object[0xa6fcfe0], false, array(0)[0x14735b38], 
array(1)[0x14735cf0], false) 
/usr/share/pear/PHPUnit/Framework/TestSuite.php:706 
[0x7ff1428caea0] run(object[0xa6fcfe0], false, array(0)[0xab473f0], 
array(1)[0xab475a8], false) /usr/share/pear/PHPUnit/TextUI/TestRunner.php:325 
[0x7ff1428ca528] doRun(object[0x7ff13c2c3ed8], array(5)[0xab48718]) 
/usr/share/pear/PHPUnit/TextUI/Command.php:177 
[0x7ff1428ca360] run(array(1)[0x6b7c498], true) 
/usr/share/pear/PHPUnit/TextUI/Command.php:130 
[0x7ff1428ca0e8] main() /usr/bin/phpunit:46 
(gdb) 

Hope that helps :)


[2012-09-11 08:48:58] larue...@php.net

intl

Internationalization support => enabled
version => 1.1.0
ICU version => 3.6


[2012-09-11 06:57:39] reeze dot xia at gmail dot com

gdb > zbactrace   --->  gdb > zbacktrace   missing a 'k' :)


[2012-09-11 06:56:49] reeze dot xia at gmail dot com

Hi wallbash,
  when you got a backtrace, you could source php-src's backtrace of php script

gdb > source path/to/php-src/.gdbinit
gdb > zbactrace 
then you may see a php level script, then we could find where cause the php 
crash


[2012-09-11 06:53:26] reeze dot xia at gmail dot com

>From the backtrace this seems a test for ext: intl, 
I can't install intl ext in my box because of compile issue.

@larucene, do you see some test skip for intl or did you enabled intl extsion?




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


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

Req #62860 [ReO->Opn]: Moar magic methods! __constructStatic(), __getStatic(), __setStatic(), __get

[laruence]

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

 ID: 62860
 Updated by: larue...@php.net
 Reported by:michaelduff2 at yahoo dot com
 Summary:Moar magic methods! __constructStatic(),
 __getStatic(), __setStatic(), __get
-Status: Re-Opened
+Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N



Previous Comments:

[2012-09-12 03:35:35] larue...@php.net

 The fact that his code defies the point of using magic getters and 
setters should have been a hint.
 __get and __set are meant for inaccessible variables.


[2012-09-12 02:52:03] larue...@php.net

they are not dup...


[2012-09-12 02:41:08] re...@php.net

Duplicate to https://bugs.php.net/bug.php?id=45002 closed.


[2012-09-05 15:12:01] matthew dot bonner at gmail dot com

Sorry in my last example there was a typo, and what I meant was:
I would like to add that being magic methods, it would be nice if they could do 
a little more magic, ie:

class Classy {
  public static $foo = 'foo';
  public $bar = 'bar';

  public static function __get ($propertyName) {
return self::$propertyName;
  }

  public function __get ($propertyName) {
return $this->$propertyName;
  }
}

echo Classy::$foo; // outputs "foo"
$classy = new Classy;
echo $classy->bar; // outputs "bar"


[2012-09-05 15:10:36] matthew dot bonner at gmail dot com

I would like to add that being magic methods, it would be nice if they could do 
a little more magic, ie:

class Classy {
  public static $foo = 'foo';
  public $bar = 'bar';

  public static function __get ($propertyName) {
return $this->$propertyName;
  }

  public function __get ($propertyName) {
return self::$propertyName;
  }
}

echo Classy::$foo; // outputs "foo"
$classy = new Classy;
echo $classy->bar; // outputs "bar"




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


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

Req #62860 [ReO]: Moar magic methods! __constructStatic(), __getStatic(), __setStatic(), __get

[laruence]

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

 ID: 62860
 Updated by: larue...@php.net
 Reported by:michaelduff2 at yahoo dot com
 Summary:Moar magic methods! __constructStatic(),
 __getStatic(), __setStatic(), __get
 Status: Re-Opened
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

 The fact that his code defies the point of using magic getters and 
setters should have been a hint.
 __get and __set are meant for inaccessible variables.


Previous Comments:

[2012-09-12 02:52:03] larue...@php.net

they are not dup...


[2012-09-12 02:41:08] re...@php.net

Duplicate to https://bugs.php.net/bug.php?id=45002 closed.


[2012-09-05 15:12:01] matthew dot bonner at gmail dot com

Sorry in my last example there was a typo, and what I meant was:
I would like to add that being magic methods, it would be nice if they could do 
a little more magic, ie:

class Classy {
  public static $foo = 'foo';
  public $bar = 'bar';

  public static function __get ($propertyName) {
return self::$propertyName;
  }

  public function __get ($propertyName) {
return $this->$propertyName;
  }
}

echo Classy::$foo; // outputs "foo"
$classy = new Classy;
echo $classy->bar; // outputs "bar"


[2012-09-05 15:10:36] matthew dot bonner at gmail dot com

I would like to add that being magic methods, it would be nice if they could do 
a little more magic, ie:

class Classy {
  public static $foo = 'foo';
  public $bar = 'bar';

  public static function __get ($propertyName) {
return $this->$propertyName;
  }

  public function __get ($propertyName) {
return self::$propertyName;
  }
}

echo Classy::$foo; // outputs "foo"
$classy = new Classy;
echo $classy->bar; // outputs "bar"


[2012-09-05 15:06:06] matthew dot bonner at gmail dot com

The additional magic methods with static support have been requested over and 
over for well over 5 years now. Is PHP a dying language because the developers 
don't have the time to provide essential functionality?

There are so many hacks going about now to try and provide essential 
functionality and there is so much messy code all over the place to support 
what should be part of PHP 5 as standard.

Sorry for my raving and ranting but the reputation of PHP is being severely 
damaged by not providing the essentials.

.NET has static accessor and mutator support, Java does too. All the big 
languages do apart from PHP.

class PLEASE_SUPPORT_AT_A_MINIMUM {
  public static function __construct () {}
  public static function __set ($propertyName, $propertyValue) {}
  public static function __get ($propertyName) {}

  public function setConstDynamically () {
const Foo = 'foo';
echo self::Foo;
  }
}

Otherwise I will fork PHP and provide this essential functionality myself which 
will ultimately result in the death of the original PHP.




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

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


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

Bug #47640 [Fbk->Opn]: Session does not unlock file in /tmp/

[aharvey]

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

 ID: 47640
 Updated by: ahar...@php.net
 Reported by:manuel dot schmitt at manitu dot de
-Summary:Session does not close file in /tmp/
+Summary:Session does not unlock file in /tmp/
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Session related
 Operating System:   Linux
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

Explanation provided separately, since it's not relevant to this bug. Bug 
reopened.


Previous Comments:

[2012-09-12 03:10:26] larue...@php.net

...maybe it's chagned by the reporter self, no action history log in the 
changes 
tab


[2012-09-11 20:39:24] kriscr...@php.net

Could somebody explain why the status was changed to "Not a bug?"  I'm not 
seeing 
anything in the comments to indicate why that edit was made.  Looks like a real 
bug to me and everything else seems to check-out, so I'm assuming that was an 
error given the lack of an explanation.

I'm re-opening this with "Feedback" status.  If you're the one who closed this 
(the edit history is empty), please post a comment explaining your reasoning.  
Thanks!


[2012-05-27 01:04:29] bugs dot php dot net at jrs-s dot net

I worked around this problem by simply moving sessions from file storage to 
memcache.

session.save_handler = memcache
session.save_path = "tcp://serv01:11211,tcp://serv02:11211,tcp://serv03:11211"

An application pool that had been creeping up to MaxCli (900 children apiece, 
in 
this case) within a couple hours of a restart due to this FLOCK issue settled 
down and has now been running happily for several days on fewer than 150 
children per server.  I highly recommend just NOT USING php's file based 
session 
storage in the first place, because of exactly this issue.


[2012-02-01 19:50:15] pio at rdl dot pl

Hello !

Is there any news with this issue ?

Piotr


[2010-10-24 12:29:55] alex dot linte at gmail dot com

Hello,

I have the same mistake :

host:~# date
dimanche 24 octobre 2010, 12:10:03 (UTC+0200)
host:~# ps faux | grep php
juritrav 17749  0.0  0.0 118988 11616 ?S00:11   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 17818  0.0  0.0 117764  9536 ?S00:12   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 18004  0.0  0.0 117764  9536 ?S00:14   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12573  0.0  0.1 138812 31784 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12574  0.0  0.0 117492  9396 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
duphpuser 12594  0.0  0.0 117492  9396 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12675  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12682  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12695  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi

So php-cgi scripts run for ever until I kill its manually.

I take the sample of process 18004 : 


front2:~# strace -p18004
Process 18004 attached - interrupt to quit
flock(3, LOCK_EX


host# lsof -p18004

php-cgi 18004 suphpuser3uW  REG9,1   7   897723 
/tmp/php5/sess_ (deleted)


So the php script tries to lock a session file (file descriptor 3) that has 
been deleted by the PHP garbage collector.

When the garbage collector delete a session file, it doesn't take care that any 
php process still using this session file.
Then the php process can't lock the file because it doesn't exist anymore, the 
php-cgi process is blocked

I have the problem with the following version of php :

PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug  4 2010 
06:06:53)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies

The cron job for php (script that delete session on debian) is disabled et the 
garbage collector php is enabled in php.ini file :

session.gc_probability = 1
session.gc_divisor = 100


Sorry for my english.

Alexandre LINTE




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


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

Bug #47640 [Fbk]: Session does not close file in /tmp/

[laruence]

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

 ID: 47640
 Updated by: larue...@php.net
 Reported by:manuel dot schmitt at manitu dot de
 Summary:Session does not close file in /tmp/
 Status: Feedback
 Type:   Bug
 Package:Session related
 Operating System:   Linux
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

...maybe it's chagned by the reporter self, no action history log in the 
changes 
tab


Previous Comments:

[2012-09-11 20:39:24] kriscr...@php.net

Could somebody explain why the status was changed to "Not a bug?"  I'm not 
seeing 
anything in the comments to indicate why that edit was made.  Looks like a real 
bug to me and everything else seems to check-out, so I'm assuming that was an 
error given the lack of an explanation.

I'm re-opening this with "Feedback" status.  If you're the one who closed this 
(the edit history is empty), please post a comment explaining your reasoning.  
Thanks!


[2012-05-27 01:04:29] bugs dot php dot net at jrs-s dot net

I worked around this problem by simply moving sessions from file storage to 
memcache.

session.save_handler = memcache
session.save_path = "tcp://serv01:11211,tcp://serv02:11211,tcp://serv03:11211"

An application pool that had been creeping up to MaxCli (900 children apiece, 
in 
this case) within a couple hours of a restart due to this FLOCK issue settled 
down and has now been running happily for several days on fewer than 150 
children per server.  I highly recommend just NOT USING php's file based 
session 
storage in the first place, because of exactly this issue.


[2012-02-01 19:50:15] pio at rdl dot pl

Hello !

Is there any news with this issue ?

Piotr


[2010-10-24 12:29:55] alex dot linte at gmail dot com

Hello,

I have the same mistake :

host:~# date
dimanche 24 octobre 2010, 12:10:03 (UTC+0200)
host:~# ps faux | grep php
juritrav 17749  0.0  0.0 118988 11616 ?S00:11   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 17818  0.0  0.0 117764  9536 ?S00:12   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 18004  0.0  0.0 117764  9536 ?S00:14   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12573  0.0  0.1 138812 31784 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12574  0.0  0.0 117492  9396 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
duphpuser 12594  0.0  0.0 117492  9396 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12675  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12682  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12695  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi

So php-cgi scripts run for ever until I kill its manually.

I take the sample of process 18004 : 


front2:~# strace -p18004
Process 18004 attached - interrupt to quit
flock(3, LOCK_EX


host# lsof -p18004

php-cgi 18004 suphpuser3uW  REG9,1   7   897723 
/tmp/php5/sess_ (deleted)


So the php script tries to lock a session file (file descriptor 3) that has 
been deleted by the PHP garbage collector.

When the garbage collector delete a session file, it doesn't take care that any 
php process still using this session file.
Then the php process can't lock the file because it doesn't exist anymore, the 
php-cgi process is blocked

I have the problem with the following version of php :

PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug  4 2010 
06:06:53)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies

The cron job for php (script that delete session on debian) is disabled et the 
garbage collector php is enabled in php.ini file :

session.gc_probability = 1
session.gc_divisor = 100


Sorry for my english.

Alexandre LINTE


[2009-05-03 12:07:47] manuel dot schmitt at manitu dot de

ACK, but as server administrator there *must* be a way to prevent this.

Admins do not have influence on the scripts that are used by webmasters.

So I think it's a PHP thing. Likely one should automatically close all sessions 
that were opened by scripts aborting / running into limits sets by php (e.g. 
exec time) etc. This should solve it.




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

Req #62860 [Dup->ReO]: Moar magic methods! __constructStatic(), __getStatic(), __setStatic(), __get

[laruence]

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

 ID: 62860
 Updated by: larue...@php.net
 Reported by:michaelduff2 at yahoo dot com
 Summary:Moar magic methods! __constructStatic(),
 __getStatic(), __setStatic(), __get
-Status: Duplicate
+Status: Re-Opened
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

they are not dup...


Previous Comments:

[2012-09-12 02:41:08] re...@php.net

Duplicate to https://bugs.php.net/bug.php?id=45002 closed.


[2012-09-05 15:12:01] matthew dot bonner at gmail dot com

Sorry in my last example there was a typo, and what I meant was:
I would like to add that being magic methods, it would be nice if they could do 
a little more magic, ie:

class Classy {
  public static $foo = 'foo';
  public $bar = 'bar';

  public static function __get ($propertyName) {
return self::$propertyName;
  }

  public function __get ($propertyName) {
return $this->$propertyName;
  }
}

echo Classy::$foo; // outputs "foo"
$classy = new Classy;
echo $classy->bar; // outputs "bar"


[2012-09-05 15:10:36] matthew dot bonner at gmail dot com

I would like to add that being magic methods, it would be nice if they could do 
a little more magic, ie:

class Classy {
  public static $foo = 'foo';
  public $bar = 'bar';

  public static function __get ($propertyName) {
return $this->$propertyName;
  }

  public function __get ($propertyName) {
return self::$propertyName;
  }
}

echo Classy::$foo; // outputs "foo"
$classy = new Classy;
echo $classy->bar; // outputs "bar"


[2012-09-05 15:06:06] matthew dot bonner at gmail dot com

The additional magic methods with static support have been requested over and 
over for well over 5 years now. Is PHP a dying language because the developers 
don't have the time to provide essential functionality?

There are so many hacks going about now to try and provide essential 
functionality and there is so much messy code all over the place to support 
what should be part of PHP 5 as standard.

Sorry for my raving and ranting but the reputation of PHP is being severely 
damaged by not providing the essentials.

.NET has static accessor and mutator support, Java does too. All the big 
languages do apart from PHP.

class PLEASE_SUPPORT_AT_A_MINIMUM {
  public static function __construct () {}
  public static function __set ($propertyName, $propertyValue) {}
  public static function __get ($propertyName) {}

  public function setConstDynamically () {
const Foo = 'foo';
echo self::Foo;
  }
}

Otherwise I will fork PHP and provide this essential functionality myself which 
will ultimately result in the death of the original PHP.


[2012-08-18 20:03:22] michaelduff2 at yahoo dot com

Description:

__constructStatic() - executed automatically on class definition

__getStatic() - executed when ClassName::$inaccessible_property is fetched

__setStatic() - executed when ClassName::$inaccessible_property is modified


The particular use case I have for this is self-loading configuration registry 
singletons:



Currently, I accomplish this with __callStatic() which needs the extra 
open-close parenthesis.  Ideally, we could get rid of the '$' too, but that 
would need some __getConst() magic, which is just madness.







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

Req #62860 [Opn->Dup]: Moar magic methods! __constructStatic(), __getStatic(), __setStatic(), __get

[reeze]

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

 ID: 62860
 Updated by: re...@php.net
 Reported by:michaelduff2 at yahoo dot com
 Summary:Moar magic methods! __constructStatic(),
 __getStatic(), __setStatic(), __get
-Status: Open
+Status: Duplicate
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Duplicate to https://bugs.php.net/bug.php?id=45002 closed.


Previous Comments:

[2012-09-05 15:12:01] matthew dot bonner at gmail dot com

Sorry in my last example there was a typo, and what I meant was:
I would like to add that being magic methods, it would be nice if they could do 
a little more magic, ie:

class Classy {
  public static $foo = 'foo';
  public $bar = 'bar';

  public static function __get ($propertyName) {
return self::$propertyName;
  }

  public function __get ($propertyName) {
return $this->$propertyName;
  }
}

echo Classy::$foo; // outputs "foo"
$classy = new Classy;
echo $classy->bar; // outputs "bar"


[2012-09-05 15:10:36] matthew dot bonner at gmail dot com

I would like to add that being magic methods, it would be nice if they could do 
a little more magic, ie:

class Classy {
  public static $foo = 'foo';
  public $bar = 'bar';

  public static function __get ($propertyName) {
return $this->$propertyName;
  }

  public function __get ($propertyName) {
return self::$propertyName;
  }
}

echo Classy::$foo; // outputs "foo"
$classy = new Classy;
echo $classy->bar; // outputs "bar"


[2012-09-05 15:06:06] matthew dot bonner at gmail dot com

The additional magic methods with static support have been requested over and 
over for well over 5 years now. Is PHP a dying language because the developers 
don't have the time to provide essential functionality?

There are so many hacks going about now to try and provide essential 
functionality and there is so much messy code all over the place to support 
what should be part of PHP 5 as standard.

Sorry for my raving and ranting but the reputation of PHP is being severely 
damaged by not providing the essentials.

.NET has static accessor and mutator support, Java does too. All the big 
languages do apart from PHP.

class PLEASE_SUPPORT_AT_A_MINIMUM {
  public static function __construct () {}
  public static function __set ($propertyName, $propertyValue) {}
  public static function __get ($propertyName) {}

  public function setConstDynamically () {
const Foo = 'foo';
echo self::Foo;
  }
}

Otherwise I will fork PHP and provide this essential functionality myself which 
will ultimately result in the death of the original PHP.


[2012-08-18 20:03:22] michaelduff2 at yahoo dot com

Description:

__constructStatic() - executed automatically on class definition

__getStatic() - executed when ClassName::$inaccessible_property is fetched

__setStatic() - executed when ClassName::$inaccessible_property is modified


The particular use case I have for this is self-loading configuration registry 
singletons:



Currently, I accomplish this with __callStatic() which needs the extra 
open-close parenthesis.  Ideally, we could get rid of the '$' too, but that 
would need some __getConst() magic, which is just madness.







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

Bug #61925 [Opn->Fbk]: Crashes on using variable equal to conditional shortcut

[reeze]

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

 ID: 61925
 Updated by: re...@php.net
 Reported by:alex dot erwin at dilithiumtoys dot com
 Summary:Crashes on using variable equal to conditional
 shortcut
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*Programming Data Structures
 Operating System:   Windows 7 32-bit
 PHP Version:5.4.1
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Could you please try lastest version.

I can't reproduce it. http://3v4l.org/to5RB


Previous Comments:

[2012-05-03 16:12:59] alex dot erwin at dilithiumtoys dot com

Description:

I am using Apache 2.4 with PHP 5.4 on Windows 7 32bit. When executing the code 
shown, from within a private class method, the server crashes. PHP is compiled 
as a DSO. If the code is changed to utilize long form conditional processing 
the execution works.

If I use the command line to execute the script, the class loaded by require 
does not get called.

// my index.php
require("C:/Infinity/application/shared/classes/a.php"); 
$x = new a();

// my a.php
class a { __constructor(){ $this->import_variables($_POST); }}

further code in test script.

Test script:
---
# retrieve caller name
$calledby = debug_backtrace(); print_r($calledby);
// does not work
$caller = (strlen($calledby[1]['class'])) ? $calledby[1]['class'] : 
$calledby[0]['class'];
// works and does does not segfault
if (strlen($calledby[1]['class']))  $caller = $calledby[1]['class'];
else$caller = $calledby[0]['class'];

# arguments are required
if (!func_num_args()) { return; }
# fill variables with argument contents if exists
$variables = (func_num_args() == 0) ? NULL : (is_array(func_get_arg(0)) ? 
func_get_arg(0) : NULL);

Expected result:

I expect that Apache will not SEGFAULT







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

Bug #63066 [Asn]: Calling an undefined method in a generator results in a seg fault

[laruence]

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

 ID: 63066
 Updated by: larue...@php.net
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Assigned
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
-Assigned To:nikic
+Assigned To:romakhin
 Block user comment: N
 Private report: N

 New Comment:

yeah, of course, my patch is just a hint :)

assign to dmitry, dmitry, could you please look at this? 

thanks


Previous Comments:

[2012-09-11 16:50:56] ni...@php.net

There are several fatal errors that may trigger this. I added another patch 
that 
fixes (hopefully?) all of them.

Instead of loading the object directly into EX(object) I first put it into a 
temporary variable and only assign it to EX(object) after everything's good.

Does this seem reasonable?


[2012-09-11 16:48:58] ni...@php.net

The following patch has been added/updated:

Patch Name: patch2.diff
Revision:   1347382138
URL:
https://bugs.php.net/patch-display.php?bug=63066&patch=patch2.diff&revision=1347382138


[2012-09-11 16:04:58] Jared dot Williams1 at ntlworld dot com

Yeah, the QF does work.


[2012-09-11 15:29:18] larue...@php.net

a quick fix made, and attached, hope that will help.


[2012-09-11 15:27:58] larue...@php.net

The following patch has been added/updated:

Patch Name: bug63066.patch
Revision:   1347377278
URL:
https://bugs.php.net/patch-display.php?bug=63066&patch=bug63066.patch&revision=1347377278




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


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

Bug #63026 [Fbk]: require_once error

[laruence]

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

 ID: 63026
 Updated by: larue...@php.net
 Reported by:ian dot xspace at yahoo dot cn
 Summary:require_once error
 Status: Feedback
 Type:   Bug
 Package:*Compile Issues
 Operating System:   windows 7
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

那些类名可以正确加载 ,那些类名不可以?  你举个例子?


Previous Comments:

[2012-09-12 01:56:19] ian dot xspace at yahoo dot cn

//init.php 定义网站目录
/***网站目录定义***/
define('THEME', 'default');
//define('TEMP', WEB_ROOT.DS.'temp');
//define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
define('LOGS', VIEWS.DS.'logs');
define('DYN', VIEWS.DS.'dynamic');
define('HLP', WEB_ROOT.DS.'helpers');
//define('PLNS', WEB_ROOT.DS.'plugins');
define('CONFS', WEB_ROOT.DS.'configs');
define('MODELS', WEB_ROOT.DS.'models');
define('CTRLS', WEB_ROOT.DS.'controls');
//SYS.php  
sysModule函数里的对应关系为错误写法，正确写法应该是'M'=>MODELS后者无需单引号
class SYS
{
//sysModule系统目录映射
private function sysModule()
{
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
}
//getSys获取相应配置
public static function getSys($fun)
{
return self::$fun();
}
}
//common.php 其中一个函数，加载所需要的类
class Common
{
//loadCS
protected function loadCS($cs)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //直接定位   
require_once($moArr[$type].DS."{$csName}.php");
//  switch($type)  以上将会获取更快执行速度
//  {
//  case 'M':
//  require_once(MODELS.DS."$csName.php");
//  break;
//  case 'V':
//  require_once(VIEWS.DS."$csName.php");
//  break;
//  case 'C':
//  require_once(CTRLS.DS."$csName.php");
//  break;
//  case 'L':
//  require_once(LIBS.DS."$csName.php");
//  break;
//  case 'P':
//  require_once(PLNS.DS."$csName.php");
//  break;
//  case 'H':
//  require_once(HLP.DS."$csName.php");
//  break;
//  default:
//  JS::willJS('alertMsg', '调用失败!');
//  }
$CS = ucfirst($csName);
return new $CS();
}
}

//index.php 首页调用其它类
//Index
class Index extends IAN_C
{
//__construct
public function __construct()
{
   $obj = $this->loadCS('M.share_model');//调用其它类
   
//你可以多调用几个类，在上面错误写法情况下，有的类可以调用成功，有的失败
   //sysModule 
里的对应关系，应该这么写'C'=>CTRLS,后者无需引号
}

}
new Index

//大哥你要是再看不明白，我也没辙了


[2012-09-12 01:48:03] ian dot xspace at yahoo dot cn

早说啊，我还以为都是外国人呢。
//定义网站跟目录 init.php
define('WEB_ROOT', strtr(dirname(__FILE__), '\\', '/'));
//定义网站的其它目录
define('TEMP', WEB_ROOT.DS.'temp');
define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
//下面是我写的一个类 sys.php
class SYS
{

//这个是每个目录对应的简写，但是这是错误写法，可在后期的程序调用中居然有的
//可以成功有的失败了  $moArr = SYS::getSys('sysModule');
//require_once($moArr[$type].DS."{$csName}.php"); 这样可以直接
//引入所需要的文件，避免使用switch浪费时间
/*
//  switch($type)  以上将会获取更快执行速度
//  {
//  case 'M':
//  require_once(MODELS.DS."$csName.php");
//  break;
//  case 'V':
//  require_once(VIEWS.DS."$csName.php");
//  break;
//  case 'C':
//  require_once(CTRLS.DS."$csName.php");
//  break;
//  case 'L':
/

Bug #63026 [Com]: require_once error

[ian dot xspace at yahoo dot cn]

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

 ID: 63026
 Comment by: ian dot xspace at yahoo dot cn
 Reported by:ian dot xspace at yahoo dot cn
 Summary:require_once error
 Status: Feedback
 Type:   Bug
 Package:*Compile Issues
 Operating System:   windows 7
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

//init.php 定义网站目录
/***网站目录定义***/
define('THEME', 'default');
//define('TEMP', WEB_ROOT.DS.'temp');
//define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
define('LOGS', VIEWS.DS.'logs');
define('DYN', VIEWS.DS.'dynamic');
define('HLP', WEB_ROOT.DS.'helpers');
//define('PLNS', WEB_ROOT.DS.'plugins');
define('CONFS', WEB_ROOT.DS.'configs');
define('MODELS', WEB_ROOT.DS.'models');
define('CTRLS', WEB_ROOT.DS.'controls');
//SYS.php  
sysModule函数里的对应关系为错误写法，正确写法应该是'M'=>MODELS后者无需单引号
class SYS
{
//sysModule系统目录映射
private function sysModule()
{
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
}
//getSys获取相应配置
public static function getSys($fun)
{
return self::$fun();
}
}
//common.php 其中一个函数，加载所需要的类
class Common
{
//loadCS
protected function loadCS($cs)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //直接定位   
require_once($moArr[$type].DS."{$csName}.php");
//  switch($type)  以上将会获取更快执行速度
//  {
//  case 'M':
//  require_once(MODELS.DS."$csName.php");
//  break;
//  case 'V':
//  require_once(VIEWS.DS."$csName.php");
//  break;
//  case 'C':
//  require_once(CTRLS.DS."$csName.php");
//  break;
//  case 'L':
//  require_once(LIBS.DS."$csName.php");
//  break;
//  case 'P':
//  require_once(PLNS.DS."$csName.php");
//  break;
//  case 'H':
//  require_once(HLP.DS."$csName.php");
//  break;
//  default:
//  JS::willJS('alertMsg', '调用失败!');
//  }
$CS = ucfirst($csName);
return new $CS();
}
}

//index.php 首页调用其它类
//Index
class Index extends IAN_C
{
//__construct
public function __construct()
{
   $obj = $this->loadCS('M.share_model');//调用其它类
   
//你可以多调用几个类，在上面错误写法情况下，有的类可以调用成功，有的失败
   //sysModule 
里的对应关系，应该这么写'C'=>CTRLS,后者无需引号
}

}
new Index

//大哥你要是再看不明白，我也没辙了


Previous Comments:

[2012-09-12 01:48:03] ian dot xspace at yahoo dot cn

早说啊，我还以为都是外国人呢。
//定义网站跟目录 init.php
define('WEB_ROOT', strtr(dirname(__FILE__), '\\', '/'));
//定义网站的其它目录
define('TEMP', WEB_ROOT.DS.'temp');
define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
//下面是我写的一个类 sys.php
class SYS
{

//这个是每个目录对应的简写，但是这是错误写法，可在后期的程序调用中居然有的
//可以成功有的失败了  $moArr = SYS::getSys('sysModule');
//require_once($moArr[$type].DS."{$csName}.php"); 这样可以直接
//引入所需要的文件，避免使用switch浪费时间
/*
//  switch($type)  以上将会获取更快执行速度
//  {
//  case 'M':
//  require_once(MODELS.DS."$csName.php");
//  break;
//  case 'V':
//  require_once(VIEWS.DS."$csName.php");
//  break;
//  case 'C':
//  require_once(CTRLS.DS."$csName.php");
//  break;
//  case 'L':
//  require_once(LIBS.DS."$csName.php");
//  break;
//  case 'P':
//  require_once(PLNS.DS."

Bug #63026 [Com]: require_once error

[ian dot xspace at yahoo dot cn]

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

 ID: 63026
 Comment by: ian dot xspace at yahoo dot cn
 Reported by:ian dot xspace at yahoo dot cn
 Summary:require_once error
 Status: Feedback
 Type:   Bug
 Package:*Compile Issues
 Operating System:   windows 7
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

早说啊，我还以为都是外国人呢。
//定义网站跟目录 init.php
define('WEB_ROOT', strtr(dirname(__FILE__), '\\', '/'));
//定义网站的其它目录
define('TEMP', WEB_ROOT.DS.'temp');
define('LIBS', WEB_ROOT.DS.'libs');
define('VIEWS', WEB_ROOT.DS.'views');
//下面是我写的一个类 sys.php
class SYS
{

//这个是每个目录对应的简写，但是这是错误写法，可在后期的程序调用中居然有的
//可以成功有的失败了  $moArr = SYS::getSys('sysModule');
//require_once($moArr[$type].DS."{$csName}.php"); 这样可以直接
//引入所需要的文件，避免使用switch浪费时间
/*
//  switch($type)  以上将会获取更快执行速度
//  {
//  case 'M':
//  require_once(MODELS.DS."$csName.php");
//  break;
//  case 'V':
//  require_once(VIEWS.DS."$csName.php");
//  break;
//  case 'C':
//  require_once(CTRLS.DS."$csName.php");
//  break;
//  case 'L':
//  require_once(LIBS.DS."$csName.php");
//  break;
//  case 'P':
//  require_once(PLNS.DS."$csName.php");
//  break;
//  case 'H':
//  require_once(HLP.DS."$csName.php");
//  break;
//  default:
//  JS::willJS('alertMsg', '调用失败!');
//  }
   */
   //这里是系统目录对应的单词简写，但是这是错误写法
   //正确写法应该是  'M'=>MODELS 
后面无需加单引号（虽然是错误写法但是使用的时候
   //有的可以正常使用有的不能正常使用）
private function sysModule()
{
return array(
'M'=>'MODELS', 'V'=>'VIEWS',
'C'=>'CTRLS', 'L'=>'LIBS',
'P'=>'PLNS', 'H'=>'HLP'
);
}

public static function getSys($fun)
{
return self::$fun();
}
}

//common.php 其它程序共享类
class Common
{
   //类中的一个函数用于调用所需要的其他类
   public function loadSomeClass($type)
   {
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$moArr = SYS::getSys('sysModule'); //find module
require_once($moArr[$type].DS."{$csName}.php");
   }
}

//index.php 比如在index.php页面里调用其他类文件
class Index
{
   public function __construct()
   {
 require_once 'common.php';
 $com = new Common();
 
$com->loadSomeClass('M.db_model');//引入这个类文件或者mvc里的任何一个文件
//问题就出在这里  'M'=>'MODELS', 
这种写法是有错的，但是调用loadSomeClass
//时候居然有的类可以正确加载而有的类不能正确加载
   }
}
new Index();

//要是还看不明名，你告诉我从哪里上传文件啊，或者我的QQ是995668790，以前我在你的博客里和你
聊过ian,就说有bug的


Previous Comments:

[2012-09-10 07:53:37] larue...@php.net

你用中文描述吧, 我实在看不懂你说什么错误 
另外, 请提供一个可以正常运行的可重试脚本. 
(you can re-describe this problem in chinese, previous one is hard to read).

thanks


[2012-09-10 07:44:44] ian dot xspace at yahoo dot cn

private function sysModule()
{
//error writing 错误写法
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);
//right wring 正确写法
return array(
'M'=>MODELS, 'V'=>VIEWS,
'C'=>CTRLS, 'L'=>LIBS,
'P'=>PLNS, 'H'=>HLP
);

}

//common.php load some calss file
//Assume  $type = 'M.className';
function loadSomeClass($type)
{
$csName = substr($cs, 2);
$type = strtoupper(strtok($cs, '.'));
$m

Req #18060 [Com]: request for user defined superglobals

[markus dot behm at gmail dot com]

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

 ID: 18060
 Comment by: markus dot behm at gmail dot com
 Reported by:cstdenis at hotmail dot com
 Summary:request for user defined superglobals
 Status: Closed
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   any
 PHP Version:4.2.1
 Block user comment: N
 Private report: N

 New Comment:

And yes I do know that I could fix that with one line of code (global $Contact, 
$Event, $Account) but updating that line every time you need a model is a real 
pita.

Also typing M::$Account is quite a bit harder than Account or $Account ;)


Previous Comments:

[2012-09-12 00:59:31] markus dot behm at gmail dot com

There are so many ways to shoot yourself in the foot in php if used wrongly 
that  
I feel the response given here is a bit moot point. Take ruby for example, yes 
you can totally fuck it up if you do stupid things but is it prone to the 
problems? No.

I've created a very powerful database abstraction based on models and since you 
can't define constant instances of classes (eg. Account), being able to create 
superglobals (eg. $Account) would be the next closest thing but no.

Because of these instead of this

$events = Contacts->join('accounts', 'events')->where(
  Event['start_date']->gteq($start_date),
  Event['end_date']->lteq($end_date),
  Event['type']->eq($type),
  Contact['owner_id']->eq($current_user->id)
)->project('firstname', 'lastname', Account['accountname'], Event['subject']);

You have to do something like this (closest I have come so far)

$events = M::$Contacts->join('accounts', 'events')->where(
  M::$Event['start_date']->gteq($start_date),
  M::$Event['end_date']->lteq($end_date),
  M::$Event['type']->eq($type),
  M::$Contact['owner_id']->eq($current_user->id)
)->project('firstname', 'lastname', M::$Account['accountname'], 
$::$Event['subject']);

Not that much worse but it compunds over time.

Maybe the only reason why such feature doesn't exist is because somebody fucked 
up with certain other language magic in the first place.


[2002-06-29 10:08:25] ras...@php.net

Won't happen.  You can already set variables that are accessible everywhere by 
specifying you want to access a global variable via "global $user" or 
$GLOBALS['user'].  The whole point is to prevent nasty global variable 
side-effects that other languages are prone to.


[2002-06-29 06:32:52] cstdenis at hotmail dot com

I am requesting a feature of user defined 'superglobal' varables. This would be 
handy for a varable that is set in the header containing somthing like username 
or access level that is used throughout a script.





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

Req #18060 [Com]: request for user defined superglobals

[markus dot behm at gmail dot com]

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

 ID: 18060
 Comment by: markus dot behm at gmail dot com
 Reported by:cstdenis at hotmail dot com
 Summary:request for user defined superglobals
 Status: Closed
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   any
 PHP Version:4.2.1
 Block user comment: N
 Private report: N

 New Comment:

There are so many ways to shoot yourself in the foot in php if used wrongly 
that  
I feel the response given here is a bit moot point. Take ruby for example, yes 
you can totally fuck it up if you do stupid things but is it prone to the 
problems? No.

I've created a very powerful database abstraction based on models and since you 
can't define constant instances of classes (eg. Account), being able to create 
superglobals (eg. $Account) would be the next closest thing but no.

Because of these instead of this

$events = Contacts->join('accounts', 'events')->where(
  Event['start_date']->gteq($start_date),
  Event['end_date']->lteq($end_date),
  Event['type']->eq($type),
  Contact['owner_id']->eq($current_user->id)
)->project('firstname', 'lastname', Account['accountname'], Event['subject']);

You have to do something like this (closest I have come so far)

$events = M::$Contacts->join('accounts', 'events')->where(
  M::$Event['start_date']->gteq($start_date),
  M::$Event['end_date']->lteq($end_date),
  M::$Event['type']->eq($type),
  M::$Contact['owner_id']->eq($current_user->id)
)->project('firstname', 'lastname', M::$Account['accountname'], 
$::$Event['subject']);

Not that much worse but it compunds over time.

Maybe the only reason why such feature doesn't exist is because somebody fucked 
up with certain other language magic in the first place.


Previous Comments:

[2002-06-29 10:08:25] ras...@php.net

Won't happen.  You can already set variables that are accessible everywhere by 
specifying you want to access a global variable via "global $user" or 
$GLOBALS['user'].  The whole point is to prevent nasty global variable 
side-effects that other languages are prone to.


[2002-06-29 06:32:52] cstdenis at hotmail dot com

I am requesting a feature of user defined 'superglobal' varables. This would be 
handy for a varable that is set in the header containing somthing like username 
or access level that is used throughout a script.





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

Bug #61045 [Com]: fpm don't send error log to fastcgi clients(nginx)

[ryan dot pendergast at gmail dot com]

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

 ID: 61045
 Comment by: ryan dot pendergast at gmail dot com
 Reported by:lxlight at gmail dot com
 Summary:fpm don't send error log to fastcgi clients(nginx)
 Status: Closed
 Type:   Bug
 Package:FPM related
 Operating System:   Linux
 PHP Version:5.3.10
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

Is there a work around for us that are stuck on 5.3.10?


Previous Comments:

[2012-06-15 06:00:41] f...@php.net

yes this fix will go live in the next 5.3 and 5.4 release.


[2012-06-15 05:25:40] hb at peytz dot dk

Any news about when this will see a release? Maybe 5.3.15 ? 5.4.5?


[2012-05-22 17:46:33] arohter at gmail dot com

Does this mean the fix will go live in the official 5.3.14 release?


[2012-05-22 16:54:43] a...@php.net

Automatic comment on behalf of fat
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=faca4e08b4dffbf00b1bc20fc5d4e310b3f99c13
Log: - Fixed bug #61045 (fpm don't send error log to fastcgi clients)


[2012-05-22 07:05:31] f...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.






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


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

Req #53573 [Opn->Wfx]: Invisible "static" property of Closure

[nikic]

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

 ID: 53573
 Updated by: ni...@php.net
 Reported by:kak dot serpom dot po dot yaitsam at gmail dot com
 Summary:Invisible "static" property of Closure
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.4
 Block user comment: N
 Private report: N

 New Comment:

As reeze pointed out this is only debugging output (var_dump is a debugging 
function). The property does not actually exist. We provide the same kind of 
functionality for various other classes. You could think of this as a "private" 
property, which is used internally, but which the user does not have access too 
(encapsulation).

I see no reason to expose this. If you need this for $this bindings, then 
switch to PHP 5.4. It will automatically bind $this and allows rebinding using 
the ->bind() method.

Closing this as won't fix. (If you have any convincing counter arguments, 
please share them and this will be reopened.)


Previous Comments:

[2012-09-11 18:16:41] re...@php.net

In fact, closure is a class: Closure just an implementation detail.

we should forget about the class itself. the output static is just 
let you to ease debugging but not for public access


[2011-02-16 02:04:21] olamedia at gmail dot com

Please, let Closure be standard object without any restrictions.
Let developers decide what they can use, and what must not.
PHP is already full enough of "RESERVED" "YOU MUST NOT" "YOU CAN NOT" "YOU 
SHOULD 
NOT" "ITS HARD, SO WE WILL NOT MAKE THIS FEATURE" "I DONT NEED THIS, SO PLEASE 
DON'T REQUEST THIS FEATURE"


[2011-02-16 01:51:07] olamedia at gmail dot com

c[$name]; // example
$self = $this;
// how can I pass $self to closure?
$closure->static['self'] = $this // NO!, Reflection is giving empty array
call_user_func_array($closure, $args);
  }
}
$a = new a();
$a->c['hello'] = function($x) use ($self){
  return 'Hello, '.$x.'! My name is '.get_class($self).'!';
};
$a->hello('php');


[2010-12-19 06:03:08] kak dot serpom dot po dot yaitsam at gmail dot com

Description:

var_dump($closure) displays public property named "static", but I cannot access 
to 
it with standard call: Closure object cannot have properties
It might be very useful!
Thanks.

Test script:
---
{'static'}['foo'] = 'foo';
$a();


Expected result:

Output: foo

Actual result:
--
object(Closure)#1 (1) {
  ["static"]=>
  array(1) {
["foo"]=>
string(3) "bar"
  }
}
PHP Catchable fatal error:  Closure object cannot have properties in 
/home/web/1.php on line 7







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

Bug #47640 [Nab->Fbk]: Session does not close file in /tmp/

[kriscraig]

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

 ID: 47640
 Updated by: kriscr...@php.net
 Reported by:manuel dot schmitt at manitu dot de
 Summary:Session does not close file in /tmp/
-Status: Not a bug
+Status: Feedback
 Type:   Bug
 Package:Session related
 Operating System:   Linux
 PHP Version:5.2.9
 Block user comment: N
 Private report: N



Previous Comments:

[2012-09-11 20:39:24] kriscr...@php.net

Could somebody explain why the status was changed to "Not a bug?"  I'm not 
seeing 
anything in the comments to indicate why that edit was made.  Looks like a real 
bug to me and everything else seems to check-out, so I'm assuming that was an 
error given the lack of an explanation.

I'm re-opening this with "Feedback" status.  If you're the one who closed this 
(the edit history is empty), please post a comment explaining your reasoning.  
Thanks!


[2012-05-27 01:04:29] bugs dot php dot net at jrs-s dot net

I worked around this problem by simply moving sessions from file storage to 
memcache.

session.save_handler = memcache
session.save_path = "tcp://serv01:11211,tcp://serv02:11211,tcp://serv03:11211"

An application pool that had been creeping up to MaxCli (900 children apiece, 
in 
this case) within a couple hours of a restart due to this FLOCK issue settled 
down and has now been running happily for several days on fewer than 150 
children per server.  I highly recommend just NOT USING php's file based 
session 
storage in the first place, because of exactly this issue.


[2012-02-01 19:50:15] pio at rdl dot pl

Hello !

Is there any news with this issue ?

Piotr


[2010-10-24 12:29:55] alex dot linte at gmail dot com

Hello,

I have the same mistake :

host:~# date
dimanche 24 octobre 2010, 12:10:03 (UTC+0200)
host:~# ps faux | grep php
juritrav 17749  0.0  0.0 118988 11616 ?S00:11   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 17818  0.0  0.0 117764  9536 ?S00:12   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 18004  0.0  0.0 117764  9536 ?S00:14   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12573  0.0  0.1 138812 31784 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12574  0.0  0.0 117492  9396 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
duphpuser 12594  0.0  0.0 117492  9396 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12675  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12682  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12695  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi

So php-cgi scripts run for ever until I kill its manually.

I take the sample of process 18004 : 


front2:~# strace -p18004
Process 18004 attached - interrupt to quit
flock(3, LOCK_EX


host# lsof -p18004

php-cgi 18004 suphpuser3uW  REG9,1   7   897723 
/tmp/php5/sess_ (deleted)


So the php script tries to lock a session file (file descriptor 3) that has 
been deleted by the PHP garbage collector.

When the garbage collector delete a session file, it doesn't take care that any 
php process still using this session file.
Then the php process can't lock the file because it doesn't exist anymore, the 
php-cgi process is blocked

I have the problem with the following version of php :

PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug  4 2010 
06:06:53)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies

The cron job for php (script that delete session on debian) is disabled et the 
garbage collector php is enabled in php.ini file :

session.gc_probability = 1
session.gc_divisor = 100


Sorry for my english.

Alexandre LINTE


[2009-05-03 12:07:47] manuel dot schmitt at manitu dot de

ACK, but as server administrator there *must* be a way to prevent this.

Admins do not have influence on the scripts that are used by webmasters.

So I think it's a PHP thing. Likely one should automatically close all sessions 
that were opened by scripts aborting / running into limits sets by php (e.g. 
exec time) etc. This should solve it.




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

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


-- 
Edit this bug report a

Bug #47640 [Com]: Session does not close file in /tmp/

[kriscr...@php.net]

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

 ID: 47640
 Comment by: kriscr...@php.net
 Reported by:manuel dot schmitt at manitu dot de
 Summary:Session does not close file in /tmp/
 Status: Not a bug
 Type:   Bug
 Package:Session related
 Operating System:   Linux
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

Could somebody explain why the status was changed to "Not a bug?"  I'm not 
seeing 
anything in the comments to indicate why that edit was made.  Looks like a real 
bug to me and everything else seems to check-out, so I'm assuming that was an 
error given the lack of an explanation.

I'm re-opening this with "Feedback" status.  If you're the one who closed this 
(the edit history is empty), please post a comment explaining your reasoning.  
Thanks!


Previous Comments:

[2012-05-27 01:04:29] bugs dot php dot net at jrs-s dot net

I worked around this problem by simply moving sessions from file storage to 
memcache.

session.save_handler = memcache
session.save_path = "tcp://serv01:11211,tcp://serv02:11211,tcp://serv03:11211"

An application pool that had been creeping up to MaxCli (900 children apiece, 
in 
this case) within a couple hours of a restart due to this FLOCK issue settled 
down and has now been running happily for several days on fewer than 150 
children per server.  I highly recommend just NOT USING php's file based 
session 
storage in the first place, because of exactly this issue.


[2012-02-01 19:50:15] pio at rdl dot pl

Hello !

Is there any news with this issue ?

Piotr


[2010-10-24 12:29:55] alex dot linte at gmail dot com

Hello,

I have the same mistake :

host:~# date
dimanche 24 octobre 2010, 12:10:03 (UTC+0200)
host:~# ps faux | grep php
juritrav 17749  0.0  0.0 118988 11616 ?S00:11   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 17818  0.0  0.0 117764  9536 ?S00:12   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 18004  0.0  0.0 117764  9536 ?S00:14   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12573  0.0  0.1 138812 31784 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12574  0.0  0.0 117492  9396 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
duphpuser 12594  0.0  0.0 117492  9396 ?S09:39   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12675  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12682  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi
suphpuser 12695  0.0  0.0 117764  9536 ?S09:40   0:00  |   \_ 
/usr/bin/php-cgi

So php-cgi scripts run for ever until I kill its manually.

I take the sample of process 18004 : 


front2:~# strace -p18004
Process 18004 attached - interrupt to quit
flock(3, LOCK_EX


host# lsof -p18004

php-cgi 18004 suphpuser3uW  REG9,1   7   897723 
/tmp/php5/sess_ (deleted)


So the php script tries to lock a session file (file descriptor 3) that has 
been deleted by the PHP garbage collector.

When the garbage collector delete a session file, it doesn't take care that any 
php process still using this session file.
Then the php process can't lock the file because it doesn't exist anymore, the 
php-cgi process is blocked

I have the problem with the following version of php :

PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug  4 2010 
06:06:53)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies

The cron job for php (script that delete session on debian) is disabled et the 
garbage collector php is enabled in php.ini file :

session.gc_probability = 1
session.gc_divisor = 100


Sorry for my english.

Alexandre LINTE


[2009-05-03 12:07:47] manuel dot schmitt at manitu dot de

ACK, but as server administrator there *must* be a way to prevent this.

Admins do not have influence on the scripts that are used by webmasters.

So I think it's a PHP thing. Likely one should automatically close all sessions 
that were opened by scripts aborting / running into limits sets by php (e.g. 
exec time) etc. This should solve it.


[2009-05-02 18:42:02] j...@php.net

Endless loops tend to cause such problems. One should always use 
http://www.php.net/session_write_close as early as possible to prevent 
race conditions and this kind of "bugs".




The remainder of the comments for this repo

Bug #61955 [Com]: Adding DateInterval to DateTime adds 1 additional hour

[chris dot baker dot gr at gmail dot com]

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

 ID: 61955
 Comment by: chris dot baker dot gr at gmail dot com
 Reported by:php at arjanonline dot net
 Summary:Adding DateInterval to DateTime adds 1 additional
 hour
 Status: Assigned
 Type:   Bug
 Package:Date/time related
 Operating System:   Linux / Mac
 PHP Version:5.3.12
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

To amend my earlier comment: my repro attempts show that if I create an 
instance of DateTime by passing a string to the constructor, everything works 
fine. If I use a timestamp in combination with DateTime::createFromFormat, I 
see the bug affect the results

Use of a string
-   
$start = new DateTime('09/13/2012 7:00pm');
$end = new DateTime('09/13/2012 8:00pm');
$interval = DateInterval::createFromDateString('30 minutes');

// expected, 1 hours, 0 minutes, get 1 hours, 0 minutes
$diff = $start->diff($end);
print 'Diff: '.$diff->h.' hours, '.$diff->i.' minutes'."\n";

$end->add($interval);
$diff = $start->diff($end);
// ecpected: 1 hours, 30 minutes, get 1 hours, 30 minutes
print "\n".'Diff after interval: '.$diff->h.' hours, '.$diff->i.' minutes';


Use of a timestamp
-

$start = DateTime::createFromFormat('U', 1347577200);
$end =  DateTime::createFromFormat('U', 1347580800);
$interval = DateInterval::createFromDateString('30 minutes');

// expected, 1 hours, 0 minutes, get 1 hours, 0 minutes
$diff = $start->diff($end);
print 'Diff: '.$diff->h.' hours, '.$diff->i.' minutes'."\n";

$end->add($interval);
$diff = $start->diff($end);
// ecpected: 1 hours, 30 minutes, get 2 hours, 30 minutes
print "\n".'Diff after interval: '.$diff->h.' hours, '.$diff->i.' minutes';

http://3v4l.org/fivbW

The extra one hour makes less sense considering that my server timezone is -5 
UTC -- not that it makes sense for DateInterval to be sensitive to timezone!


Previous Comments:

[2012-09-11 14:58:51] chris dot baker dot gr at gmail dot com

Can reproduce this as well, just determined it to be the cause of new errors in 
a scheduling web app after updating to 5.4.


[2012-07-09 19:47:08] jgardynik at endlessrealities dot com

I'm getting the same thing. Any single date_modify() call is causing an extra 
hour to be added. If I add 1 minute, it still adds an extra hour. The commit 
that was bisected is very clearly adding an extra hour. If I use 
Pacific/Honolulu or UTC in date_default_timezone_set() it works fine. 
Apparently the fix was not specific enough in its implementation and it's 
taking effect all the time.

This is causing every single one of my monthly comparison reports to break in a 
rather large system because the time is getting thrown off.

I'm using PHP 5.4.4 on linux.


[2012-05-19 15:03:40] graham at grahamc dot com

One minor clarification - This is occurring in every version above 5.3.8.

After running git bisect, I've narrowed it down to this particular commit: 
https://github.com/php/php-src/commit/7411ae09f5565b3f0dfbbfeb71c8f848fd38d6ca


[2012-05-11 15:51:21] zhanglijiu at gmail dot com

My result is object(DateTime)#2 (3) { ["date"]=> string(19) "1970-01-01 
00:00:05" 
["timezone_type"]=> int(1) ["timezone"]=> string(6) "+00:00" }

My system is MAC 10.6.8 php 5.3.1


[2012-05-05 20:45:27] php at arjanonline dot net

Description:

When I create a DateTime object from a (any) timestamp and then add a 
DateInterval object to the DateTime object, the time in the DateInterval object 
is added and one additional hour is also added.

I have not noticed this behavior in versions up to and including 5.3.8, only in 
newer 5.3 versions. (I did not test in 5.4.)
Also the behavior is related to the default time zone, even though the created 
DateTime object is in UTC. I have tested several timezones and it appears that 
all Europe/* and North American America/* timezones are affected. The 
Australian timezones seem to be unaffected.

Information from phpinfo():
date
- date/time support => enabled
- "Olson" Timezone Database Version => 2012.3
- Timezone Database => internal


Test script:
---
date_default_timezone_set('Europe/Amsterdam');
$d1 = new DateTime('@0');
$d2 = clone($d1);
$d2->add(new DateInterval('PT5S'));
var_dump($d2);


Expected result:

object(DateTime)[2]
  public 'date' => string '1970-01-01 00:00:05' (length=19)
  public 'timezone_type' => int 1
  public 'timezone' => string '+00:00' (length=6)

Actual result:
---

Req #53573 [Com]: Invisible "static" property of Closure

[re...@php.net]

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

 ID: 53573
 Comment by: re...@php.net
 Reported by:kak dot serpom dot po dot yaitsam at gmail dot com
 Summary:Invisible "static" property of Closure
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.4
 Block user comment: N
 Private report: N

 New Comment:

In fact, closure is a class: Closure just an implementation detail.

we should forget about the class itself. the output static is just 
let you to ease debugging but not for public access


Previous Comments:

[2011-02-16 02:04:21] olamedia at gmail dot com

Please, let Closure be standard object without any restrictions.
Let developers decide what they can use, and what must not.
PHP is already full enough of "RESERVED" "YOU MUST NOT" "YOU CAN NOT" "YOU 
SHOULD 
NOT" "ITS HARD, SO WE WILL NOT MAKE THIS FEATURE" "I DONT NEED THIS, SO PLEASE 
DON'T REQUEST THIS FEATURE"


[2011-02-16 01:51:07] olamedia at gmail dot com

c[$name]; // example
$self = $this;
// how can I pass $self to closure?
$closure->static['self'] = $this // NO!, Reflection is giving empty array
call_user_func_array($closure, $args);
  }
}
$a = new a();
$a->c['hello'] = function($x) use ($self){
  return 'Hello, '.$x.'! My name is '.get_class($self).'!';
};
$a->hello('php');


[2010-12-19 06:03:08] kak dot serpom dot po dot yaitsam at gmail dot com

Description:

var_dump($closure) displays public property named "static", but I cannot access 
to 
it with standard call: Closure object cannot have properties
It might be very useful!
Thanks.

Test script:
---
{'static'}['foo'] = 'foo';
$a();


Expected result:

Output: foo

Actual result:
--
object(Closure)#1 (1) {
  ["static"]=>
  array(1) {
["foo"]=>
string(3) "bar"
  }
}
PHP Catchable fatal error:  Closure object cannot have properties in 
/home/web/1.php on line 7







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

Req #40457 [Com]: ReflectionProperty lacks method getStartLine() / getEndLine()

[re...@php.net]

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

 ID: 40457
 Comment by: re...@php.net
 Reported by:ralph at smashlabs dot com
 Summary:ReflectionProperty lacks method getStartLine() /
 getEndLine()
 Status: Open
 Type:   Feature/Change Request
 Package:Reflection related
 Operating System:   Linux 2.6
 PHP Version:5.2.1
 Block user comment: N
 Private report: N

 New Comment:

I like the idea, but those information didn't exists in runtime as 
class/functions
just for this request to implement this seems a waste.


Previous Comments:

[2010-07-27 22:09:52] rasmus at mindplay dot dk

Yes, this is missing for me too. Badly.

Trying to work around this by manually scanning the source code for the 
property definition would be a huuuge PITA... :-(


[2007-02-13 04:40:08] ralph at smashlabs dot com

Description:

Simply put, when getting a property (in the same manner as a method) from a 
class, ReflectionProperty lacks the ability (as does the ReflectionClass) to 
retrieve a line number from where the property was defined.

  - Properties [1] {
Property [  protected $_Id ]
  }

  - Methods [3] {
Method [  public method get ] {
  @@ 
/home/webdeveloper/vhosts/zdiis2.dev/development/modeling/models/ZDISubmission.php
 11 - 14

  - Parameters [1] {
Parameter #0 [  $identifiers = Array ]
  }
}







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

Bug #63066 [Com]: Calling an undefined method in a generator results in a seg fault

[ni...@php.net]

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

 ID: 63066
 Comment by: ni...@php.net
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Assigned
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
 Assigned To:nikic
 Block user comment: N
 Private report: N

 New Comment:

There are several fatal errors that may trigger this. I added another patch 
that 
fixes (hopefully?) all of them.

Instead of loading the object directly into EX(object) I first put it into a 
temporary variable and only assign it to EX(object) after everything's good.

Does this seem reasonable?


Previous Comments:

[2012-09-11 16:48:58] ni...@php.net

The following patch has been added/updated:

Patch Name: patch2.diff
Revision:   1347382138
URL:
https://bugs.php.net/patch-display.php?bug=63066&patch=patch2.diff&revision=1347382138


[2012-09-11 16:04:58] Jared dot Williams1 at ntlworld dot com

Yeah, the QF does work.


[2012-09-11 15:29:18] larue...@php.net

a quick fix made, and attached, hope that will help.


[2012-09-11 15:27:58] larue...@php.net

The following patch has been added/updated:

Patch Name: bug63066.patch
Revision:   1347377278
URL:
https://bugs.php.net/patch-display.php?bug=63066&patch=bug63066.patch&revision=1347377278


[2012-09-11 15:12:54] larue...@php.net

nikic, while method is not exists, then the EX(object)'s refcount will not be 
increased..

then this object will be dtor in genertor_close, and then the arguments of 
previous exeucte_data clean up.. 

nikic, please look at this.  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=63066


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

Bug #52909 [Com]: ReflectionMethod::getParameters() return incorrect number of arguments

[re...@php.net]

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

 ID: 52909
 Comment by: re...@php.net
 Reported by:frederic dot hardy at mageekbox dot net
 Summary:ReflectionMethod::getParameters() return incorrect
 number of arguments
 Status: Assigned
 Type:   Bug
 Package:PHAR related
 Operating System:   FreeBSD 8.0
 PHP Version:5.3.3
 Assigned To:aharvey
 Block user comment: N
 Private report: N

 New Comment:

Hi aharvey
   reopen and what to do next :)


Previous Comments:

[2010-09-23 17:37:05] ahar...@php.net

Reopening per IRC discussion.


[2010-09-23 06:52:42] ahar...@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-09-23 06:52:32] ahar...@php.net

Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=303712
Log: Fix doc bug #52909 by documenting the extra parameters available in
PharData::__construct().


[2010-09-23 06:41:17] ahar...@php.net

Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=303709
Log: Fix up the vim folds in phar_object.c and add a note that the two 
prototypes
before Phar::__construct() are actually valid and not a mistake, per bug
#52909.


[2010-09-23 06:39:18] ahar...@php.net

The reason for this is that Phar and PharData actually use the same function 
for their __construct implementations -- internally it calls 
instanceof_function() to figure out whether it's constructing a Phar or 
PharData object and then has some if statements to handle things from there. 
There's no distinct arginfo for the PharData implementation, so reflection has 
no way of distinguishing the three parameter Phar constructor from the four 
parameter PharData constructor.

I'll make the proto comment in phar_object.c a little clearer (and remove the 
extra vim fold that doesn't do anything useful). Beyond that, the manual's 
correct for Phar::__construct() but not for PharData::__construct() (which is 
currently documented as accepted two parameters when it actually accepts four), 
so I'll fix that up.

I don't see any way of getting reflection to do the right thing short of 
refactoring the function into two -- which might be the right thing to do 
anyway, but is a decision for Greg or Marcus to make.




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


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

Bug #63066 [PATCH]: Calling an undefined method in a generator results in a seg fault

[ni...@php.net]

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

 ID: 63066
 Patch added by: ni...@php.net
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Assigned
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
 Assigned To:nikic
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: patch2.diff
Revision:   1347382138
URL:
https://bugs.php.net/patch-display.php?bug=63066&patch=patch2.diff&revision=1347382138


Previous Comments:

[2012-09-11 16:04:58] Jared dot Williams1 at ntlworld dot com

Yeah, the QF does work.


[2012-09-11 15:29:18] larue...@php.net

a quick fix made, and attached, hope that will help.


[2012-09-11 15:27:58] larue...@php.net

The following patch has been added/updated:

Patch Name: bug63066.patch
Revision:   1347377278
URL:
https://bugs.php.net/patch-display.php?bug=63066&patch=bug63066.patch&revision=1347377278


[2012-09-11 15:12:54] larue...@php.net

nikic, while method is not exists, then the EX(object)'s refcount will not be 
increased..

then this object will be dtor in genertor_close, and then the arguments of 
previous exeucte_data clean up.. 

nikic, please look at this.  thanks


[2012-09-11 13:50:49] Jared dot Williams1 at ntlworld dot com

Backtrace of the NON debug seg fault...

jared@ubuntu:~$ gdb ./Development/php-src/sapi/cli/php 
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/jared/Development/php-src/sapi/cli/php...done.
(gdb) run fatalSegFault.php 
Starting program: /home/jared/Development/php-src/sapi/cli/php fatalSegFault.php
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Program received signal SIGSEGV, Segmentation fault.
0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0  0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
#1  0x006f6246 in zend_generator_close 
(generator=generator@entry=0x77fce180, 
finished_execution=finished_execution@entry=0 '\000')
at /home/jared/Development/php-src/Zend/zend_generators.c:148
#2  0x006f63cb in zend_generator_free_storage (generator=0x77fce180)
at /home/jared/Development/php-src/Zend/zend_generators.c:181
#3  0x006fc0a8 in zend_objects_store_free_object_storage (
objects=0xdbae60 )
at /home/jared/Development/php-src/Zend/zend_objects_API.c:92
#4  0x006c7153 in shutdown_executor ()
at /home/jared/Development/php-src/Zend/zend_execute_API.c:298
#5  0x006d5646 in zend_deactivate () at 
/home/jared/Development/php-src/Zend/zend.c:938
#6  0x0067641d in php_request_shutdown (dummy=dummy@entry=0x0)
at /home/jared/Development/php-src/main/main.c:1780
#7  0x00781fe0 in do_cli (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1171
#8  0x0042d56b in main (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1364




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


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

Bug #48795 [Com]: Building intl 64-bit fails on OS X

[re...@php.net]

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

 ID: 48795
 Comment by: re...@php.net
 Reported by:gwy...@php.net
 Summary:Building intl 64-bit fails on OS X
 Status: Verified
 Type:   Bug
 Package:Compile Failure
 Operating System:   OS X 10.5 & 10.6; Linux
 PHP Version:5.3 SVN; 5.4.0RC1
 Block user comment: N
 Private report: N

 New Comment:

Same for me, I can't compile either. hope there is a solution


Previous Comments:

[2012-05-08 13:11:12] k...@php.net

Also happens again with PHP 5.3.12 on Ubuntu 12.04 -- stas fix confirmed. A 
generic solution would be nice, indeed.


[2012-03-13 15:46:33] dan at cdchase dot com

It would be helpful if the build system imported any already set CFLAGS. As 
I've experienced this issue before, so I've set the appropriate CFLAGS in my 
default environment. But, the automated install routine does not honor these. I 
have to manually install for them to be honored.


[2011-11-14 16:54:00] weierophin...@php.net

I can confirm Stas's suggestion (s/CC/CXX/ in BUILD_* vars) works with 5.4.0RC1 
on linux 64-bit.


[2011-11-11 11:30:21] ahar...@php.net

tl;dr: Debian Testing and Ubuntu 11.10 have the same problem with
./configure --enable-intl --with-curl.


Effectively the same issue (required C++ linkage not occurring) is now
happening on Ubuntu 11.10 (x86-64) and Debian Testing (armv7l) with
PHP 5.3 SVN and PHP 5.4.0RC1 when compiling with both intl and curl
enabled (note that a compile with just --enable-intl succeeds). It's
notable that both these distributions feature the new Debian
"multiarch" support. Both libcurl and libicu are the normal packaged
versions.

With ./configure --enable-intl --with-curl, the result of
the compile (on the Ubuntu box, although the Debian errors are
effectively the same, just with different architecture-specific paths)
is this:

/usr/bin/ld: ext/intl/msgformat/msgformat_helpers.o: undefined reference to 
symbol '__gxx_personality_v0@@CXXABI_1.3'
/usr/bin/ld: note: '__gxx_personality_v0@@CXXABI_1.3' is defined in DSO 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command 
line
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid 
operation
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1

Diffing the Makefile produced by --enable-intl alone with the
"--enable-intl --with-curl" combination produces the following
(excluding rules directly related to compiling objects within
ext/curl):

@@ -75,9 +76,9 @@
 CXXFLAGS_CLEAN = -g -O2
 DEBUG_CFLAGS =
 EXTENSION_DIR = /usr/local/lib/php/extensions/no-debug-non-zts-20100525
-EXTRA_LDFLAGS =
-EXTRA_LDFLAGS_PROGRAM =
-EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lrt -lm -ldl -lnsl -lxml2 -lxml2 
-ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 -lcrypt -lxml2 
-lxml2 -lxml2 -lcrypt
+EXTRA_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LDFLAGS_PROGRAM = -L/usr/lib/x86_64-linux-gnu
+EXTRA_LIBS = -lcrypt -lresolv -lcrypt -lrt -lcurl -lrt -lm -ldl -lnsl -lxml2 
-lcurl -lxml2 -ldl -lm -licui18n -licuuc -licudata -ldl -lm -licuio -lxml2 
-lcrypt -lxml2 -lxml2 -lxml2 -lcrypt
 ZEND_EXTRA_LIBS =
 INCLUDES = -I/tmp/php-5.4.0RC1/ext/date/lib -I/tmp/php-5.4.0RC1/ext/ereg/regex 
-I/usr/include/libxml2 -I/tmp/php-5.4.0RC1/ext/sqlite3/libsqlite 
-I$(top_builddir)/TSRM -I$(top_builddir)/Zend
 EXTRA_INCLUDES =
@@ -86,13 +87,13 @@
 LFLAGS =
 LIBTOOL = $(SHELL) $(top_builddir)/libtool --silent --preserve-dup-deps
 LN_S = ln -s
-NATIVE_RPATHS =
+NATIVE_RPATHS = -Wl,-rpath,/usr/lib/x86_64-linux-gnu
 PEAR_INSTALLDIR = ${exec_prefix}/lib/php
 PHP_BUILD_DATE = 2011-11-11
-PHP_LDFLAGS =
+PHP_LDFLAGS = -L/usr/lib/x86_64-linux-gnu
 PHP_LIBS =
 OVERALL_TARGET =
-PHP_RPATHS =
+PHP_RPATHS = -R /usr/lib/x86_64-linux-gnu
 PHP_SAPI = none
 PHP_VERSION = 5.4.0RC1
 PHP_VERSION_ID = 50400

Stas's suggestion of replacing the $(BUILD_CGI) and $(BUILD_CLI)
instances of $(CC) in the generated Makefile with $(CXX) fixes the
build.

I'm not familiar enough with our build system to know how to fix this,
but we should probably do something if we can for 5.4.0 final: intl
and curl doesn't seem like it would be an unusual combination. Can we
hack the build system to use the C++ compiler preferentially if
ext/intl and ext/curl are enabled, if it can't be fixed "properly"
(whatever form that takes -- it may even up being an upstream issue)?


[2011-11-06 19:11:09] luke at cywh dot com

Is there going to be a proper fix for this any time soon? I'm having a lot of 
trouble getting 5.3.8 to compile on OS X 10.6.8.

-

Bug #63066 [Asn]: Calling an undefined method in a generator results in a seg fault

[Jared dot Williams1 at ntlworld dot com]

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

 ID: 63066
 User updated by:Jared dot Williams1 at ntlworld dot com
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Assigned
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
 Assigned To:nikic
 Block user comment: N
 Private report: N

 New Comment:

Yeah, the QF does work.


Previous Comments:

[2012-09-11 15:29:18] larue...@php.net

a quick fix made, and attached, hope that will help.


[2012-09-11 15:27:58] larue...@php.net

The following patch has been added/updated:

Patch Name: bug63066.patch
Revision:   1347377278
URL:
https://bugs.php.net/patch-display.php?bug=63066&patch=bug63066.patch&revision=1347377278


[2012-09-11 15:12:54] larue...@php.net

nikic, while method is not exists, then the EX(object)'s refcount will not be 
increased..

then this object will be dtor in genertor_close, and then the arguments of 
previous exeucte_data clean up.. 

nikic, please look at this.  thanks


[2012-09-11 13:50:49] Jared dot Williams1 at ntlworld dot com

Backtrace of the NON debug seg fault...

jared@ubuntu:~$ gdb ./Development/php-src/sapi/cli/php 
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/jared/Development/php-src/sapi/cli/php...done.
(gdb) run fatalSegFault.php 
Starting program: /home/jared/Development/php-src/sapi/cli/php fatalSegFault.php
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Program received signal SIGSEGV, Segmentation fault.
0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0  0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
#1  0x006f6246 in zend_generator_close 
(generator=generator@entry=0x77fce180, 
finished_execution=finished_execution@entry=0 '\000')
at /home/jared/Development/php-src/Zend/zend_generators.c:148
#2  0x006f63cb in zend_generator_free_storage (generator=0x77fce180)
at /home/jared/Development/php-src/Zend/zend_generators.c:181
#3  0x006fc0a8 in zend_objects_store_free_object_storage (
objects=0xdbae60 )
at /home/jared/Development/php-src/Zend/zend_objects_API.c:92
#4  0x006c7153 in shutdown_executor ()
at /home/jared/Development/php-src/Zend/zend_execute_API.c:298
#5  0x006d5646 in zend_deactivate () at 
/home/jared/Development/php-src/Zend/zend.c:938
#6  0x0067641d in php_request_shutdown (dummy=dummy@entry=0x0)
at /home/jared/Development/php-src/main/main.c:1780
#7  0x00781fe0 in do_cli (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1171
#8  0x0042d56b in main (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1364


[2012-09-11 13:46:20] Jared dot Williams1 at ntlworld dot com

It appears that the seg fault doesn't appear in debug builds. 

Recompiled without debug again, and the seg fault is still present


jared@ubuntu:~$ php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:25:38) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6



jared@ubuntu:~$ ./Development/php-src/sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:41:40) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubunt

Bug #63066 [Com]: Calling an undefined method in a generator results in a seg fault

[larue...@php.net]

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

 ID: 63066
 Comment by: larue...@php.net
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Assigned
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
 Assigned To:nikic
 Block user comment: N
 Private report: N

 New Comment:

a quick fix made, and attached, hope that will help.


Previous Comments:

[2012-09-11 15:27:58] larue...@php.net

The following patch has been added/updated:

Patch Name: bug63066.patch
Revision:   1347377278
URL:
https://bugs.php.net/patch-display.php?bug=63066&patch=bug63066.patch&revision=1347377278


[2012-09-11 15:12:54] larue...@php.net

nikic, while method is not exists, then the EX(object)'s refcount will not be 
increased..

then this object will be dtor in genertor_close, and then the arguments of 
previous exeucte_data clean up.. 

nikic, please look at this.  thanks


[2012-09-11 13:50:49] Jared dot Williams1 at ntlworld dot com

Backtrace of the NON debug seg fault...

jared@ubuntu:~$ gdb ./Development/php-src/sapi/cli/php 
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/jared/Development/php-src/sapi/cli/php...done.
(gdb) run fatalSegFault.php 
Starting program: /home/jared/Development/php-src/sapi/cli/php fatalSegFault.php
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Program received signal SIGSEGV, Segmentation fault.
0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0  0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
#1  0x006f6246 in zend_generator_close 
(generator=generator@entry=0x77fce180, 
finished_execution=finished_execution@entry=0 '\000')
at /home/jared/Development/php-src/Zend/zend_generators.c:148
#2  0x006f63cb in zend_generator_free_storage (generator=0x77fce180)
at /home/jared/Development/php-src/Zend/zend_generators.c:181
#3  0x006fc0a8 in zend_objects_store_free_object_storage (
objects=0xdbae60 )
at /home/jared/Development/php-src/Zend/zend_objects_API.c:92
#4  0x006c7153 in shutdown_executor ()
at /home/jared/Development/php-src/Zend/zend_execute_API.c:298
#5  0x006d5646 in zend_deactivate () at 
/home/jared/Development/php-src/Zend/zend.c:938
#6  0x0067641d in php_request_shutdown (dummy=dummy@entry=0x0)
at /home/jared/Development/php-src/main/main.c:1780
#7  0x00781fe0 in do_cli (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1171
#8  0x0042d56b in main (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1364


[2012-09-11 13:46:20] Jared dot Williams1 at ntlworld dot com

It appears that the seg fault doesn't appear in debug builds. 

Recompiled without debug again, and the seg fault is still present


jared@ubuntu:~$ php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:25:38) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6



jared@ubuntu:~$ ./Development/php-src/sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:41:40) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ ./Development/php-src/sapi/cli/php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.ph

Bug #63066 [PATCH]: Calling an undefined method in a generator results in a seg fault

[larue...@php.net]

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

 ID: 63066
 Patch added by: larue...@php.net
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Assigned
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
 Assigned To:nikic
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug63066.patch
Revision:   1347377278
URL:
https://bugs.php.net/patch-display.php?bug=63066&patch=bug63066.patch&revision=1347377278


Previous Comments:

[2012-09-11 15:12:54] larue...@php.net

nikic, while method is not exists, then the EX(object)'s refcount will not be 
increased..

then this object will be dtor in genertor_close, and then the arguments of 
previous exeucte_data clean up.. 

nikic, please look at this.  thanks


[2012-09-11 13:50:49] Jared dot Williams1 at ntlworld dot com

Backtrace of the NON debug seg fault...

jared@ubuntu:~$ gdb ./Development/php-src/sapi/cli/php 
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/jared/Development/php-src/sapi/cli/php...done.
(gdb) run fatalSegFault.php 
Starting program: /home/jared/Development/php-src/sapi/cli/php fatalSegFault.php
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Program received signal SIGSEGV, Segmentation fault.
0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0  0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
#1  0x006f6246 in zend_generator_close 
(generator=generator@entry=0x77fce180, 
finished_execution=finished_execution@entry=0 '\000')
at /home/jared/Development/php-src/Zend/zend_generators.c:148
#2  0x006f63cb in zend_generator_free_storage (generator=0x77fce180)
at /home/jared/Development/php-src/Zend/zend_generators.c:181
#3  0x006fc0a8 in zend_objects_store_free_object_storage (
objects=0xdbae60 )
at /home/jared/Development/php-src/Zend/zend_objects_API.c:92
#4  0x006c7153 in shutdown_executor ()
at /home/jared/Development/php-src/Zend/zend_execute_API.c:298
#5  0x006d5646 in zend_deactivate () at 
/home/jared/Development/php-src/Zend/zend.c:938
#6  0x0067641d in php_request_shutdown (dummy=dummy@entry=0x0)
at /home/jared/Development/php-src/main/main.c:1780
#7  0x00781fe0 in do_cli (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1171
#8  0x0042d56b in main (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1364


[2012-09-11 13:46:20] Jared dot Williams1 at ntlworld dot com

It appears that the seg fault doesn't appear in debug builds. 

Recompiled without debug again, and the seg fault is still present


jared@ubuntu:~$ php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:25:38) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6



jared@ubuntu:~$ ./Development/php-src/sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:41:40) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ ./Development/php-src/sapi/cli/php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6
Segmentation fault

-

Bug #63066 [Opn]: Calling an undefined method in a generator results in a seg fault

[laruence]

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

 ID: 63066
 Updated by: larue...@php.net
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
-Assigned To:
+Assigned To:nikic
 Block user comment: N
 Private report: N

 New Comment:

nikic, while method is not exists, then the EX(object)'s refcount will not be 
increased..

then this object will be dtor in genertor_close, and then the arguments of 
previous exeucte_data clean up.. 

nikic, please look at this.  thanks


Previous Comments:

[2012-09-11 13:50:49] Jared dot Williams1 at ntlworld dot com

Backtrace of the NON debug seg fault...

jared@ubuntu:~$ gdb ./Development/php-src/sapi/cli/php 
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/jared/Development/php-src/sapi/cli/php...done.
(gdb) run fatalSegFault.php 
Starting program: /home/jared/Development/php-src/sapi/cli/php fatalSegFault.php
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Program received signal SIGSEGV, Segmentation fault.
0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0  0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
#1  0x006f6246 in zend_generator_close 
(generator=generator@entry=0x77fce180, 
finished_execution=finished_execution@entry=0 '\000')
at /home/jared/Development/php-src/Zend/zend_generators.c:148
#2  0x006f63cb in zend_generator_free_storage (generator=0x77fce180)
at /home/jared/Development/php-src/Zend/zend_generators.c:181
#3  0x006fc0a8 in zend_objects_store_free_object_storage (
objects=0xdbae60 )
at /home/jared/Development/php-src/Zend/zend_objects_API.c:92
#4  0x006c7153 in shutdown_executor ()
at /home/jared/Development/php-src/Zend/zend_execute_API.c:298
#5  0x006d5646 in zend_deactivate () at 
/home/jared/Development/php-src/Zend/zend.c:938
#6  0x0067641d in php_request_shutdown (dummy=dummy@entry=0x0)
at /home/jared/Development/php-src/main/main.c:1780
#7  0x00781fe0 in do_cli (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1171
#8  0x0042d56b in main (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1364


[2012-09-11 13:46:20] Jared dot Williams1 at ntlworld dot com

It appears that the seg fault doesn't appear in debug builds. 

Recompiled without debug again, and the seg fault is still present


jared@ubuntu:~$ php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:25:38) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6



jared@ubuntu:~$ ./Development/php-src/sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:41:40) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ ./Development/php-src/sapi/cli/php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6
Segmentation fault


[2012-09-11 13:17:14] jared dot williams1 at ntlworld dot com

No APC or XDebug. 

Will recompile with debug and get a bt.


[2012-09-11 13:13:41] reeze dot xia at gmail dot com

Bug #61955 [Com]: Adding DateInterval to DateTime adds 1 additional hour

[chris dot baker dot gr at gmail dot com]

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

 ID: 61955
 Comment by: chris dot baker dot gr at gmail dot com
 Reported by:php at arjanonline dot net
 Summary:Adding DateInterval to DateTime adds 1 additional
 hour
 Status: Assigned
 Type:   Bug
 Package:Date/time related
 Operating System:   Linux / Mac
 PHP Version:5.3.12
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

Can reproduce this as well, just determined it to be the cause of new errors in 
a scheduling web app after updating to 5.4.


Previous Comments:

[2012-07-09 19:47:08] jgardynik at endlessrealities dot com

I'm getting the same thing. Any single date_modify() call is causing an extra 
hour to be added. If I add 1 minute, it still adds an extra hour. The commit 
that was bisected is very clearly adding an extra hour. If I use 
Pacific/Honolulu or UTC in date_default_timezone_set() it works fine. 
Apparently the fix was not specific enough in its implementation and it's 
taking effect all the time.

This is causing every single one of my monthly comparison reports to break in a 
rather large system because the time is getting thrown off.

I'm using PHP 5.4.4 on linux.


[2012-05-19 15:03:40] graham at grahamc dot com

One minor clarification - This is occurring in every version above 5.3.8.

After running git bisect, I've narrowed it down to this particular commit: 
https://github.com/php/php-src/commit/7411ae09f5565b3f0dfbbfeb71c8f848fd38d6ca


[2012-05-11 15:51:21] zhanglijiu at gmail dot com

My result is object(DateTime)#2 (3) { ["date"]=> string(19) "1970-01-01 
00:00:05" 
["timezone_type"]=> int(1) ["timezone"]=> string(6) "+00:00" }

My system is MAC 10.6.8 php 5.3.1


[2012-05-05 20:45:27] php at arjanonline dot net

Description:

When I create a DateTime object from a (any) timestamp and then add a 
DateInterval object to the DateTime object, the time in the DateInterval object 
is added and one additional hour is also added.

I have not noticed this behavior in versions up to and including 5.3.8, only in 
newer 5.3 versions. (I did not test in 5.4.)
Also the behavior is related to the default time zone, even though the created 
DateTime object is in UTC. I have tested several timezones and it appears that 
all Europe/* and North American America/* timezones are affected. The 
Australian timezones seem to be unaffected.

Information from phpinfo():
date
- date/time support => enabled
- "Olson" Timezone Database Version => 2012.3
- Timezone Database => internal


Test script:
---
date_default_timezone_set('Europe/Amsterdam');
$d1 = new DateTime('@0');
$d2 = clone($d1);
$d2->add(new DateInterval('PT5S'));
var_dump($d2);


Expected result:

object(DateTime)[2]
  public 'date' => string '1970-01-01 00:00:05' (length=19)
  public 'timezone_type' => int 1
  public 'timezone' => string '+00:00' (length=6)

Actual result:
--
object(DateTime)[2]
  public 'date' => string '1970-01-01 01:00:05' (length=19)
  public 'timezone_type' => int 1
  public 'timezone' => string '+00:00' (length=6)






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

Bug #63055 [Fbk->Asn]: Segfault in zend_gc with SF2 testsuite

[php at wallbash dot com]

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

 ID: 63055
 User updated by:php at wallbash dot com
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
-Status: Feedback
+Status: Assigned
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Fixed reproduce instructions: https://gist.github.com/3690351; Maybe that helps 
you laruence.

I've misspelled the phpunit mock object dependency and it doesn't work with 
newer versions (as it, i assume, involves object cloning that newer versions 
have turned off). Any other minor versions don't lead to the segfault.


@reeze,

(gdb) zbacktrace

(gdb) [0x7ff1428d4ea8] 
preg_match_all("/@requires\s+(?Pfunction|extension)\s(?P([^\40]+))\r?$/m",
 
"/**\12\40*\40Note\40that\40there\40are\40some\40values\40written\40like\40-2147483647\40-\401.\40This\40is\40the\40lower\4032bit\40int\40max\40and\40is\40a\40known\12\40*\40behavior\40of\40PHP.\12\40*/\12/**\12\40\40\40\40\40*\40@dataProvider\40formatCurrencyWithCurrencyStyleBrazilianRealRoundingProvider\12\40\40\40\40\40*/",
 array(7)[0x14916c30]) /usr/share/pear/PHPUnit/Util/Test.php:126 
[0x7ff1428d4ab0] 
getRequirements("Symfony\Component\Locale\Tests\Stub\StubNumberFormatterTest", 
"testFormatCurrencyWithCurrencyStyleBrazilianRealRoundingStub") 
/usr/share/pear/PHPUnit/Framework/TestCase.php:558 
[0x7ff1428d4378] setRequirementsFromAnnotation() 
/usr/share/pear/PHPUnit/Framework/TestCase.php:586 
[0x7ff1428d31b0] checkRequirements() 
/usr/share/pear/PHPUnit/Framework/TestCase.php:823 
[0x7ff1428d1d38] runBare() /usr/share/pear/PHPUnit/Framework/TestResult.php:649 
[0x7ff1428d0dd8] run(object[0x747e368]) 
/usr/share/pear/PHPUnit/Framework/TestCase.php:770 
[0x7ff1428d0cd8] run(object[0xa6fcfe0]) 
/usr/share/pear/PHPUnit/Framework/TestSuite.php:776 
[0x7ff1428cf980] runTest(object[0x747e368], object[0xa6fcfe0]) 
/usr/share/pear/PHPUnit/Framework/TestSuite.php:746 
[0x7ff1428ce610] run(object[0xa6fcfe0], false, array(0)[0xa6fa9e8], 
array(1)[0xa7390a8], false) /usr/share/pear/PHPUnit/Framework/TestSuite.php:706 
[0x7ff1428cd2a0] run(object[0xa6fcfe0], false, array(0)[0x14735b38], 
array(1)[0x14735cf0], false) 
/usr/share/pear/PHPUnit/Framework/TestSuite.php:706 
[0x7ff1428caea0] run(object[0xa6fcfe0], false, array(0)[0xab473f0], 
array(1)[0xab475a8], false) /usr/share/pear/PHPUnit/TextUI/TestRunner.php:325 
[0x7ff1428ca528] doRun(object[0x7ff13c2c3ed8], array(5)[0xab48718]) 
/usr/share/pear/PHPUnit/TextUI/Command.php:177 
[0x7ff1428ca360] run(array(1)[0x6b7c498], true) 
/usr/share/pear/PHPUnit/TextUI/Command.php:130 
[0x7ff1428ca0e8] main() /usr/bin/phpunit:46 
(gdb) 

Hope that helps :)


Previous Comments:

[2012-09-11 08:48:58] larue...@php.net

intl

Internationalization support => enabled
version => 1.1.0
ICU version => 3.6


[2012-09-11 06:57:39] reeze dot xia at gmail dot com

gdb > zbactrace   --->  gdb > zbacktrace   missing a 'k' :)


[2012-09-11 06:56:49] reeze dot xia at gmail dot com

Hi wallbash,
  when you got a backtrace, you could source php-src's backtrace of php script

gdb > source path/to/php-src/.gdbinit
gdb > zbactrace 
then you may see a php level script, then we could find where cause the php 
crash


[2012-09-11 06:53:26] reeze dot xia at gmail dot com

>From the backtrace this seems a test for ext: intl, 
I can't install intl ext in my box because of compile issue.

@larucene, do you see some test skip for intl or did you enabled intl extsion?


[2012-09-10 16:34:15] php at wallbash dot com

Like stated on pecl: I sadly can't. Every output i generate or just executing 
that one test case make the segfault go away.

I'm really sorry I can't provide anything more helpful but with issues like 
that (see the last time I ran into something like that: 
https://bugs.php.net/bug.php?id=60825) getting a good repro is really hard for 
me. I've tried for a couple of hours but gave up.

I totally understand if this is not fixable for you of course but asking in 
php.pecl encouraged me to post it anyways :)




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


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

Bug #62474 [Com]: com_event_sink crashes when closure object given as an argument

[fb1h2s at gmail dot com]

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

 ID: 62474
 Comment by: fb1h2s at gmail dot com
 Reported by:deadb17ch at gmail dot com
 Summary:com_event_sink crashes when closure object given as
 an argument
 Status: Open
 Type:   Bug
 Package:COM related
 Operating System:   Windows XP SP3
 PHP Version:5.4.4
 Block user comment: N
 Private report: N

 New Comment:

A reliable way to get coded execution  
http://www.garage4hackers.com/blogs/8/web-
app-remote-code-execution-via-scripting-engines-part-1-local-exploits-php-0-day-
394/ using this bug.


Previous Comments:

[2012-07-27 20:43:06] fb1h2s at gmail dot com

Oh yea my mistake I was referring to arg 1 crash, dint see a Bug Id open for 
that here though.




[2012-07-26 13:43:04] deadb17ch at gmail dot com

I know. I have send an advisory about possible code execution  in 
com_event_sink()  
function using VARIANT object to bugtraq some time ago (21 May) :

http://cxsecurity.com/issue/WLB-2012050163
http://www.exploit-db.com/exploits/18910/

but this time it is about bug in second argument, not first.


[2012-07-26 13:32:17] fb1h2s at gmail dot com

It's possible to achieve code execution using this bug. 

$_evil_object = new VARIANT(0x41414141);


[2012-07-03 20:18:20] deadb17ch at gmail dot com

Description:

com_event_sink() crashes when closure object (anonymouse function) is given as 
the 
second argument...

Test script:
---


Expected result:

nothing happends or an information about error (or maybe argument type 
mismatch) 
occurs


Actual result:
--
crash

eax= ebx=010328f0 ecx= edx=0001 esi=0121e438 edi=
eip=100f33c8 esp=00c0fa50 ebp= iopl=0 nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs= efl=00200202
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for 
C:\xampp\php\php5ts.dll - 
php5ts!php_com_load_typelib_via_cache+0x118:
100f33c8 8b08mov ecx,dword ptr [eax]  ds:0023:= 






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

Bug #63066 [Opn]: Calling an undefined method in a generator results in a seg fault

[Jared dot Williams1 at ntlworld dot com]

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

 ID: 63066
 User updated by:Jared dot Williams1 at ntlworld dot com
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Backtrace of the NON debug seg fault...

jared@ubuntu:~$ gdb ./Development/php-src/sapi/cli/php 
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/jared/Development/php-src/sapi/cli/php...done.
(gdb) run fatalSegFault.php 
Starting program: /home/jared/Development/php-src/sapi/cli/php fatalSegFault.php
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Program received signal SIGSEGV, Segmentation fault.
0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0  0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8)
at /home/jared/Development/php-src/Zend/zend_gc.c:143
#1  0x006f6246 in zend_generator_close 
(generator=generator@entry=0x77fce180, 
finished_execution=finished_execution@entry=0 '\000')
at /home/jared/Development/php-src/Zend/zend_generators.c:148
#2  0x006f63cb in zend_generator_free_storage (generator=0x77fce180)
at /home/jared/Development/php-src/Zend/zend_generators.c:181
#3  0x006fc0a8 in zend_objects_store_free_object_storage (
objects=0xdbae60 )
at /home/jared/Development/php-src/Zend/zend_objects_API.c:92
#4  0x006c7153 in shutdown_executor ()
at /home/jared/Development/php-src/Zend/zend_execute_API.c:298
#5  0x006d5646 in zend_deactivate () at 
/home/jared/Development/php-src/Zend/zend.c:938
#6  0x0067641d in php_request_shutdown (dummy=dummy@entry=0x0)
at /home/jared/Development/php-src/main/main.c:1780
#7  0x00781fe0 in do_cli (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1171
#8  0x0042d56b in main (argc=2, argv=0x7fffe118)
at /home/jared/Development/php-src/sapi/cli/php_cli.c:1364


Previous Comments:

[2012-09-11 13:46:20] Jared dot Williams1 at ntlworld dot com

It appears that the seg fault doesn't appear in debug builds. 

Recompiled without debug again, and the seg fault is still present


jared@ubuntu:~$ php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:25:38) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6



jared@ubuntu:~$ ./Development/php-src/sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:41:40) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ ./Development/php-src/sapi/cli/php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6
Segmentation fault


[2012-09-11 13:17:14] jared dot williams1 at ntlworld dot com

No APC or XDebug. 

Will recompile with debug and get a bt.


[2012-09-11 13:13:41] reeze dot xia at gmail dot com

Can't reproduce in Ubuntu too.

parallels@ubuntu:~/php-src$ uname -a
Linux ubuntu 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 
x86_64 
x86_64 x86_64 GNU/Linux


if your are testing the lastest version, Could please provide backtrace？
https://bugs.php.net/bugs-generating-backtrace.php


[2012-09-11 12:59:13] r

Bug #63066 [Opn]: Calling an undefined method in a generator results in a seg fault

[Jared dot Williams1 at ntlworld dot com]

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

 ID: 63066
 User updated by:Jared dot Williams1 at ntlworld dot com
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
 Block user comment: N
 Private report: N

 New Comment:

It appears that the seg fault doesn't appear in debug builds. 

Recompiled without debug again, and the seg fault is still present


jared@ubuntu:~$ php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:25:38) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6



jared@ubuntu:~$ ./Development/php-src/sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:41:40) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies
jared@ubuntu:~$ ./Development/php-src/sapi/cli/php fatalSegFault.php 
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6
Segmentation fault


Previous Comments:

[2012-09-11 13:17:14] jared dot williams1 at ntlworld dot com

No APC or XDebug. 

Will recompile with debug and get a bt.


[2012-09-11 13:13:41] reeze dot xia at gmail dot com

Can't reproduce in Ubuntu too.

parallels@ubuntu:~/php-src$ uname -a
Linux ubuntu 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 
x86_64 
x86_64 x86_64 GNU/Linux


if your are testing the lastest version, Could please provide backtrace？
https://bugs.php.net/bugs-generating-backtrace.php


[2012-09-11 12:59:13] reeze dot xia at gmail dot com

I could not reproduce it in Mac OS X

do you use any extension like apc, xdebug?


[2012-09-11 12:49:54] Jared dot Williams1 at ntlworld dot com

Description:

Calling an undefined method in a generator results in an expected fatal error, 
but then a segmentation fault occurs afterwards.

Test script:
---
function gen($o)
{
yield 'foo';
$o->fatalError();
}

foreach(gen(new stdClass()) as $value)
echo $value, "\n";

Expected result:

foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Actual result:
--
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6
Segmentation fault







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

Bug #63066 [Com]: Calling an undefined method in a generator results in a seg fault

[jared dot williams1 at ntlworld dot com]

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

 ID: 63066
 Comment by: jared dot williams1 at ntlworld dot com
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
 Block user comment: N
 Private report: N

 New Comment:

No APC or XDebug. 

Will recompile with debug and get a bt.


Previous Comments:

[2012-09-11 13:13:41] reeze dot xia at gmail dot com

Can't reproduce in Ubuntu too.

parallels@ubuntu:~/php-src$ uname -a
Linux ubuntu 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 
x86_64 
x86_64 x86_64 GNU/Linux


if your are testing the lastest version, Could please provide backtrace？
https://bugs.php.net/bugs-generating-backtrace.php


[2012-09-11 12:59:13] reeze dot xia at gmail dot com

I could not reproduce it in Mac OS X

do you use any extension like apc, xdebug?


[2012-09-11 12:49:54] Jared dot Williams1 at ntlworld dot com

Description:

Calling an undefined method in a generator results in an expected fatal error, 
but then a segmentation fault occurs afterwards.

Test script:
---
function gen($o)
{
yield 'foo';
$o->fatalError();
}

foreach(gen(new stdClass()) as $value)
echo $value, "\n";

Expected result:

foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Actual result:
--
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6
Segmentation fault







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

Bug #63066 [Com]: Calling an undefined method in a generator results in a seg fault

[reeze dot xia at gmail dot com]

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

 ID: 63066
 Comment by: reeze dot xia at gmail dot com
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Can't reproduce in Ubuntu too.

parallels@ubuntu:~/php-src$ uname -a
Linux ubuntu 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 
x86_64 
x86_64 x86_64 GNU/Linux


if your are testing the lastest version, Could please provide backtrace？
https://bugs.php.net/bugs-generating-backtrace.php


Previous Comments:

[2012-09-11 12:59:13] reeze dot xia at gmail dot com

I could not reproduce it in Mac OS X

do you use any extension like apc, xdebug?


[2012-09-11 12:49:54] Jared dot Williams1 at ntlworld dot com

Description:

Calling an undefined method in a generator results in an expected fatal error, 
but then a segmentation fault occurs afterwards.

Test script:
---
function gen($o)
{
yield 'foo';
$o->fatalError();
}

foreach(gen(new stdClass()) as $value)
echo $value, "\n";

Expected result:

foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Actual result:
--
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6
Segmentation fault







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

Bug #63066 [Com]: Calling an undefined method in a generator results in a seg fault

[reeze dot xia at gmail dot com]

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

 ID: 63066
 Comment by: reeze dot xia at gmail dot com
 Reported by:Jared dot Williams1 at ntlworld dot com
 Summary:Calling an undefined method in a generator results
 in a seg fault
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   Linux ubuntu 3.5.0-14-generic #1
 PHP Version:master-Git-2012-09-11 (Git)
 Block user comment: N
 Private report: N

 New Comment:

I could not reproduce it in Mac OS X

do you use any extension like apc, xdebug?


Previous Comments:

[2012-09-11 12:49:54] Jared dot Williams1 at ntlworld dot com

Description:

Calling an undefined method in a generator results in an expected fatal error, 
but then a segmentation fault occurs afterwards.

Test script:
---
function gen($o)
{
yield 'foo';
$o->fatalError();
}

foreach(gen(new stdClass()) as $value)
echo $value, "\n";

Expected result:

foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Actual result:
--
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6
Segmentation fault







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

[PHP-BUG] Bug #63066 [NEW]: Calling an undefined method in a generator results in a seg fault

[Jared dot Williams1 at ntlworld dot com]

From: Jared dot Williams1 at ntlworld dot com
Operating system: Linux ubuntu 3.5.0-14-generic #1
PHP version:  master-Git-2012-09-11 (Git)
Package:  Class/Object related
Bug Type: Bug
Bug description:Calling an undefined method in a generator results in a seg 
fault

Description:

Calling an undefined method in a generator results in an expected fatal
error, 
but then a segmentation fault occurs afterwards.

Test script:
---
function gen($o)
{
yield 'foo';
$o->fatalError();
}

foreach(gen(new stdClass()) as $value)
echo $value, "\n";

Expected result:

foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Actual result:
--
foo
PHP Fatal error:  Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6

Fatal error: Call to undefined method stdClass::fatalError() in 
/home/jared/fatalSegFault.php on line 6
Segmentation fault


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

Bug #63060 [Com]: Option LIBXML_NOEMPTYTAG is ignored

[reeze dot xia at gmail dot com]

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

 ID: 63060
 Comment by: reeze dot xia at gmail dot com
 Reported by:maglor at i dot ua
 Summary:Option LIBXML_NOEMPTYTAG is ignored
 Status: Open
 Type:   Bug
 Package:SimpleXML related
 Operating System:   Windows XP SP3
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

Hi maglor,

http://php.net/manual/en/libxml.constants.php


LIBXML_NOEMPTYTAG (integer)
Expand empty tags (e.g.  to )
Note:

This option is currently just available in the DOMDocument::save and 
DOMDocument::saveXML functions.


Previous Comments:

[2012-09-11 09:36:02] maglor at i dot ua

Description:

Option LIBXML_NOEMPTYTAG is ignored for SimpleXMLElement::__construct() and 
simplexml_load_string() 

Probably, for simplexml_load_file() also.



Test script:
---
', LIBXML_NOEMPTYTAG);
$xml->saveXML();


Expected result:




Actual result:
--








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

Req #63061 [Opn->Csd]: Provide a specific error message if date.timezone value is invalid

[laruence]

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

 ID: 63061
 Updated by: larue...@php.net
 Reported by:simon at welsh dot co dot nz
 Summary:Provide a specific error message if date.timezone
 value is invalid
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Date/time related
 Operating System:   N/A
 PHP Version:5.4.6
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2012-09-11 09:37:02] simon at welsh dot co dot nz

Description:

Rather than failing with the generic "it's bad to use the system timezone 
value, 
set date.timezone" when date.timezone is set, but incorrectly, fail telling the 
user that.

GitHub pull request at https://github.com/php/php-src/pull/188







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

[PHP-BUG] Req #63061 [NEW]: Provide a specific error message if date.timezone value is invalid

[simon at welsh dot co dot nz]

From: simon at welsh dot co dot nz
Operating system: N/A
PHP version:  5.4.6
Package:  Date/time related
Bug Type: Feature/Change Request
Bug description:Provide a specific error message if date.timezone value is 
invalid

Description:

Rather than failing with the generic "it's bad to use the system timezone
value, 
set date.timezone" when date.timezone is set, but incorrectly, fail telling
the 
user that.

GitHub pull request at https://github.com/php/php-src/pull/188


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

[PHP-BUG] Bug #63060 [NEW]: Option LIBXML_NOEMPTYTAG is ignored

[maglor at i dot ua]

From: maglor at i dot ua
Operating system: Windows XP SP3
PHP version:  5.3.16
Package:  SimpleXML related
Bug Type: Bug
Bug description:Option LIBXML_NOEMPTYTAG is ignored

Description:

Option LIBXML_NOEMPTYTAG is ignored for SimpleXMLElement::__construct() and
simplexml_load_string() 

Probably, for simplexml_load_file() also.



Test script:
---
',
LIBXML_NOEMPTYTAG);
$xml->saveXML();


Expected result:




Actual result:
--



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

Bug #63055 [Opn->Fbk]: Segfault in zend_gc with SF2 testsuite

[laruence]

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

 ID: 63055
 Updated by: larue...@php.net
 Reported by:php at wallbash dot com
 Summary:Segfault in zend_gc with SF2 testsuite
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*General Issues
 Operating System:   CentOS 6.3
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

intl

Internationalization support => enabled
version => 1.1.0
ICU version => 3.6


Previous Comments:

[2012-09-11 06:57:39] reeze dot xia at gmail dot com

gdb > zbactrace   --->  gdb > zbacktrace   missing a 'k' :)


[2012-09-11 06:56:49] reeze dot xia at gmail dot com

Hi wallbash,
  when you got a backtrace, you could source php-src's backtrace of php script

gdb > source path/to/php-src/.gdbinit
gdb > zbactrace 
then you may see a php level script, then we could find where cause the php 
crash


[2012-09-11 06:53:26] reeze dot xia at gmail dot com

>From the backtrace this seems a test for ext: intl, 
I can't install intl ext in my box because of compile issue.

@larucene, do you see some test skip for intl or did you enabled intl extsion?


[2012-09-10 16:34:15] php at wallbash dot com

Like stated on pecl: I sadly can't. Every output i generate or just executing 
that one test case make the segfault go away.

I'm really sorry I can't provide anything more helpful but with issues like 
that (see the last time I ran into something like that: 
https://bugs.php.net/bug.php?id=60825) getting a good repro is really hard for 
me. I've tried for a couple of hours but gave up.

I totally understand if this is not fixable for you of course but asking in 
php.pecl encouraged me to post it anyways :)


[2012-09-10 12:53:17] larue...@php.net

I can not reproduce this with 5.4-branch...

could you try to make a small reproduce test script ?  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=63055


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

Bug #63057 [Opn->Csd]: problem in cUrl with CURLOPT_PRIVATE and CURLINFO_PRIVATE

[stefanos at cpan dot org]

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

 ID: 63057
 User updated by:stefanos at cpan dot org
 Reported by:stefanos at cpan dot org
 Summary:problem in cUrl with CURLOPT_PRIVATE and
 CURLINFO_PRIVATE
-Status: Open
+Status: Closed
 Type:   Bug
 Package:cURL related
 Operating System:   Debian Linux 6.0.5
-PHP Version:5.3.16
+PHP Version:5.4.16
 Block user comment: N
 Private report: N

 New Comment:

okay, thanks for the answer. With php version 5.4.6 is no problem. I close the 
bugreport.


Previous Comments:

[2012-09-11 07:03:53] ras...@php.net

Ok, I compiled against 7.27 and I am still unable to reproduce this:

12:02am x220:~> php -i | grep "cURL Info"
cURL Information => 7.27.0

12:02am x220:~> php test.php
Next - 666 - 404 - 0.55528 Sec - Request http://www.kb-gaming.com/
Next - 64 - 200 - 0.746688 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.554405 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.782507 Sec - Request https://www.google.de/


[2012-09-11 05:18:03] ras...@php.net

PHP 5.3.16/5.4.6 w/ Curl 7.22

Next - 666 - 404 - 0.543194 Sec - Request http://www.kb-gaming.com/
Next - 64 - 200 - 0.759856 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.555988 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.769565 Sec - Request https://www.google.de/


[2012-09-11 04:59:56] stefanos at cpan dot org

maybe a libcurl issue, can you test this with newer cUrl version?

7.15.5 is very old (year 2006)


[2012-09-11 04:19:18] larue...@php.net

I can not reproduce this, maybe a libcurl issue?

cURL support => enabled
cURL Information => 7.15.5


[2012-09-10 21:21:40] stefanos at cpan dot org

Description:

Currently, while using a testscript with curl_multi, the option CURLOPT_PRIVATE 
(per curl_setopt) isn't stored correctly, is getting messed up or can't be 
retrieved properly with curl_getinfo($curl,CURLINFO_PRIVATE). The result with 
multiple URLs is that the last entry (in this example 620) is used instead of 
64, 666, 600.

cUrl version 7.27.0

Now where exactly is the error? Script? cURL? PHP?


Test script:
---
More as 20 lines, see the url: 
http://pastebin.com/raw.php?i=dascV5Xv

Expected result:

Next - 64 - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 666 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/

Actual result:
--
Next -  - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 620 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 620 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/






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

Bug #63057 [Opn]: problem in cUrl with CURLOPT_PRIVATE and CURLINFO_PRIVATE

[rasmus]

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

 ID: 63057
 Updated by: ras...@php.net
 Reported by:stefanos at cpan dot org
 Summary:problem in cUrl with CURLOPT_PRIVATE and
 CURLINFO_PRIVATE
 Status: Open
 Type:   Bug
 Package:cURL related
 Operating System:   Debian Linux 6.0.5
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

Ok, I compiled against 7.27 and I am still unable to reproduce this:

12:02am x220:~> php -i | grep "cURL Info"
cURL Information => 7.27.0

12:02am x220:~> php test.php
Next - 666 - 404 - 0.55528 Sec - Request http://www.kb-gaming.com/
Next - 64 - 200 - 0.746688 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.554405 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.782507 Sec - Request https://www.google.de/


Previous Comments:

[2012-09-11 05:18:03] ras...@php.net

PHP 5.3.16/5.4.6 w/ Curl 7.22

Next - 666 - 404 - 0.543194 Sec - Request http://www.kb-gaming.com/
Next - 64 - 200 - 0.759856 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.555988 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.769565 Sec - Request https://www.google.de/


[2012-09-11 04:59:56] stefanos at cpan dot org

maybe a libcurl issue, can you test this with newer cUrl version?

7.15.5 is very old (year 2006)


[2012-09-11 04:19:18] larue...@php.net

I can not reproduce this, maybe a libcurl issue?

cURL support => enabled
cURL Information => 7.15.5


[2012-09-10 21:21:40] stefanos at cpan dot org

Description:

Currently, while using a testscript with curl_multi, the option CURLOPT_PRIVATE 
(per curl_setopt) isn't stored correctly, is getting messed up or can't be 
retrieved properly with curl_getinfo($curl,CURLINFO_PRIVATE). The result with 
multiple URLs is that the last entry (in this example 620) is used instead of 
64, 666, 600.

cUrl version 7.27.0

Now where exactly is the error? Script? cURL? PHP?


Test script:
---
More as 20 lines, see the url: 
http://pastebin.com/raw.php?i=dascV5Xv

Expected result:

Next - 64 - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 666 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 600 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/

Actual result:
--
Next -  - 404 - 0.061303 Sec - Request http://www.kb-gaming.com/
Next - 620 - 200 - 0.057142 Sec - Request http://www.sd-p.ch/
Next - 620 - 200 - 0.032915 Sec - Request http://richardschwab.de/
Next - 620 - 200 - 0.326081 Sec - Request https://www.google.de/






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