Bug #40880 [Com]: public->protected inheritance causes fatal

[postmaster at greg0ire dot fr]

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

[mrvanes at gmail dot com]

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

[maarten]

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

[pajoye]

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

[ni...@php.net]

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

[postmaster at greg0ire dot fr]

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

[rasmus]

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

[ab]

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

[ab]

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

[ly...@php.net]

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

[rasmus]

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

[ly...@php.net]

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

[ly...@php.net]

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

[johannes]

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

[k-yamashita at ver2 dot jp]

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

[postmaster at greg0ire dot fr]

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

[postmaster at greg0ire dot fr]

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

[postmaster at greg0ire dot fr]

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

[stolen dot data dot net at gmail dot com]

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

[yoyahack at undersecurity dot net]

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