Bug #40880 [Com]: public->protected inheritance causes fatal
Edit report at https://bugs.php.net/bug.php?id=40880&edit=1 ID: 40880 Comment by: postmaster at greg0ire dot fr Reported by:prometheus__0 at hotmail dot com Summary:public->protected inheritance causes fatal Status: Not a bug Type: Bug Package:Class/Object related Operating System: SUSE SLES 10 PHP Version:5CVS-2007-03-21 (snap) Block user comment: N Private report: N New Comment: @rasmus: Then why is there a strict warning regarding the compatibility of method signatures for this code: -- class Foo { public function test() { } } class Bar extends Foo { public function test(ArrayObject $arrayObj, $number = 0) { /* do stuff with $arrayObj and $number */ } } --- and not for this one: --- class Foo { public function __construct() { } } class Bar extends Foo { public function __construct(ArrayObject $arrayObj, $number = 0) { /* do stuff with $arrayObj and $number */ } } No, as stated here : - http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle - and here: http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern, the LSP does not apply to constructors for several reasons: - When you call the constructor, you know whether you're using the type or one of its subtypes. - You can't apply the LSP to an object that does not exist yet. I think this is a design flaw. Not "massive", but a design flaw indeed. Previous Comments: [2012-05-06 16:12:00] ras...@php.net Most (all?) object oriented languages work this way. Java and C# both do. You can loosen visibility when you override a parent method, but you can never tighten it. This is part of what is known as the Liskov Substitution Principle and it is one of the fundamental principles of object oriented programming. You can read about at http://en.wikipedia.org/wiki/Liskov_substitution_principle I can guarantee that abiding by LSP is not a bug [2012-05-06 15:40:26] ekincigokan at gmail dot com Same "problem". class A{ public function __construct(){} } class B extends A { protected function __construct(){} } Please, can you tell us a reason why we can't put an private/protected access to B's constructor if A's constructor is public ? Is there any logical reason to this ? Thanks. [2011-09-10 22:27:24] herman dot wetherington at gmail dot com Apparently, we don't call this a "bug" because this is not caused by a programming error. So I'm calling it a "massive design flaw" instead. [2010-10-15 23:33:35] robertoblanko at gmail dot com Same problem here. You cannot actually apply the singleton pattern to subclasses with this behavior. I do not see any reason for not calling this a bug. [2010-09-07 12:58:35] nickyla83 at yahoo dot fr I'm in the same situation as our friend "prometheus" here, I am trying to use a singleton pattern and logically, this should involve being able to encapsulate the subcalasses information particularly setting up a private constructor for the singleton subclass, IT DEFINITELY DOES MAKE SENSE, so please try to take this under consideration for the next php engine release. 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=40880 -- Edit this bug report at https://bugs.php.net/bug.php?id=40880&edit=1
Bug #51160 [Com]: Exec family of functions runs a script piped into 'head' too until script end
Edit report at https://bugs.php.net/bug.php?id=51160&edit=1 ID: 51160 Comment by: mrvanes at gmail dot com Reported by:poehler at interworx dot com Summary:Exec family of functions runs a script piped into 'head' too until script end Status: Not a bug Type: Bug Package:*General Issues Operating System: CentOS 5.4 PHP Version:5.2.13 Block user comment: N Private report: N New Comment: I was encountering a similar problem too and for some reason Mike's hint (registering an empty/exit function on the SIGPIPE signal) solved the problem for me. The only problem I now have is racking my brains over WHY?! Is this discussed somewhere so I can read up on the given solution? Previous Comments: [2012-01-19 12:26:16] burek021 at gmail dot com Just to say, my problem somehow got misteriosly solved. I don't know exactly what was the culprit, but I know I've messed around with ulimit and with apache2.conf: StartServers 5 MinSpareServers 5 MaxSpareServers 100 MaxClients 150 MaxRequestsPerChild 0 More details here (if needed): http://www.linuxquestions.org/questions/showthread.php?p=4577927 [2012-01-18 21:59:26] burek021 at gmail dot com I also have this issue. I've tried to test a simple example on several of our web hosting machines and all of them have this issue present. Simple test. Create a php file (test.php) with this content: == &1 you should get the error like: ls: write error: Broken pipe almost every time you run that command. I'm not sure what's the reason for this, but I'm pretty sure it's the bug, since the bash/sh doesn't ever raise that error no matter how many ls'es we put into the pipe. [2010-12-07 21:57:02] sirjava at gmail dot com I'm confused. If the exec family of functions is designed to execute something as if executed from a shell, and the command executes properly from a shell, but not in php... how is this not a php bug? [2010-05-17 11:21:33] m...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. $ cat 51160.php https://bugs.php.net/bug.php?id=51160 -- Edit this bug report at https://bugs.php.net/bug.php?id=51160&edit=1
Bug #61928 [Opn->Nab]: Instanciate object for aliased class
Edit report at https://bugs.php.net/bug.php?id=61928&edit=1 ID: 61928 Updated by: maar...@php.net Reported by:olav at fwt dot no Summary:Instanciate object for aliased class -Status: Open +Status: Not a bug Type: Bug Package:Class/Object related Operating System: Linux 3.3.4 PHP Version:5.3.12 Block user comment: N Private report: N New Comment: 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 This isn't a bug, see Example 3 @ http://www.php.net/manual/en/language.namespaces.importing.php and the note "Importing is performed at compile-time, and so does not affect dynamic class, function or constant names." So your code is referencing Foo in the root namespace, which is the documented behavior. Previous Comments: [2012-05-03 19:01:09] olav at fwt dot no It seems this problem is not related to the use keyword but imported items in general: file: test2.php https://bugs.php.net/bug.php?id=61928&edit=1
Bug #40880 [Nab]: public->protected inheritance causes fatal
Edit report at https://bugs.php.net/bug.php?id=40880&edit=1 ID: 40880 Updated by: paj...@php.net Reported by:prometheus__0 at hotmail dot com Summary:public->protected inheritance causes fatal Status: Not a bug Type: Bug Package:Class/Object related Operating System: SUSE SLES 10 PHP Version:5CVS-2007-03-21 (snap) Block user comment: N Private report: N New Comment: @postmaster at greg0ire dot fr __construct applies only to the class where it is declared. On the other hand, a method, already defined in the parent class, must be as visible as the one declared in the parent class and with a compatible signature. The 2nd clause is not respected in your example as the 1st argument is not optional. It would work if it was optional, making $a->test() possible ass it is with the parent class. All these details are very explained in the PHP manual and other various OOP references out there. Previous Comments: [2012-05-07 08:14:16] postmaster at greg0ire dot fr @rasmus: Then why is there a strict warning regarding the compatibility of method signatures for this code: -- class Foo { public function test() { } } class Bar extends Foo { public function test(ArrayObject $arrayObj, $number = 0) { /* do stuff with $arrayObj and $number */ } } --- and not for this one: --- class Foo { public function __construct() { } } class Bar extends Foo { public function __construct(ArrayObject $arrayObj, $number = 0) { /* do stuff with $arrayObj and $number */ } } No, as stated here : - http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle - and here: http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern, the LSP does not apply to constructors for several reasons: - When you call the constructor, you know whether you're using the type or one of its subtypes. - You can't apply the LSP to an object that does not exist yet. I think this is a design flaw. Not "massive", but a design flaw indeed. [2012-05-06 16:12:00] ras...@php.net Most (all?) object oriented languages work this way. Java and C# both do. You can loosen visibility when you override a parent method, but you can never tighten it. This is part of what is known as the Liskov Substitution Principle and it is one of the fundamental principles of object oriented programming. You can read about at http://en.wikipedia.org/wiki/Liskov_substitution_principle I can guarantee that abiding by LSP is not a bug [2012-05-06 15:40:26] ekincigokan at gmail dot com Same "problem". class A{ public function __construct(){} } class B extends A { protected function __construct(){} } Please, can you tell us a reason why we can't put an private/protected access to B's constructor if A's constructor is public ? Is there any logical reason to this ? Thanks. [2011-09-10 22:27:24] herman dot wetherington at gmail dot com Apparently, we don't call this a "bug" because this is not caused by a programming error. So I'm calling it a "massive design flaw" instead. [2010-10-15 23:33:35] robertoblanko at gmail dot com Same problem here. You cannot actually apply the singleton pattern to subclasses with this behavior. I do not see any reason for not calling this a bug. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=40880 -- Edit this bug report at https://bugs.php.net/bug.php?id=40880&edit=1
Bug #61945 [Com]: array returned from __get method gices a notice when trying to change a value
Edit report at https://bugs.php.net/bug.php?id=61945&edit=1 ID: 61945 Comment by: ni...@php.net Reported by:sevenrow2 at yahoo dot com Summary:array returned from __get method gices a notice when trying to change a value Status: Open Type: Bug Package:Dynamic loading Operating System: Windows 7 PHP Version:5.4.2 Block user comment: N Private report: N New Comment: You should define __get to return by reference: public function &__get($name) { ... } Modifications of the type $foo->x[0] = 'y' (where ->x is a magic property) happen by executing roughly the following code: $array =& $foo->x; $array[0] = 'y'; If $foo->x is not a reference here though, $array[0] = 'y' will only be able to change the copied array, not the original one. In your case you still see the change due to a lucky combination of arrays and objects. You aren't actually modifying the array, but only the object and objects behave reference-like by themselves. --- I'd be inclined to close this as Not A Bug, but there is actually some kind of bug in here: PHP should see that $foo->x[0]->y = 'z' does not change the returned array, so no notice should appear. But I'm not sure whether that's fixable. Previous Comments: [2012-05-04 22:33:22] sevenrow2 at yahoo dot com Description: I'm using the latest downloadable version of PHP 5.4.2. See the following code (this code works): --- vars[$name])) { $arrObj = new B(); $this->vars[$name] = $arrObj; } $obj = $this->vars[$name]; return $obj; } } class B { public $rolename = 'foo'; } $a = new A; var_dump($a); echo $a->role->rolename.PHP_EOL; $a->role->rolename = 'test'; echo $a->role->rolename; ?> - What happends in this code is that i create a simple object "A". From that object i try to get the 'role' property. It doesn't exist, so the magic __get() function is called. In there i create a B() object and i return the instance of that object. Right after that i'm trying to access the 'rolename' property of the 'B()' object: echo $a->role->rolename.PHP_EOL; $a->role->rolename = 'test'; This works. It successfully echo's the rolename and changes it after that. - The problem occurs when i return an array with objects: vars[$name])) { $arrObj = array(); $arrObj[] = new B(); $arrObj[] = new B(); $this->vars[$name] = $arrObj; } return $this->vars[$name]; } } class B { public $rolename = 'foo'; } $a = new A; var_dump($a); echo $a->role[0]->rolename.PHP_EOL; $a->role[0]->rolename = 'test'; echo $a->role[0]->rolename; ?> -- This code gives me the following notice: "Notice: Indirect modification of overloaded property A::$role has no effect" Strangely enough it tells me that i can't change the property any more. Or better yet, it has no effect. The only difference is, is that i get the object from an array. The weird thing is though, that it DOES alter the value of the property, regardless of the notice. I think the notice shouldn't be displayed in this case. Test script: --- vars[$name])) { $arrObj = array(); $arrObj[] = new B(); $arrObj[] = new B(); $this->vars[$name] = $arrObj; } return $this->vars[$name]; } } class B { public $rolename = 'foo'; } $a = new A; var_dump($a); echo $a->role[0]->rolename.PHP_EOL; $a->role[0]->rolename = 'test'; echo $a->role[0]->rolename; ?> Expected result: I expected that $a->role[0]->rolename = 'test'; simply changed the value of that property, but it generates an unexpected 'notice'. But: echo $a->role[0]->rolename; does show me that the property was actually changed, regardless of the notice which tells that it can't be changed. -- Edit this bug report at https://bugs.php.net/bug.php?id=61945&edit=1
Bug #40880 [Com]: public->protected inheritance causes fatal
Edit report at https://bugs.php.net/bug.php?id=40880&edit=1 ID: 40880 Comment by: postmaster at greg0ire dot fr Reported by:prometheus__0 at hotmail dot com Summary:public->protected inheritance causes fatal Status: Not a bug Type: Bug Package:Class/Object related Operating System: SUSE SLES 10 PHP Version:5CVS-2007-03-21 (snap) Block user comment: N Private report: N New Comment: @pajoye : let me explain better what I tried to point out there: Rasmus says the Fatal error we're getting is here to enforce the LSP. What I'm saying here is that I'm not getting a signature-compatibility strict notice with the __construct() example , so obviously, the developer who wrote this notice thinks that LSP should not apply to __construct() (and I agree with him). This is just one more argument to convince Rasmus that the LSP does not apply here : obviously, even some member of the php team are aware of that. So to sum up the rules you are talking about, though "explained in the PHP manual", should not apply to __construct() (please read the references I gave in my previous comment to understand why). Previous Comments: [2012-05-07 09:49:52] paj...@php.net @postmaster at greg0ire dot fr __construct applies only to the class where it is declared. On the other hand, a method, already defined in the parent class, must be as visible as the one declared in the parent class and with a compatible signature. The 2nd clause is not respected in your example as the 1st argument is not optional. It would work if it was optional, making $a->test() possible ass it is with the parent class. All these details are very explained in the PHP manual and other various OOP references out there. [2012-05-07 08:14:16] postmaster at greg0ire dot fr @rasmus: Then why is there a strict warning regarding the compatibility of method signatures for this code: -- class Foo { public function test() { } } class Bar extends Foo { public function test(ArrayObject $arrayObj, $number = 0) { /* do stuff with $arrayObj and $number */ } } --- and not for this one: --- class Foo { public function __construct() { } } class Bar extends Foo { public function __construct(ArrayObject $arrayObj, $number = 0) { /* do stuff with $arrayObj and $number */ } } No, as stated here : - http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle - and here: http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern, the LSP does not apply to constructors for several reasons: - When you call the constructor, you know whether you're using the type or one of its subtypes. - You can't apply the LSP to an object that does not exist yet. I think this is a design flaw. Not "massive", but a design flaw indeed. [2012-05-06 16:12:00] ras...@php.net Most (all?) object oriented languages work this way. Java and C# both do. You can loosen visibility when you override a parent method, but you can never tighten it. This is part of what is known as the Liskov Substitution Principle and it is one of the fundamental principles of object oriented programming. You can read about at http://en.wikipedia.org/wiki/Liskov_substitution_principle I can guarantee that abiding by LSP is not a bug [2012-05-06 15:40:26] ekincigokan at gmail dot com Same "problem". class A{ public function __construct(){} } class B extends A { protected function __construct(){} } Please, can you tell us a reason why we can't put an private/protected access to B's constructor if A's constructor is public ? Is there any logical reason to this ? Thanks. [2011-09-10 22:27:24] herman dot wetherington at gmail dot com Apparently, we don't call this a "bug" because this is not caused by a programming error. So I'm calling it a "massive design flaw" instead. 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=40880 -- Edit this bug report at https://bugs.php.net/bug.php?id=40880&edit=1
Bug #40880 [Nab]: public->protected inheritance causes fatal
Edit report at https://bugs.php.net/bug.php?id=40880&edit=1 ID: 40880 Updated by: ras...@php.net Reported by:prometheus__0 at hotmail dot com Summary:public->protected inheritance causes fatal Status: Not a bug Type: Bug Package:Class/Object related Operating System: SUSE SLES 10 PHP Version:5CVS-2007-03-21 (snap) Block user comment: N Private report: N New Comment: This bug report isn't about constructors specifically though. See the bug title and the opening points (1) and (2). The fact that __construct was used as an example seemed entirely coincidental here. For constructors specifically, I agree that Liskov can be mostly ignored, and we do so as you have discovered. The one case where we haven't is visibility. It seems a bit of an edge-case to tighten visibility on an inherited constructor and if that discourages the singleton pattern we might be doing the world a favour here. Previous Comments: [2012-05-07 12:17:27] postmaster at greg0ire dot fr @pajoye : let me explain better what I tried to point out there: Rasmus says the Fatal error we're getting is here to enforce the LSP. What I'm saying here is that I'm not getting a signature-compatibility strict notice with the __construct() example , so obviously, the developer who wrote this notice thinks that LSP should not apply to __construct() (and I agree with him). This is just one more argument to convince Rasmus that the LSP does not apply here : obviously, even some member of the php team are aware of that. So to sum up the rules you are talking about, though "explained in the PHP manual", should not apply to __construct() (please read the references I gave in my previous comment to understand why). [2012-05-07 09:49:52] paj...@php.net @postmaster at greg0ire dot fr __construct applies only to the class where it is declared. On the other hand, a method, already defined in the parent class, must be as visible as the one declared in the parent class and with a compatible signature. The 2nd clause is not respected in your example as the 1st argument is not optional. It would work if it was optional, making $a->test() possible ass it is with the parent class. All these details are very explained in the PHP manual and other various OOP references out there. [2012-05-07 08:14:16] postmaster at greg0ire dot fr @rasmus: Then why is there a strict warning regarding the compatibility of method signatures for this code: -- class Foo { public function test() { } } class Bar extends Foo { public function test(ArrayObject $arrayObj, $number = 0) { /* do stuff with $arrayObj and $number */ } } --- and not for this one: --- class Foo { public function __construct() { } } class Bar extends Foo { public function __construct(ArrayObject $arrayObj, $number = 0) { /* do stuff with $arrayObj and $number */ } } No, as stated here : - http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle - and here: http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern, the LSP does not apply to constructors for several reasons: - When you call the constructor, you know whether you're using the type or one of its subtypes. - You can't apply the LSP to an object that does not exist yet. I think this is a design flaw. Not "massive", but a design flaw indeed. [2012-05-06 16:12:00] ras...@php.net Most (all?) object oriented languages work this way. Java and C# both do. You can loosen visibility when you override a parent method, but you can never tighten it. This is part of what is known as the Liskov Substitution Principle and it is one of the fundamental principles of object oriented programming. You can read about at http://en.wikipedia.org/wiki/Liskov_substitution_principle I can guarantee that abiding by LSP is not a bug [2012-05-06 15:40:26] ekincigokan at gmail dot com Same "problem". class A{ public function __construct(){} } class B extends A { protected function __construct(){} } Please, can you tell us a reason why we can't put an private/protected access to B's constructor if A's constructor is public ? Is there any logical reason to 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
Bug #61905 [Opn->Csd]: ext\phar\tests\zip\phar_commitwrite.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61905&edit=1 ID: 61905 Updated by: a...@php.net Reported by:a...@php.net Summary:ext\phar\tests\zip\phar_commitwrite.phpt fails -Status: Open +Status: Closed Type: Bug Package:PHAR related Operating System: windows PHP Version:Irrelevant -Assigned To: +Assigned To:ab Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-05-02 15:15:46] a...@php.net Description: Test diff: 001+ Fatal error: Uncaught exception 'BadMethodCallException' with message 'Entry file1.txt does not exist and cannot be created: phar error: unable to create temporary file' in C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\zip\phar_commitwrite.php:3 002+ Stack trace: 003+ #0 C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\zip\phar_commitwrite.php(3): Phar->offsetSet('file1.txt', 'hi') 004+ #1 {main} 005+ thrown in C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\zip\phar_commitwrite.php on line 3 001- string(60) " 011- " 012- bool(true) 013- ===DONE=== Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61905&edit=1
Bug #61903 [Opn->Csd]: ext\phar\tests\tar\phar_commitwrite.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61903&edit=1 ID: 61903 Updated by: a...@php.net Reported by:a...@php.net Summary:ext\phar\tests\tar\phar_commitwrite.phpt fails -Status: Open +Status: Closed Type: Bug Package:PHAR related Operating System: windows PHP Version:Irrelevant -Assigned To: +Assigned To:ab Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-05-02 15:08:07] a...@php.net Description: test diff: 001+ Fatal error: Uncaught exception 'BadMethodCallException' with message 'Entry file1.txt does not exist and cannot be created: phar error: unable to create temporary file' in C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\tar\phar_commitwrite.php:3 002+ Stack trace: 003+ #0 C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\tar\phar_commitwrite.php(3): Phar->offsetSet('file1.txt', 'hi') 004+ #1 {main} 005+ thrown in C:\snaps\php-test-pack-5.3-nts-windows-vc9-x86-rf3d86b3\ext\phar\tests\tar\phar_commitwrite.php on line 3 001- string(60) " 011- " 012- bool(true) 013- ===DONE=== Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61903&edit=1
Bug #61947 [Com]: curl Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61947&edit=1 ID: 61947 Comment by: ly...@php.net Reported by:ly...@php.net Summary:curl Segmentation fault Status: Feedback Type: Bug Package:cURL related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I have reproduced this on an RHEL5.7 box with PHP 5.3.3 Still not supported, but getting closer... Previous Comments: [2012-05-05 15:28:01] ras...@php.net There were known libcurl+curl_multi crashes in curl 7.15-7.19. See bug #47773 [2012-05-05 11:16:58] paj...@php.net Please do it already, the shorter script we get, the easier it will be to work on a fix. [2012-05-05 11:12:57] ly...@php.net If it helps, I now have a script that crashes every time, with a similar backtrace. Not a short script, mind you, but the libcurl bits aren't all that long either. If I hear back from somebody that wants to look at it, I'll strip out the non-curl parts, see if it crashes, and put here. Might just do that anyway, since I'm kind of stalled right now... [2012-05-05 05:39:24] ly...@php.net It is definitely the second one, with the POST that is crashing. Repeatable. [2012-05-05 05:00:00] ceo at l-i-e dot com I've got 9 more of these backtraces if you want them. And about 8 of these with no backtrace or anything at all: [Fri May 04 10:59:37 2012] [notice] child pid 24011 exit signal Segmentation fault (11) [Fri May 04 11:10:00 2012] [notice] child pid 24050 exit signal Segmentation fault (11) [Fri May 04 11:10:03 2012] [notice] child pid 24044 exit signal Segmentation fault (11) [Fri May 04 18:23:31 2012] [notice] child pid 27659 exit signal Segmentation fault (11) [Fri May 04 19:15:25 2012] [notice] child pid 27830 exit signal Segmentation fault (11) [Fri May 04 19:15:34 2012] [notice] child pid 27832 exit signal Segmentation fault (11) [Fri May 04 19:17:53 2012] [notice] child pid 26396 exit signal Segmentation fault (11) [Fri May 04 20:17:11 2012] [notice] child pid 28059 exit signal Segmentation fault (11) Those look more like apache crashes, I presume... PHP may have been the root cause, however, if something is scrambling RAM. 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=61947 -- Edit this bug report at https://bugs.php.net/bug.php?id=61947&edit=1
Bug #61947 [Fbk]: curl Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61947&edit=1 ID: 61947 Updated by: ras...@php.net Reported by:ly...@php.net Summary:curl Segmentation fault Status: Feedback Type: Bug Package:cURL related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The PHP version is less important than the libcurl version on this one. Previous Comments: [2012-05-07 16:03:19] ly...@php.net I have reproduced this on an RHEL5.7 box with PHP 5.3.3 Still not supported, but getting closer... [2012-05-05 15:28:01] ras...@php.net There were known libcurl+curl_multi crashes in curl 7.15-7.19. See bug #47773 [2012-05-05 11:16:58] paj...@php.net Please do it already, the shorter script we get, the easier it will be to work on a fix. [2012-05-05 11:12:57] ly...@php.net If it helps, I now have a script that crashes every time, with a similar backtrace. Not a short script, mind you, but the libcurl bits aren't all that long either. If I hear back from somebody that wants to look at it, I'll strip out the non-curl parts, see if it crashes, and put here. Might just do that anyway, since I'm kind of stalled right now... [2012-05-05 05:39:24] ly...@php.net It is definitely the second one, with the POST that is crashing. Repeatable. 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=61947 -- Edit this bug report at https://bugs.php.net/bug.php?id=61947&edit=1
Bug #61947 [Com]: curl Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61947&edit=1 ID: 61947 Comment by: ly...@php.net Reported by:ly...@php.net Summary:curl Segmentation fault Status: Feedback Type: Bug Package:cURL related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Short test script, for what its' worth: http://www.6112northwolcott.com/curl_bug/test.phps libcurl is 7.15.5 on both boxes. I'll close this out. SORRY! I did search, but missed the other bug somehow. Previous Comments: [2012-05-07 16:05:04] ras...@php.net The PHP version is less important than the libcurl version on this one. [2012-05-07 16:03:19] ly...@php.net I have reproduced this on an RHEL5.7 box with PHP 5.3.3 Still not supported, but getting closer... [2012-05-05 15:28:01] ras...@php.net There were known libcurl+curl_multi crashes in curl 7.15-7.19. See bug #47773 [2012-05-05 11:16:58] paj...@php.net Please do it already, the shorter script we get, the easier it will be to work on a fix. [2012-05-05 11:12:57] ly...@php.net If it helps, I now have a script that crashes every time, with a similar backtrace. Not a short script, mind you, but the libcurl bits aren't all that long either. If I hear back from somebody that wants to look at it, I'll strip out the non-curl parts, see if it crashes, and put here. Might just do that anyway, since I'm kind of stalled right now... 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=61947 -- Edit this bug report at https://bugs.php.net/bug.php?id=61947&edit=1
Bug #61947 [Fbk->Csd]: curl Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61947&edit=1 ID: 61947 User updated by:ly...@php.net Reported by:ly...@php.net Summary:curl Segmentation fault -Status: Feedback +Status: Closed Type: Bug Package:cURL related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: libcurl 7.15.5 known non-php issue https://bugs.php.net/bug.php?id=47773 Previous Comments: [2012-05-07 16:06:59] ly...@php.net Short test script, for what its' worth: http://www.6112northwolcott.com/curl_bug/test.phps libcurl is 7.15.5 on both boxes. I'll close this out. SORRY! I did search, but missed the other bug somehow. [2012-05-07 16:05:04] ras...@php.net The PHP version is less important than the libcurl version on this one. [2012-05-07 16:03:19] ly...@php.net I have reproduced this on an RHEL5.7 box with PHP 5.3.3 Still not supported, but getting closer... [2012-05-05 15:28:01] ras...@php.net There were known libcurl+curl_multi crashes in curl 7.15-7.19. See bug #47773 [2012-05-05 11:16:58] paj...@php.net Please do it already, the shorter script we get, the easier it will be to work on a fix. 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=61947 -- Edit this bug report at https://bugs.php.net/bug.php?id=61947&edit=1
Bug #61704 [Opn->Asn]: Crash apache
Edit report at https://bugs.php.net/bug.php?id=61704&edit=1 ID: 61704 Updated by: johan...@php.net Reported by:ricardo dot nuno dot rodrigues at hotmail dot com Summary:Crash apache -Status: Open +Status: Assigned Type: Bug Package:MySQLi related Operating System: Windows 7 64bit PHP Version:5.4.0 -Assigned To: +Assigned To:mysql Block user comment: N Private report: N New Comment: This comes from using zend_hash_apply() on the plugin table on multiple threads. A fix using a mutex is on http://schlueters.de/~johannes/php/bug61704.diff I'll switch to manual iteration however so the lock isn't needed. Previous Comments: [2012-05-04 23:46:20] ricardo dot nuno dot rodrigues at hotmail dot com change to MySQL [2012-04-28 08:44:05] ricardo dot nuno dot rodrigues at hotmail dot com Update -- PHP 5.4.1 stills Update -- without ANY extension stills Update - mysqlnd I made another test: 1) no extensions 2) run a large number ab -n 1 -c 20 http://127.0.0.1/phpinfo.php 3) run on the browser on SAME TIME to see what happens Output (interesting part & repeated to see if happen on the same point and it does & results not change with ALL other extensions loaded): mysqlnd Fatal error: Nesting level too deep - recursive dependency? in C:\\phpinfo.php on line 3 mysqlnd enabled Version mysqlnd 5.0.10 - 20111026 - $Id: b0b3b15c693b7f6aeb3aa66b646fee339f175e39 $ Compression supported SSL supported Command buffer size 8192 Read buffer size32768 Read timeout31536000 Collecting statistics No Collecting memory statisticsNo Tracing 0 [2012-04-26 14:43:26] ricardo dot nuno dot rodrigues at hotmail dot com xdebug excluded as mentioned earlier the error doesn't change with or without xdebug [2012-04-26 05:31:20] paj...@php.net @drueter at assyst dot com it is not related to this discussion. Stas explanation is correct. Also it does not seem that your issue is related to this one. Please open a new one if necessary. [2012-04-26 05:29:54] paj...@php.net @ricardo dot nuno dot rodrigues at hotmail dot com Please disable xdebug and try again. 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=61704 -- Edit this bug report at https://bugs.php.net/bug.php?id=61704&edit=1
[PHP-BUG] Bug #61968 [NEW]: Crash in certain script using GD in Moodle
From: Operating system: Windows 7 x86 PHP version: 5.4.2 Package: GD related Bug Type: Bug Bug description:Crash in certain script using GD in Moodle Description: PHP 5.4.1 and 5.4.2 crashes at a page of learning management system Moodle (http://moodle.org/) drawing a graph using GD. 1. Install Moodle. 2. Log in as admin and create at least one student user. 3. Create a course. 4. Enter edit mode and add a quiz to the course. 5. Log in as a student user, take the quiz just created. 6. Log in as admin, see the quiz report. Page URL is /mod/quiz/report.php?id=&mode=overview. Embedded graph image is rendered by /mod/quiz/report/overview/overviewgraph.php?id=. PHP 5.3.8 didn't have this issue. My environment: OS: Windows 7 x86 Home Premium Server package: XAMPP 1.7.7 (Apache 2.2.21, MySQL 5.5.16) PHP: replaced original 5.3.8 with 5.4.1 and 5.4.2 PHP extensions: php_gd2.dll, php_mysqli.dll Moodle: any of 1.9.14, 2.0.8, 2.2.2 Test script: --- Tried to reproduce by separating concerning library files only and copied the object properties by var_export but didn't reproduce (graph is displayed without crash). Actual result: -- php5ts.dll stops with APPCRASH c005. Access to both report page and graph only causes crash. Weirdly if I add "exit();" at the end of the script overviewgraph.php, it doesn't crash. Callgraph shown when debugging with Visual Studio: (è¡=line, ãã¤ã=byte) > php5ts.dll!zval_mark_grey(_zval_struct * pz, void * * * tsrm_ls) è¡ 425 C php5ts.dll!gc_mark_roots(void * * * tsrm_ls) è¡ 501 + 0x7 ãã¤ã C php5ts.dll!gc_collect_cycles(void * * * tsrm_ls) + 0x15c1a1 ãã¤ã C php5ts.dll!zend_deactivate(void * * * tsrm_ls) è¡ 944 + 0x6 ãã¤ã C php5ts.dll!php_request_shutdown(void * dummy) è¡ 1784 C php5apache2_2.dll!php_handler(request_rec * r) è¡ 680 C libhttpd.dll!6ff02515() [ä¸ã®ãã¬ã¼ã ã¯ééã£ã¦ããããã¾ãã¯è¦ã¤ããã¾ãããlibhttpd.dll ã«å¯¾ãã¦èªã¿è¾¼ã¾ããã·ã³ãã«ã¯ããã¾ããã] libhttpd.dll!6ff0297c() libhttpd.dll!6ff0ff7c() libhttpd.dll!6ff0b092() libhttpd.dll!6ff05305() libhttpd.dll!6ff055d2() libhttpd.dll!6ff1ea89() msvcr90.dll!6ffb3433() msvcr90.dll!6ffb34c7() kernel32.dll!7655ed6c() ntdll.dll!778f377b() ntdll.dll!778f374e() -- Edit bug report at https://bugs.php.net/bug.php?id=61968&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61968&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61968&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61968&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61968&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61968&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61968&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61968&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61968&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61968&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61968&r=support Expected behavior: https://bugs.php.net/fix.php?id=61968&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61968&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61968&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61968&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61968&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61968&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61968&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61968&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61968&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61968&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61968&r=mysqlcfg
[PHP-BUG] Bug #61970 [NEW]: Restraining __constructor() access level in subclass gives a fatal error
From: Operating system: Linux PHP version: 5.3.12 Package: Class/Object related Bug Type: Bug Bug description:Restraining __constructor() access level in subclass gives a fatal error Description: Restraining the __construct() method un a subtype gives a Fatal error. As stated in the following resources, the LSP should not apply here. - https://bugs.php.net/bug.php?id=40880 - http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle - http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern Test script: --- PHP Fatal error: Access level to Bar::__construct() must be public (as in class Foo) in /tmp/bug.php on line 9 > Fatal error: Access level to Bar::__construct() must be public (as in class Foo) in /tmp/bug.php on line 9 -- Edit bug report at https://bugs.php.net/bug.php?id=61970&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61970&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61970&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61970&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61970&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61970&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61970&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61970&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61970&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61970&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61970&r=support Expected behavior: https://bugs.php.net/fix.php?id=61970&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61970&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61970&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61970&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61970&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61970&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61970&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61970&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61970&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61970&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61970&r=mysqlcfg
Bug #40880 [Com]: public->protected inheritance causes fatal
Edit report at https://bugs.php.net/bug.php?id=40880&edit=1 ID: 40880 Comment by: postmaster at greg0ire dot fr Reported by:prometheus__0 at hotmail dot com Summary:public->protected inheritance causes fatal Status: Not a bug Type: Bug Package:Class/Object related Operating System: SUSE SLES 10 PHP Version:5CVS-2007-03-21 (snap) Block user comment: N Private report: N New Comment: I filed a separate bug report here: https://bugs.php.net/bug.php?id=61970 so that this bug report does not get too cluttered. I agree that Singleton is not the best of the design patterns, but what if someone wants to use it anyway? And what if someone needs a protected / private constructor for some reason I cannot imagine? Previous Comments: [2012-05-07 13:26:35] ras...@php.net This bug report isn't about constructors specifically though. See the bug title and the opening points (1) and (2). The fact that __construct was used as an example seemed entirely coincidental here. For constructors specifically, I agree that Liskov can be mostly ignored, and we do so as you have discovered. The one case where we haven't is visibility. It seems a bit of an edge-case to tighten visibility on an inherited constructor and if that discourages the singleton pattern we might be doing the world a favour here. [2012-05-07 12:17:27] postmaster at greg0ire dot fr @pajoye : let me explain better what I tried to point out there: Rasmus says the Fatal error we're getting is here to enforce the LSP. What I'm saying here is that I'm not getting a signature-compatibility strict notice with the __construct() example , so obviously, the developer who wrote this notice thinks that LSP should not apply to __construct() (and I agree with him). This is just one more argument to convince Rasmus that the LSP does not apply here : obviously, even some member of the php team are aware of that. So to sum up the rules you are talking about, though "explained in the PHP manual", should not apply to __construct() (please read the references I gave in my previous comment to understand why). [2012-05-07 09:49:52] paj...@php.net @postmaster at greg0ire dot fr __construct applies only to the class where it is declared. On the other hand, a method, already defined in the parent class, must be as visible as the one declared in the parent class and with a compatible signature. The 2nd clause is not respected in your example as the 1st argument is not optional. It would work if it was optional, making $a->test() possible ass it is with the parent class. All these details are very explained in the PHP manual and other various OOP references out there. [2012-05-07 08:14:16] postmaster at greg0ire dot fr @rasmus: Then why is there a strict warning regarding the compatibility of method signatures for this code: -- class Foo { public function test() { } } class Bar extends Foo { public function test(ArrayObject $arrayObj, $number = 0) { /* do stuff with $arrayObj and $number */ } } --- and not for this one: --- class Foo { public function __construct() { } } class Bar extends Foo { public function __construct(ArrayObject $arrayObj, $number = 0) { /* do stuff with $arrayObj and $number */ } } No, as stated here : - http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle - and here: http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern, the LSP does not apply to constructors for several reasons: - When you call the constructor, you know whether you're using the type or one of its subtypes. - You can't apply the LSP to an object that does not exist yet. I think this is a design flaw. Not "massive", but a design flaw indeed. [2012-05-06 16:12:00] ras...@php.net Most (all?) object oriented languages work this way. Java and C# both do. You can loosen visibility when you override a parent method, but you can never tighten it. This is part of what is known as the Liskov Substitution Principle and it is one of the fundamental principles of object oriented programming. You can read about at http://en.wikipedia.org/wiki/Liskov_substitution_principle I can guarantee that abiding by LSP is not a bug The remainder of the comments for this report are too long. To view the rest of the comments, please
Bug #61970 [Opn]: Restraining __construct() access level in subclass gives a fatal error
Edit report at https://bugs.php.net/bug.php?id=61970&edit=1 ID: 61970 User updated by:postmaster at greg0ire dot fr Reported by:postmaster at greg0ire dot fr -Summary:Restraining __constructor() access level in subclass gives a fatal error +Summary:Restraining __construct() access level in subclass gives a fatal error Status: Open Type: Bug Package:Class/Object related Operating System: Linux PHP Version:5.3.12 Block user comment: N Private report: N New Comment: fixed the title Previous Comments: [2012-05-07 18:40:56] postmaster at greg0ire dot fr Description: Restraining the __construct() method un a subtype gives a Fatal error. As stated in the following resources, the LSP should not apply here. - https://bugs.php.net/bug.php?id=40880 - http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle - http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern Test script: --- PHP Fatal error: Access level to Bar::__construct() must be public (as in > class Foo) in /tmp/bug.php on line 9 > Fatal error: Access level to Bar::__construct() must be public (as in class > Foo) in /tmp/bug.php on line 9 -- Edit this bug report at https://bugs.php.net/bug.php?id=61970&edit=1
Bug #61951 [Com]: "make install" script fails when prefix dir is a symbolic link
Edit report at https://bugs.php.net/bug.php?id=61951&edit=1 ID: 61951 Comment by: stolen dot data dot net at gmail dot com Reported by:stolen dot data dot net at gmail dot com Summary:"make install" script fails when prefix dir is a symbolic link Status: Open Type: Bug Package:Compile Failure Operating System: Any PHP Version:5.4.2 Block user comment: N Private report: N New Comment: Specifically, the PHP Makefile fails when the destination of the symbolic link doesn't end with a trailing slash. This will cause the new Makefile to fail...: drwxr-xr-x 9 root wheel 512 May 7 21:21 php542 lrwxr-xr-x 1 root wheel7 May 7 21:10 php -> php542 ...but the Makefile bug doesn't manifest itself in this case: drwxr-xr-x 9 root wheel 512 May 7 21:21 php542 lrwxr-xr-x 1 root wheel7 May 7 21:10 php -> php542/ (Note the trailing slash at the end of the symbolic link destination...) Previous Comments: [2012-05-05 11:00:50] stolen dot data dot net at gmail dot com Description: I've been using a symbolic link scheme for the prefix destination dir of PHP/Apache/etc. software that I compile myself for over ten years now, to easily and quickly switch between releases in case of problems showing up when I move to a new version: # ls -l /usr/opt drwxr-xr-x 6 root wheel 512 Mar 20 2011 php536 drwxr-xr-x 6 root wheel 512 Dec 11 12:44 php538 drwxr-xr-x 16 root wheel 512 May 5 11:02 php542 lrwxr-xr-x 1 root wheel6 May 5 11:02 php -> php542 ... ./configure --prefix=/usr/opt/php --other-flags If something goes wrong, I just shut down the servers, change the symbolical link, restart... You get the idea... It is not a problem with any earlier version of PHP, but as of PHP 5.4.0 something changed in the "install" portion of the Makefile that breaks this handy practice: # make install Installing PHP CLI binary:/usr/opt/php/bin/ Installing PHP CLI man page: /usr/opt/php/php/man/man1/ mkdir: /usr/opt/php/php: File exists mkdir: /usr/opt/php/php/man: Too many levels of symbolic links mkdir: /usr/opt/php/php/man/man1: Too many levels of symbolic links *** Error code 1 Stop in /usr/opt/php-5.4.2 (line 243 of Makefile). And when I take a look at what the install script has been doing: # cd /usr/opt/php # ls -l total 4 drwxr-xr-x 2 root wheel 512 May 5 13:43 bin lrwxr-xr-x 1 root wheel3 May 5 11:02 php -> php For some reason, when the prefix dir is a symbolic link, the 5.4.x Makefile creates a symbolic link to itself inside the prefix dir. Note also that the timestamp of the symbolic is identical to the actual symbolic link I make for the prefix destination, as if the Makefile tries to copy the directory into itself. The problem is easily solved by entering the prefix dir, removing the broken link that the install script creates and just "mkdir php", then resuming "make install" again. This shouldn't be needed, obviously. The script shouldn't fail just because the prefix happens to be a symbolic link to an actual destination sitting in the same directory - there are no technical complications caused by this handy practice. -- Edit this bug report at https://bugs.php.net/bug.php?id=61951&edit=1
[PHP-BUG] Bug #61971 [NEW]: apply a function to an auto-referencia(preg_replace does) not produce an effect
From: Operating system: Linux Debian PHP version: 5.4Git-2012-05-07 (Git) Package: Output Control Bug Type: Bug Bug description:apply a function to an auto-referencia(preg_replace does) not produce an effect Description: when applies a function to a auto-reference (preg_replace), it not affect to the auto-referente Test script: --- /i', htmlentities('$1'), ''); ?> Expected result: Example Actual result: -- Example -- Edit bug report at https://bugs.php.net/bug.php?id=61971&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61971&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61971&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61971&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61971&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61971&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61971&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61971&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61971&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61971&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61971&r=support Expected behavior: https://bugs.php.net/fix.php?id=61971&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61971&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61971&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61971&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61971&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61971&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61971&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61971&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61971&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61971&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61971&r=mysqlcfg
[PHP-BUG] Req #61972 [NEW]: addchild treats text as a tag
From: Operating system: Windows XP PHP version: 5.4.2 Package: SimpleXML related Bug Type: Feature/Change Request Bug description:addchild treats text as a tag Description: --- >From manual page: http://www.php.net/simplexmlelement.addchild --- addChild treatsas a tag nd removes it completely -- Edit bug report at https://bugs.php.net/bug.php?id=61972&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61972&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61972&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61972&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61972&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61972&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61972&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61972&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61972&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61972&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61972&r=support Expected behavior: https://bugs.php.net/fix.php?id=61972&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61972&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61972&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61972&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61972&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61972&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61972&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61972&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61972&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61972&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61972&r=mysqlcfg
Bug #61746 [PATCH]: Failing tests in ext/standard/tests/file/windows_links/*
Edit report at https://bugs.php.net/bug.php?id=61746&edit=1 ID: 61746 Patch added by: mattfic...@php.net Reported by:a...@php.net Summary:Failing tests in ext/standard/tests/file/windows_links/* Status: Closed Type: Bug Package:*Directory/Filesystem functions Operating System: windows PHP Version:Irrelevant Assigned To:ab Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: 61746.patch.txt Revision: 1336427548 URL: https://bugs.php.net/patch-display.php?bug=61746&patch=61746.patch.txt&revision=1336427548 Previous Comments: [2012-04-23 10:24:38] a...@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. [2012-04-16 14:59:10] a...@php.net Description: The tests failing are: ext\standard\tests\file\windows_links\bug48746.phpt ext\standard\tests\file\windows_links\bug48746_1.phpt ext\standard\tests\file\windows_links\bug48746_2.phpt The reason is the mountvol not being in the path. Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61746&edit=1
Bug #61746 [Com]: Failing tests in ext/standard/tests/file/windows_links/*
Edit report at https://bugs.php.net/bug.php?id=61746&edit=1 ID: 61746 Comment by: mattfic...@php.net Reported by:a...@php.net Summary:Failing tests in ext/standard/tests/file/windows_links/* Status: Closed Type: Bug Package:*Directory/Filesystem functions Operating System: windows PHP Version:Irrelevant Assigned To:ab Block user comment: N Private report: N New Comment: The tests fail if %SYSTEMROOT% is not c:\windows. The newest patch fixes them. Previous Comments: [2012-05-07 21:52:28] mattfic...@php.net The following patch has been added/updated: Patch Name: 61746.patch.txt Revision: 1336427548 URL: https://bugs.php.net/patch-display.php?bug=61746&patch=61746.patch.txt&revision=1336427548 [2012-04-23 10:24:38] a...@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. [2012-04-16 14:59:10] a...@php.net Description: The tests failing are: ext\standard\tests\file\windows_links\bug48746.phpt ext\standard\tests\file\windows_links\bug48746_1.phpt ext\standard\tests\file\windows_links\bug48746_2.phpt The reason is the mountvol not being in the path. Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61746&edit=1
Bug #61971 [Opn->Nab]: apply a function to an auto-referencia(preg_replace does) not produce an effect
Edit report at https://bugs.php.net/bug.php?id=61971&edit=1 ID: 61971 Updated by: ni...@php.net Reported by:yoyahack at undersecurity dot net Summary:apply a function to an auto-referencia(preg_replace does) not produce an effect -Status: Open +Status: Not a bug Type: Bug Package:Output Control Operating System: Linux Debian PHP Version:5.4Git-2012-05-07 (Git) Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. The htmlentities() is executed before passing the result to preg_replace(). So in the end you just pass '$1' on. What you probably want to use is http://de3.php.net/manual/en/function.preg-replace-callback.php. Previous Comments: [2012-05-07 21:07:41] yoyahack at undersecurity dot net Description: when applies a function to a auto-reference (preg_replace), it not affect to the auto-referente Test script: --- /i', htmlentities('$1'), ''); ?> Expected result: Example Actual result: -- Example -- Edit this bug report at https://bugs.php.net/bug.php?id=61971&edit=1
Bug #61268 [Com]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d
Edit report at https://bugs.php.net/bug.php?id=61268&edit=1 ID: 61268 Comment by: mike at harschsystems dot com Reported by:mike at harschsystems dot com Summary:--enable-dtrace leads make to clobber Zend/zend_dtrace.d Status: Open Type: Bug Package:Compile Failure Operating System: solaris PHP Version:5.4.0 Block user comment: N Private report: N New Comment: I've seen the same failing behavior on 5.4.1 as well. It's worth noting that gmake exhibits this failure mode while regular (non-GNU) make works fine. So, the 2 workarounds are: 1.) run gmake with the '-r' option or 2.) run non-GNU make instead of gmake Previous Comments: [2012-04-22 13:13:01] alasdairrr at gmail dot com I can confirm I'm seeing this problem too on both Solaris 10 and SmartOS. [2012-03-03 20:19:39] mike at harschsystems dot com Description: 5.4.0 bundle configured with only one option: --enable-dtrace The configure script runs fine and the build finishes without error. However, the next invocation of make (probably from trying to run 'make install') fails with the following error: [jack@fjpe6maa ~/php-5.4.0]$ make install gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d Undefined first referenced symbol in file main/usr/lib/crt1.o php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute /home/jack/php-5.4.0/Zend/zend_dtrace.d.o php_request_shutdown/home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_throw_exception_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o $dtrace185178.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php- 5.4.0/Zend/zend_dtrace.d.o zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o ld: fatal: symbol referencing errors. No output written to /home/jack/php- 5.4.0/Zend/zend_dtrace.d collect2: ld returned 1 exit status make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1 What's happening here is that make has determined that the file Zend/zend_dtrace.d is out of date and must be rebuilt. It matches a built-in implicit rule that ends up running: gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d This command fails with the error that you see, but it also clobbers zend_dtrace.d Here's a bit more detail from 'make -d': Prerequisite `/home/jack/php-5.4.0/Zend/zend_dtrace.d.o' is newer than target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'. Must remake target `/home/jack/php-5.4.0/Zend/zend_dtrace.d'. Invoking builtin recipe to update target `/home/jack/php- 5.4.0/Zend/zend_dtrace.d'. gcc /home/jack/php-5.4.0/Zend/zend_dtrace.d.o -o /home/jack/php- 5.4.0/Zend/zend_dtrace.d Putting child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 on the chain. Live child 80bdaa0 (/home/jack/php-5.4.0/Zend/zend_dtrace.d) PID 5104 Undefined first referenced symbol in file main/usr/lib/crt1.o php_request_startup /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_execute /home/jack/php-5.4.0/Zend/zend_dtrace.d.o $dtrace187054.ZEND_CATCH_SPEC_CONST_CV_HANDLER /home/jack/php- 5.4.0/Zend/zend_dtrace.d.o php_request_shutdown/home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_throw_exception_internal /home/jack/php-5.4.0/Zend/zend_dtrace.d.o dtrace_compile_file /home/jack/php-5.4.0/Zend/zend_dtrace.d.o zend_error_noreturn /home/jack/php-5.4.0/Zend/zend_dtrace.d.o ld: fatal: symbol referencing errors. No output written to /home/jack/php- 5.4.0/Zend/zend_dtrace.d collect2: ld returned 1 exit status Reaping losing child 80bdaa0 PID 5104 make: *** [/home/jack/php-5.4.0/Zend/zend_dtrace.d] Error 1 I was able to work-around this issue by disabling built-in implicit rules with 'make -r'. Obviously, I had to recover the clobbered file before this worked. The offending Makefile may be seen here: http://harschsystems.com/bugs/php- 54_sol_dtrace/Makefile.txt For reference: On solaris (and solaris-derived) systems, the compilation of USDT dtrace probes goes something like this: $ dtrace -h -o foo_provider.h -s foo_provider.d >> Generates header file $ gcc -c foo_src.c $ dtrace -G -o foo_provider.o -s foo_provider.d