Bug #60990 [Opn]: Segfault when trying to allocate more memory

[stas]

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

 ID: 60990
 Updated by: s...@php.net
 Reported by:flatline at hardwired dot hu
 Summary:Segfault when trying to allocate more memory
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   Debian Squeeze x86_64
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Full backtrace (or even better, a run under valgrind if it's reproduceable) 
would 
be helpful.
I'd also recommend trying without suhosin.so just to ensure the problem is not 
there (second trace still shows it loading). 
>From the trace it looks like the fault is in _zval_ptr_dtor which doesn't look 
like segfault as a result of allocator returning null - the argument is not 
null 
and _zval_ptr_dtor is not usually called right after allocator. Does it also 
crash if you set envt variable USE_ZEND_MM to 0 (that turns off Zend MM)?


Previous Comments:

[2012-02-06 18:05:12] flatline at hardwired dot hu

When I remove the suhosin.so extension it still segfaults. I don't know what 
you mean under "Do you have NO PHP code running on the system?". It's a quite 
complex script, but I can reproduce the problem each and every time. If I'm not 
mistaken when Zend tries to allocate some more memory and it bumps into the 
memory_limit parameter, it blindly uses the resulting (NULL) pointer, so that 
causes this segfault.


Here is the new backtrace, without suhosin.so loaded, with the env parameter 
you suggested:

gdb /usr/sbin/php5-fpm ./core-fpm
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/sbin/php5-fpm...Reading symbols from 
/usr/lib/debug/usr/sbin/php5-fpm...done.
(no debugging symbols found)...done.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libonig.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libonig.so.2
Reading symbols from /usr/lib/libcrypto.so.0.9.8...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libcrypto.so.0.9.8
Reading symbols from /usr/lib/libssl.so.0.9.8...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libssl.so.0.9.8
Reading symbols from /usr/lib/libdb-4.8.so...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libdb-4.8.so
Reading symbols from /usr/lib/libqdbm.so.14...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libqdbm.so.14
Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libbz2.so.1.0
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/libkrb5support.so.0...(no debugging symbols 
found)...d

[PHP-BUG] Bug #60998 [NEW]: Apache crashes on 4096 bytes PHP scripts

[bug at weezo dot net]

From: 
Operating system: Win32
PHP version:  5.3.10
Package:  Apache2 related
Bug Type: Bug
Bug description:Apache crashes on 4096 bytes PHP scripts

Description:

Apache server systematically crashes when a 4096 bytes PHP script is called
(either directly or included by another PHP script). 

Bug is also present higher power of 2 file sizes.
Everything works fine with CLI.

Tested on Win XP & Win 7, with 3 different 32bytes apache/PHP env
(wampserver env, php 5.3.10 from php.net, self compiled PHP with
apachelounge apache version), and a 64bytes version of apache/PHP.

Test script:
---
Any 4096 bytes script.


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

Bug #60997 [Com]: getopt() parses optional values incorrectly

[carloschilazo at gmail dot com]

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

 ID: 60997
 Comment by: carloschilazo at gmail dot com
 Reported by:eric at wepay dot com
 Summary:getopt() parses optional values incorrectly
 Status: Open
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Linux CentOS
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Documentation also states: 

Note: Optional values do not accept " " (space) as a separator.


Previous Comments:

[2012-02-06 23:51:51] eric at wepay dot com

Description:

If a CLI argument is passed with leading whitespace, the value is not picked up 
by 
getopt() if specified as an optional value (with two colons). This is contrary 
to 
the documentation, which states, "Option values are the first argument after 
the 
string. It does not matter if a value has leading white space or not."

Test script:
---



$ ./test.php -v2 asdf   # behaves as expected
$ ./test.php -v=2 asdf  # behaves as expected
$ ./test.php -v 2 asdf  # problem case, shown in actual result


Expected result:

array(1) {
  ["v"]=>
  bool(false)
}
array(1) {
  ["v"]=>
  string(1) "2"
}
array(1) {
  ["v"]=>
  string(1) "2"
}


Actual result:
--
array(1) {
  ["v"]=>
  bool(false)
}
array(1) {
  ["v"]=>
  string(1) "2"
}
array(1) {
  ["v"]=>
  bool(false)
}







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

Req #60996 [Opn->Wfx]: Slash agnostic basename()

[aharvey]

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

 ID: 60996
 Updated by: ahar...@php.net
 Reported by:bob at opsat dot net
 Summary:Slash agnostic basename()
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   Any
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Windows also allows / as a directory separator, which is why basename() 
supports 
both separators on that platform. Given that it's easy enough to write a 
function 
in PHP that calls explode() using \ as a delimiter and accesses the last value 
in 
the array, and namespaces _aren't_ the filesystem, extending basename() doesn't 
make much sense.


Previous Comments:

[2012-02-06 21:48:23] bob at opsat dot net

Description:

On Windows, basename() works with \ or /. On Unix platforms it only works with 
/.  
Since / is technically wrong on Windows, it should let you be technically wrong 
on  
Unix using \. Why? I noticed this while working on a custom autoloader. I was 
trying to basename('namespace\class') and was getting back 'namespace\class' on 
Unix but only getting 'class' on Windows, and 'class' was the expected output.

Since namespaces use a pseudo-filesystem structure I believe basename() (and 
probably dirname()) should be allowed to work properly on them regardless of 
the 
OS.

"But you are't dealing with files so this is dumb" - when it comes to 
autoloading, 
namespaces and classes are dealing with files... so.

Test script:
---


Expected result:

'ftw'

Actual result:
--
'bob\ftw' on unix.






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

Req #60024 [Dup]: Do not keep last element treated by foreach referenced

[chealer at gmail dot com]

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

 ID: 60024
 User updated by:chealer at gmail dot com
 Reported by:chealer at gmail dot com
 Summary:Do not keep last element treated by foreach
 referenced
 Status: Duplicate
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

Thank you. I read the discussion once, but I didn't see where it rejects this. 
Could the rejections be quoted or pointed more specifically?


Previous Comments:

[2012-02-07 00:10:38] ahar...@php.net

Sure, it's come up on the mailing list a few times, but the one I was thinking 
of 
specifically is: http://comments.gmane.org/gmane.comp.php.devel/59471


[2012-02-06 22:24:17] chealer at gmail dot com

Could the discussion be linked to?

This is not a duplicate of any of the reports indicated. The reports indicated 
are reports of application bugs as PHP bugs, which are therefore invalid. This 
report is asking to change PHP, in order to avoid such application bugs.


[2012-02-06 00:53:13] ahar...@php.net

This has previously been discussed and rejected, due to users relying both on 
PHP's lack of block scope and foreach's by-reference syntax. (Sometimes both at 
once, unfortunately.)

Duplicate of bug #29992, bug #47388, bug #54189, bug #50485, and probably a 
bunch 
of others.


[2012-02-06 00:47:50] DeveloperGuy2008 at yahoo dot com

Please fix this. It creates a lot of hard to debug bugs.


[2011-10-09 21:09:19] chealer at gmail dot com

Description:

As explained on http://ca.php.net/manual/en/control-structures.foreach.php :

Warning

Reference of a $value and the last array element remain even after the foreach 
loop. It is recommended to destroy it by unset().


In my opinion, PHP shouldn't keep the last element referenced by default, but 
at least, please provide a syntax which will not keep it. The current 
situations causes bugs like https://bugs.php.net/bug.php?id=49386







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

Req #60024 [Dup]: Do not keep last element treated by foreach referenced

[aharvey]

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

 ID: 60024
 Updated by: ahar...@php.net
 Reported by:chealer at gmail dot com
 Summary:Do not keep last element treated by foreach
 referenced
 Status: Duplicate
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

Sure, it's come up on the mailing list a few times, but the one I was thinking 
of 
specifically is: http://comments.gmane.org/gmane.comp.php.devel/59471


Previous Comments:

[2012-02-06 22:24:17] chealer at gmail dot com

Could the discussion be linked to?

This is not a duplicate of any of the reports indicated. The reports indicated 
are reports of application bugs as PHP bugs, which are therefore invalid. This 
report is asking to change PHP, in order to avoid such application bugs.


[2012-02-06 00:53:13] ahar...@php.net

This has previously been discussed and rejected, due to users relying both on 
PHP's lack of block scope and foreach's by-reference syntax. (Sometimes both at 
once, unfortunately.)

Duplicate of bug #29992, bug #47388, bug #54189, bug #50485, and probably a 
bunch 
of others.


[2012-02-06 00:47:50] DeveloperGuy2008 at yahoo dot com

Please fix this. It creates a lot of hard to debug bugs.


[2011-10-09 21:09:19] chealer at gmail dot com

Description:

As explained on http://ca.php.net/manual/en/control-structures.foreach.php :

Warning

Reference of a $value and the last array element remain even after the foreach 
loop. It is recommended to destroy it by unset().


In my opinion, PHP shouldn't keep the last element referenced by default, but 
at least, please provide a syntax which will not keep it. The current 
situations causes bugs like https://bugs.php.net/bug.php?id=49386







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

[PHP-BUG] Bug #60997 [NEW]: getopt() parses optional values incorrectly

[eric at wepay dot com]

From: 
Operating system: Linux CentOS
PHP version:  5.3.10
Package:  CGI/CLI related
Bug Type: Bug
Bug description:getopt() parses optional values incorrectly

Description:

If a CLI argument is passed with leading whitespace, the value is not
picked up by 
getopt() if specified as an optional value (with two colons). This is
contrary to 
the documentation, which states, "Option values are the first argument
after the 
string. It does not matter if a value has leading white space or not."

Test script:
---



$ ./test.php -v2 asdf   # behaves as expected
$ ./test.php -v=2 asdf  # behaves as expected
$ ./test.php -v 2 asdf  # problem case, shown in actual result


Expected result:

array(1) {
  ["v"]=>
  bool(false)
}
array(1) {
  ["v"]=>
  string(1) "2"
}
array(1) {
  ["v"]=>
  string(1) "2"
}


Actual result:
--
array(1) {
  ["v"]=>
  bool(false)
}
array(1) {
  ["v"]=>
  string(1) "2"
}
array(1) {
  ["v"]=>
  bool(false)
}


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

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

[glen at delfi dot ee]

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

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

 New Comment:

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

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


Previous Comments:

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

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


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

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


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

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

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


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

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

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


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

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




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

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


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

Bug #60993 [Asn]: php_intl.dll is missing from the non-thread safe Windows version

[szarkos]

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

 ID: 60993
 Updated by: szar...@php.net
 Reported by:yoozer at gmail dot com
 Summary:php_intl.dll is missing from the non-thread safe
 Windows version
 Status: Assigned
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.0RC7
 Assigned To:szarkos
 Block user comment: N
 Private report: N

 New Comment:

Hello,
Thank you for the bug report.  I have fixed the build issue and pushed a new 
build that includes the missing extension.  Please take a look and let me know 
if you run into any other issues.

Thanks!


Previous Comments:

[2012-02-06 14:10:46] paj...@php.net

Steve, pls take a look at this one too


[2012-02-06 14:01:45] yoozer at gmail dot com

Description:

The php_intl.dll file is missing from the Windows (non-thread safe) version. It 
is however included in the thread-safe version. 







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

Bug #55056 [Asn]: missing php_gd2.dll in windows.php.net builds

[szarkos]

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

 ID: 55056
 Updated by: szar...@php.net
 Reported by:giorgio dot liscio at email dot it
 Summary:missing php_gd2.dll in windows.php.net builds
 Status: Assigned
 Type:   Bug
 Package:*General Issues
 Operating System:   windows
 PHP Version:5.4.0RC7
 Assigned To:szarkos
 Block user comment: N
 Private report: N

 New Comment:

Thank you for the bug report.  I have fixed the build issue and pushed a new 
build that includes php_gd2.dll.  Please take a look and let me know if you run 
into any other issues.

Thanks!


Previous Comments:

[2012-02-04 07:43:47] paj...@php.net

Steve, please check why it was not in the release and re upload a new RC7 build 
with it.


[2012-02-03 23:03:48] vr...@php.net

But it is present in php-5.4-nts-windows-vc9-x86-r323040.zip again. Just please 
make sure that it will be in a final version :-).


[2012-02-03 22:55:00] vr...@php.net

The file is missing in php-5.4.0RC7-nts-Win32-VC9-x86.zip.


[2011-06-28 18:59:54] paj...@php.net

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

Fixed, there was a bug in the scripts. Snaps and alpha1 should have the missing 
exts now.


[2011-06-28 17:37:31] giorgio dot liscio at email dot it

Description:

hi, php_gd2.dll is missing in the windows snaps of 5.4 and trunk (vc9 ts)

http://windows.php.net/downloads/snaps/php-5.4/

if you download any of this you will not find the php_gd2.dll

thanks in advance







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

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

[tyr...@php.net]

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

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

 New Comment:

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


Previous Comments:

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

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


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

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

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


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

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

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


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

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


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

any interest of getting it fixed?

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




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

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


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

Req #60024 [Dup]: Do not keep last element treated by foreach referenced

[chealer at gmail dot com]

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

 ID: 60024
 User updated by:chealer at gmail dot com
 Reported by:chealer at gmail dot com
 Summary:Do not keep last element treated by foreach
 referenced
 Status: Duplicate
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

Could the discussion be linked to?

This is not a duplicate of any of the reports indicated. The reports indicated 
are reports of application bugs as PHP bugs, which are therefore invalid. This 
report is asking to change PHP, in order to avoid such application bugs.


Previous Comments:

[2012-02-06 00:53:13] ahar...@php.net

This has previously been discussed and rejected, due to users relying both on 
PHP's lack of block scope and foreach's by-reference syntax. (Sometimes both at 
once, unfortunately.)

Duplicate of bug #29992, bug #47388, bug #54189, bug #50485, and probably a 
bunch 
of others.


[2012-02-06 00:47:50] DeveloperGuy2008 at yahoo dot com

Please fix this. It creates a lot of hard to debug bugs.


[2011-10-09 21:09:19] chealer at gmail dot com

Description:

As explained on http://ca.php.net/manual/en/control-structures.foreach.php :

Warning

Reference of a $value and the last array element remain even after the foreach 
loop. It is recommended to destroy it by unset().


In my opinion, PHP shouldn't keep the last element referenced by default, but 
at least, please provide a syntax which will not keep it. The current 
situations causes bugs like https://bugs.php.net/bug.php?id=49386







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

[PHP-BUG] Req #60996 [NEW]: Slash agnostic basename()

[bob at opsat dot net]

From: 
Operating system: Any
PHP version:  5.3.10
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:Slash agnostic basename()

Description:

On Windows, basename() works with \ or /. On Unix platforms it only works
with /.  
Since / is technically wrong on Windows, it should let you be technically
wrong on  
Unix using \. Why? I noticed this while working on a custom autoloader. I
was 
trying to basename('namespace\class') and was getting back
'namespace\class' on 
Unix but only getting 'class' on Windows, and 'class' was the expected
output.

Since namespaces use a pseudo-filesystem structure I believe basename()
(and 
probably dirname()) should be allowed to work properly on them regardless
of the 
OS.

"But you are't dealing with files so this is dumb" - when it comes to
autoloading, 
namespaces and classes are dealing with files... so.

Test script:
---


Expected result:

'ftw'

Actual result:
--
'bob\ftw' on unix.

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

Bug #51184 [Com]: DateInterval has incorrect days property on windows

[asdf at asdf dot com]

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

 ID: 51184
 Comment by: asdf at asdf dot com
 Reported by:s...@php.net
 Summary:DateInterval has incorrect days property on windows
 Status: Wont fix
 Type:   Bug
 Package:Date/time related
 Operating System:   Windows
 PHP Version:5.3.2
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Your function can be changed to accept Datetime Objects for Strings this way. 
Also now calculates datetime difference from dt1 to dt2 rather then the other 
way around.

private function daysdiff($dt1, $dt2, $timeZone = 'America/Chicago') 
{
  $tZone = new DateTimeZone($timeZone);
  
  if(is_string($dt1))
  {
$dt1 = new DateTime($dt1, $tZone);
  }
  if(is_string($dt2))
  {
$dt2 = new DateTime($dt2, $tZone);  
  }
  
  // use the DateTime datediff function IF we have a non-buggy version
  // there is a bug in many Windows implementations that diff() always 
returns 6015  
  if( $dt1->diff($dt1)->format("%a") != 6015 ) {
return $dt1->diff($dt2)->format("%a");
  }
  
  // else let's use our own method
  $y1 = $dt1->format('Y');  
  $y2 = $dt2->format('Y');
  $z1 = $dt1->format('z');
  $z2 = $dt2->format('z');
  
  $diff = intval($y2 * 365.2425 + $z2) - intval($y1 * 365.2425 + $z1);
  return $diff;
}


Previous Comments:

[2012-02-06 21:25:02] asdf at asdf dot com

Also have this problem. A full year since last modified. No fixes yet? 

I agree with the other use who said there should be more documentation on this 
error. I am sure lots of us spent lots of time before we found this thread 
trying to figure out why diff() does not output the correct result.

Right here would be a great place to put some documentation on the 6015 error: 
http://us3.php.net/manual/en/datetime.diff.php


[2012-01-29 05:38:54] alabi10 at yahoo dot com

The fix submitted by fbast...@yahoo.com on 2011-10-16 16:13 UTC solved the 
problem 
for me on Windows 7 running WAMP on localhost and php 5.3.0


[2011-11-12 15:08:05] iskeen at barebrush dot com

I am surprised that the number of days between two dates problem is not made 
clear right up front in the documentation. It took me 3 hours to find this page 
and I was trying all different things to make it work. I suspected a problem 
when the three different sets of dates I was using all came out with the same 
answer, but when I finally used %a and they all came out with 6015, I knew, 
finally, that there is a problem. The fact of the problem should be made very 
clear right up front.


[2011-10-16 16:13:05] fbastage at yahoo dot com

Here's a reasonably close substitute  (run result through abs() if you don't 
want potentially negative numbers):

// $dt1 and $dt2 can be any valid date string that DateTime accepts
// the time zone shouldn't affect anything (since $dt1 and $dt2 use same zone),
// but you can override the default
function daysdiff($dt1, $dt2, $timeZone = 'America/Chicago') {
  $tZone = new DateTimeZone($timeZone);
  
  $dt1 = new DateTime($dt1, $tZone);
  $dt2 = new DateTime($dt2, $tZone);  
  
  // use the DateTime datediff function IF we have a non-buggy version
  // there is a bug in many Windows implementations that diff() always returns
  // 6015  
  if( $dt1->diff($dt1)->format("%a") != 6015 ) {
return $dt1->diff($dt2)->format("%a");
  }
  
  // else let's use our own method

  $y1 = $dt1->format('Y');  
  $y2 = $dt2->format('Y');
  $z1 = $dt1->format('z');
  $z2 = $dt2->format('z');
  
  $diff = intval($y1 * 365.2425 + $z1) - intval($y2 * 365.2425 + $z2);

  return $diff;

}


[2011-09-05 18:06:18] a at a dot com

Not solved with 5.3.5 on Windows.




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


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

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

[sixd]

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

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

 New Comment:

Try adding E to php.ini's variables_order.


Previous Comments:

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

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

Problem is no shell environment is reaching the test scripts.

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


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

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

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

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


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

Description:

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

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

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

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

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

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

So MYSQL_TEST_PASSWD is ignored.







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

Bug #51184 [Com]: DateInterval has incorrect days property on windows

[asdf at asdf dot com]

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

 ID: 51184
 Comment by: asdf at asdf dot com
 Reported by:s...@php.net
 Summary:DateInterval has incorrect days property on windows
 Status: Wont fix
 Type:   Bug
 Package:Date/time related
 Operating System:   Windows
 PHP Version:5.3.2
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Also have this problem. A full year since last modified. No fixes yet? 

I agree with the other use who said there should be more documentation on this 
error. I am sure lots of us spent lots of time before we found this thread 
trying to figure out why diff() does not output the correct result.

Right here would be a great place to put some documentation on the 6015 error: 
http://us3.php.net/manual/en/datetime.diff.php


Previous Comments:

[2012-01-29 05:38:54] alabi10 at yahoo dot com

The fix submitted by fbast...@yahoo.com on 2011-10-16 16:13 UTC solved the 
problem 
for me on Windows 7 running WAMP on localhost and php 5.3.0


[2011-11-12 15:08:05] iskeen at barebrush dot com

I am surprised that the number of days between two dates problem is not made 
clear right up front in the documentation. It took me 3 hours to find this page 
and I was trying all different things to make it work. I suspected a problem 
when the three different sets of dates I was using all came out with the same 
answer, but when I finally used %a and they all came out with 6015, I knew, 
finally, that there is a problem. The fact of the problem should be made very 
clear right up front.


[2011-10-16 16:13:05] fbastage at yahoo dot com

Here's a reasonably close substitute  (run result through abs() if you don't 
want potentially negative numbers):

// $dt1 and $dt2 can be any valid date string that DateTime accepts
// the time zone shouldn't affect anything (since $dt1 and $dt2 use same zone),
// but you can override the default
function daysdiff($dt1, $dt2, $timeZone = 'America/Chicago') {
  $tZone = new DateTimeZone($timeZone);
  
  $dt1 = new DateTime($dt1, $tZone);
  $dt2 = new DateTime($dt2, $tZone);  
  
  // use the DateTime datediff function IF we have a non-buggy version
  // there is a bug in many Windows implementations that diff() always returns
  // 6015  
  if( $dt1->diff($dt1)->format("%a") != 6015 ) {
return $dt1->diff($dt2)->format("%a");
  }
  
  // else let's use our own method

  $y1 = $dt1->format('Y');  
  $y2 = $dt2->format('Y');
  $z1 = $dt1->format('z');
  $z2 = $dt2->format('z');
  
  $diff = intval($y1 * 365.2425 + $z1) - intval($y2 * 365.2425 + $z2);

  return $diff;

}


[2011-09-05 18:06:18] a at a dot com

Not solved with 5.3.5 on Windows.


[2011-07-04 10:55:22] tux at penguinfriends dot org

Not solved with 5.3.5 on Windows...




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


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

Bug #60981 [Fbk->Asn]: Shell environment inaccessible in tests

[david at davidfavor dot com]

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

 ID: 60981
 User updated by:david at davidfavor dot com
 Reported by:david at davidfavor dot com
 Summary:Shell environment inaccessible in tests
-Status: Feedback
+Status: Assigned
 Type:   Bug
 Package:Testing related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.10
 Assigned To:danielc
 Block user comment: N
 Private report: N

 New Comment:

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

Problem is no shell environment is reaching the test scripts.

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


Previous Comments:

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

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

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

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


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

Description:

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

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

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

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

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

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

So MYSQL_TEST_PASSWD is ignored.







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

Bug #60986 [Ctl->Csd]: pcre_get_compiled_regex_cache: php_pcre.c: undefined reference to 'pcre_info'

[rasmus]

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

 ID: 60986
 Updated by: ras...@php.net
 Reported by:j0inty at stollfuss dot net
 Summary:pcre_get_compiled_regex_cache: php_pcre.c: undefined
 reference to 'pcre_info'
-Status: Critical
+Status: Closed
 Type:   Bug
 Package:PCRE related
 Operating System:   Linux
 PHP Version:5.4.0RC7
-Assigned To:
+Assigned To:rasmus
 Block user comment: N
 Private report: N

 New Comment:

Fix committed to 5.3/5.4/trunk and will be in the next releases.


Previous Comments:

[2012-02-06 18:18:48] ras...@php.net

Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&revision=323097
Log: Safer way to call pcre_fullinfo - bug 60986


[2012-02-06 18:11:51] ras...@php.net

Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&revision=323096
Log: Fix for bug 60986


[2012-02-06 18:01:32] olemarkus at gentoo dot org

Regarding the proposed patch, we were alerted about a possible null pointer 
dereference. See https://bugs.gentoo.org/show_bug.cgi?id=402357#c10


[2012-02-06 13:04:36] pierre at archlinux dot de

This also affects the 5.3 branch. The problem is the use of the pcre_info 
function which was deprecated and repalced by pcre_fullinfo 12 years ago. This 
function was now removed with pcre 8.30.

I only found one real use of it and some exports; I have attached a patch that 
might work. Note the I have no idea about php internals; so this might be 
entirely stupid or dangerous.

Also note that you might not be able to compile the apache module as apache 
itself seems also to be incompatible with pcre 8.30

Greetings,

Pierre


[2012-02-06 10:06:44] j0inty at stollfuss dot net

Description:

Hi,

If you try to compile the current RC7 of php 5.4.0 the Linker crash with the 
following message.

ext/pcre/php_pcre.o: In function `pcre_get_compiled_regex_cache':
php_pcre.c:(.text+0xb8f): undefined reference to `pcre_info'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Fehler 1

The reason is the new libpcre-8.30 which was today in my update list.

dev-libs/libpcre-8.30-r2

You can find a full build.log posted on http://paste.pocoo.org/show/546652/ .

regards
j0inty







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

Bug #60990 [Com]: Segfault when trying to allocate more memory

[flatline at hardwired dot hu]

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

 ID: 60990
 Comment by: flatline at hardwired dot hu
 Reported by:flatline at hardwired dot hu
 Summary:Segfault when trying to allocate more memory
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   Debian Squeeze x86_64
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

When I remove the suhosin.so extension it still segfaults. I don't know what 
you mean under "Do you have NO PHP code running on the system?". It's a quite 
complex script, but I can reproduce the problem each and every time. If I'm not 
mistaken when Zend tries to allocate some more memory and it bumps into the 
memory_limit parameter, it blindly uses the resulting (NULL) pointer, so that 
causes this segfault.


Here is the new backtrace, without suhosin.so loaded, with the env parameter 
you suggested:

gdb /usr/sbin/php5-fpm ./core-fpm
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/sbin/php5-fpm...Reading symbols from 
/usr/lib/debug/usr/sbin/php5-fpm...done.
(no debugging symbols found)...done.

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libonig.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libonig.so.2
Reading symbols from /usr/lib/libcrypto.so.0.9.8...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libcrypto.so.0.9.8
Reading symbols from /usr/lib/libssl.so.0.9.8...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libssl.so.0.9.8
Reading symbols from /usr/lib/libdb-4.8.so...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libdb-4.8.so
Reading symbols from /usr/lib/libqdbm.so.14...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libqdbm.so.14
Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libbz2.so.1.0
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/libkrb5support.so.0...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libkrb5support.so.0
Reading symbols from /lib/libkeyutils.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib/libkeyutils.so.1
Reading symbols from /usr/lib/php5/20090626/apc.so...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/php5/20090626/apc.so
Reading symbols from /usr/lib/php5/20090626/curl.so...Reading symbols from 
/usr/lib/debug/usr/lib/php5/20090626/curl.so...done.
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/php5/20090626/curl.so
Reading symbols from /usr/lib/libcurl.so.4...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libcurl.so.4
Reading sym

Bug #60986 [Com]: pcre_get_compiled_regex_cache: php_pcre.c: undefined reference to 'pcre_info'

[olemarkus at gentoo dot org]

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

 ID: 60986
 Comment by: olemarkus at gentoo dot org
 Reported by:j0inty at stollfuss dot net
 Summary:pcre_get_compiled_regex_cache: php_pcre.c: undefined
 reference to 'pcre_info'
 Status: Critical
 Type:   Bug
 Package:PCRE related
 Operating System:   Linux
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

Regarding the proposed patch, we were alerted about a possible null pointer 
dereference. See https://bugs.gentoo.org/show_bug.cgi?id=402357#c10


Previous Comments:

[2012-02-06 13:04:36] pierre at archlinux dot de

This also affects the 5.3 branch. The problem is the use of the pcre_info 
function which was deprecated and repalced by pcre_fullinfo 12 years ago. This 
function was now removed with pcre 8.30.

I only found one real use of it and some exports; I have attached a patch that 
might work. Note the I have no idea about php internals; so this might be 
entirely stupid or dangerous.

Also note that you might not be able to compile the apache module as apache 
itself seems also to be incompatible with pcre 8.30

Greetings,

Pierre


[2012-02-06 10:06:44] j0inty at stollfuss dot net

Description:

Hi,

If you try to compile the current RC7 of php 5.4.0 the Linker crash with the 
following message.

ext/pcre/php_pcre.o: In function `pcre_get_compiled_regex_cache':
php_pcre.c:(.text+0xb8f): undefined reference to `pcre_info'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Fehler 1

The reason is the new libpcre-8.30 which was today in my update list.

dev-libs/libpcre-8.30-r2

You can find a full build.log posted on http://paste.pocoo.org/show/546652/ .

regards
j0inty







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

Bug #60976 [Com]: PHP crashes sometimes while parsing

[giunta dot gaetano at gmail dot com]

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

 ID: 60976
 Comment by: giunta dot gaetano at gmail dot com
 Reported by:xrstf-misc at yahoo dot com
 Summary:PHP crashes sometimes while parsing
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Win7x64
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

I also have php crashes - win7 64, apache 2.2.21 from apache lounge.
No error messages left in either php or apache logs - just a "server reset 
connection" error from the browser.
The code ran fine up to php 5.3.8 (did not test with 539).
It involves executing a custom page within eZPublish, it is hard for me to 
trace it to a single php file / command and attach it here...


Previous Comments:

[2012-02-05 15:19:32] xrstf-misc at yahoo dot com

Here is the original file, wrapped in an 7z archive:
http://www.xrstf.de/bug60976.7z (1KB)


[2012-02-04 07:39:19] paj...@php.net

Ah you already did. Which EOL do you use on your original script? Unix or 
windows 
ones?

Maybe zip it and post a link to the zip file, so the contents won't be altered 
(lexer bug).


[2012-02-04 07:37:39] paj...@php.net

Please provide us the full script you use to reprodruce the crash.


[2012-02-04 01:20:16] xrstf-misc at yahoo dot com

Well this is the source file that caused the parse error: 
http://pastie.org/pastes/3312735/text (md5sum is 
1bd8de828db862a5f118be4cc9773999, there are not trailing spaces and there is a 
blank line at the end of the file).

I cannot give any shorter example. Sorry.


[2012-02-04 00:43:41] fel...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.






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


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

Bug #60983 [Com]: Memory is not properly freed

[DeveloperGuy2008 at yahoo dot com]

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

 ID: 60983
 Comment by: DeveloperGuy2008 at yahoo dot com
 Reported by:developerguy2008 at yahoo dot com
 Summary:Memory is not properly freed
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   all
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

Do you know any references where I may read about the object_store? Is there a 
to shrink it (like a compile time flag) when it is does not need to be large?

It seems like the ideal result would be to shrink the object store. In this 
example it is only a few megabytes but in other cases it could be several 
hundred megabytes that essentially lost forever (at least to other processes).


Previous Comments:

[2012-02-06 07:46:59] larue...@php.net

the reason for there is mem diff is that, the EG(objects_store) could only be 
grow  but could not be shrunk. 

if you tweak your test into:
$mem1 = memory_get_usage(true);
echo "MEM1: " . $mem1 . "\n";
class A {
public $class;
}

$c1 = $c2 = null;
for ($i = 0; $i < 2; $i++) {
$c1 = new A();
$c2 = new A();
$c1->class = array($c1, $c2);
$c2->class = array($c1, $c2);
   
gc_collect_cycles();

}
unset($c1); unset($c2);

$mem2 = memory_get_usage(true);
echo "MEM2: " . $mem2 . "\n";
echo "DIFF: " . ($mem2 - $mem1) . "\n";

you may understand my point


[2012-02-06 00:43:46] developerguy2008 at yahoo dot com

Description:

Memory is not being freed properly. In a short loop several megabytes are lost 
that should not be lost. Attached is a test script to demonstrate what I mean.

Test script:
---
$mem1 = memory_get_usage(true);
echo "MEM1: " . $mem1 . "\n";
class A {
public $class;
}

$c1 = $c2 = null;
for ($i = 0; $i < 2; $i++) {
$c1 = new A();
$c2 = new A();
$c1->class = array($c1, $c2);
$c2->class = array($c1, $c2);
}
unset($c1); unset($c2);

gc_collect_cycles();
$mem2 = memory_get_usage(true);
echo "MEM2: " . $mem2 . "\n";
echo "DIFF: " . ($mem2 - $mem1) . "\n";

Expected result:

I expect the memory difference to be 0. In this case it is several megabytes.

Actual result:
--
MEM1: 4980736
MEM2: 7340032
DIFF: 2359296

The DIFF should be 0.






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

Bug #60986 [Opn->Ctl]: pcre_get_compiled_regex_cache: php_pcre.c: undefined reference to 'pcre_info'

[rasmus]

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

 ID: 60986
 Updated by: ras...@php.net
 Reported by:j0inty at stollfuss dot net
 Summary:pcre_get_compiled_regex_cache: php_pcre.c: undefined
 reference to 'pcre_info'
-Status: Open
+Status: Critical
 Type:   Bug
 Package:PCRE related
 Operating System:   Linux
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N



Previous Comments:

[2012-02-06 13:04:36] pierre at archlinux dot de

This also affects the 5.3 branch. The problem is the use of the pcre_info 
function which was deprecated and repalced by pcre_fullinfo 12 years ago. This 
function was now removed with pcre 8.30.

I only found one real use of it and some exports; I have attached a patch that 
might work. Note the I have no idea about php internals; so this might be 
entirely stupid or dangerous.

Also note that you might not be able to compile the apache module as apache 
itself seems also to be incompatible with pcre 8.30

Greetings,

Pierre


[2012-02-06 10:06:44] j0inty at stollfuss dot net

Description:

Hi,

If you try to compile the current RC7 of php 5.4.0 the Linker crash with the 
following message.

ext/pcre/php_pcre.o: In function `pcre_get_compiled_regex_cache':
php_pcre.c:(.text+0xb8f): undefined reference to `pcre_info'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Fehler 1

The reason is the new libpcre-8.30 which was today in my update list.

dev-libs/libpcre-8.30-r2

You can find a full build.log posted on http://paste.pocoo.org/show/546652/ .

regards
j0inty







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

Bug #60994 [Opn]: PDO_OCI: Reading a multibyte CLOB caps at 8192 characters

[php dot net at boedah dot de]

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

 ID: 60994
 User updated by:php dot net at boedah dot de
 Reported by:php dot net at boedah dot de
 Summary:PDO_OCI: Reading a multibyte CLOB caps at 8192
 characters
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   OEL 5 / RHEL5 / Win7
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

adding the full code sample as patch did not work in the first place
-> attached it now


Previous Comments:

[2012-02-06 16:13:52] php dot net at boedah dot de

Description:

Inserting large multibyte strings works fine,
reading them back in results in only 8192 characters read (=24576 bytes).

Even if inserting mixed single-multibyte strings, reading caps at 8192 
characters (even though the byte count is far less).

Inserting and reading 10 single bytes work, though.

Attached a file with more debug output.

== PHP ==

We are using ZendServer 5.5.0:

PHP 5.3.8-ZS5.5.0 (cli) (built: Aug 23 2011 05:20:27)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

But this bug also is on PHP 5.4.0RC8-dev

== Oracle ==

Oracle XE 10.2.0.1, but also on Enterprise 10.2.0.4.0.
Characterset: AL32UTF8

Test table:

create table TEST_LOB (
tl_id NUMBER(3),
tl_byte_16VARCHAR2(16 BYTE),
tl_char_16VARCHAR2(16 CHAR),
tl_byte_4000  VARCHAR2(4000 BYTE),
tl_char_4000  VARCHAR2(4000 CHAR),
tl_blob   BLOB,
tl_clob   CLOB,
tl_date   DATE,
tl_number NUMBER
)


Test script:
---
$dsn = 'oci:dbname=(DESCRIPTION=(ADDRESS_LIST=(
ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))
(CONNECT_DATA=(SID=xe)));charset=AL32UTF8';
$username = 'USER';
$password = 'PW';
$lobTestTablename = 'TEST_LOB';
$id = -1;
$clobData = str_repeat('…', 8193);

$pdo = new PDO($dsn, $username, $password);
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo->exec("delete from $lobTestTablename where tl_id < 0");
$pdoStmt = $pdo->prepare("insert into $lobTestTablename (tl_id, tl_clob) values 
(?, ?)");
$pdoStmt->bindParam(1, $id, PDO::PARAM_INT, null, null);
$pdoStmt->bindParam(2, $clobData, PDO::PARAM_STR, strlen($clobData), null);
$pdoStmt->execute();
$pdoStmt = $pdo->query("select * from $lobTestTablename where TL_ID = $id");
$row = $pdoStmt->fetch(PDO::FETCH_ASSOC);
$dataRead = stream_get_contents($row['TL_CLOB']);
printf("values equal: %s\n", var_export($clobData === $dataRead, true));

Expected result:

values equal: false

Actual result:
--
values equal: true






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

[PHP-BUG] Bug #60994 [NEW]: PDO_OCI: Reading a multibyte CLOB caps at 8192 characters

[php dot net at boedah dot de]

From: 
Operating system: OEL 5 / RHEL5 / Win7
PHP version:  Irrelevant
Package:  PDO related
Bug Type: Bug
Bug description:PDO_OCI: Reading a multibyte CLOB caps at 8192 characters

Description:

Inserting large multibyte strings works fine,
reading them back in results in only 8192 characters read (=24576 bytes).

Even if inserting mixed single-multibyte strings, reading caps at 8192 
characters (even though the byte count is far less).

Inserting and reading 10 single bytes work, though.

Attached a file with more debug output.

== PHP ==

We are using ZendServer 5.5.0:

PHP 5.3.8-ZS5.5.0 (cli) (built: Aug 23 2011 05:20:27)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

But this bug also is on PHP 5.4.0RC8-dev

== Oracle ==

Oracle XE 10.2.0.1, but also on Enterprise 10.2.0.4.0.
Characterset: AL32UTF8

Test table:

create table TEST_LOB (
tl_id NUMBER(3),
tl_byte_16VARCHAR2(16 BYTE),
tl_char_16VARCHAR2(16 CHAR),
tl_byte_4000  VARCHAR2(4000 BYTE),
tl_char_4000  VARCHAR2(4000 CHAR),
tl_blob   BLOB,
tl_clob   CLOB,
tl_date   DATE,
tl_number NUMBER
)


Test script:
---
$dsn = 'oci:dbname=(DESCRIPTION=(ADDRESS_LIST=(
ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))
(CONNECT_DATA=(SID=xe)));charset=AL32UTF8';
$username = 'USER';
$password = 'PW';
$lobTestTablename = 'TEST_LOB';
$id = -1;
$clobData = str_repeat('…', 8193);

$pdo = new PDO($dsn, $username, $password);
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$pdo->exec("delete from $lobTestTablename where tl_id < 0");
$pdoStmt = $pdo->prepare("insert into $lobTestTablename (tl_id, tl_clob)
values (?, ?)");
$pdoStmt->bindParam(1, $id, PDO::PARAM_INT, null, null);
$pdoStmt->bindParam(2, $clobData, PDO::PARAM_STR, strlen($clobData),
null);
$pdoStmt->execute();
$pdoStmt = $pdo->query("select * from $lobTestTablename where TL_ID =
$id");
$row = $pdoStmt->fetch(PDO::FETCH_ASSOC);
$dataRead = stream_get_contents($row['TL_CLOB']);
printf("values equal: %s\n", var_export($clobData === $dataRead, true));

Expected result:

values equal: false

Actual result:
--
values equal: true

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

Bug #60704 [Fbk->Opn]: unlink() bug with some files path

[dean at dacunha dot net]

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

 ID: 60704
 User updated by:dean at dacunha dot net
 Reported by:dean at dacunha dot net
 Summary:unlink() bug with some files path
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Linux 3.0.0-14-generic #23-Ubunt
-PHP Version:5.3.8
+PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Hi,
I've just tested with php 5.3.10, the bug is still here.
Do you still need me to test with version 5.3.9 ?

Here is the proof:

root@djavanubu:/root#
root@djavanubu:/root# cat b.php
#!/usr/local/bin/php

root@djavanubu:/root#
root@djavanubu:/root# /usr/local/bin/php -v
PHP 5.3.10 (cli) (built: Jan 31 2012 22:48:16)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
root@djavanubu:/root#
root@djavanubu:/root#
root@djavanubu:/root# ./b.php

Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot 
List.mp3): No such file or directory in /root/b.php on line 7
root@djavanubu:/root#
root@djavanubu:/root# rm "/mnt/M:/NEWBASE/BRASIL/Carlinhos 
Brown/Alfagamabetizado - Angel's Robot List.1.2.mp3"
root@djavanubu:/root#
root@djavanubu:/root# strace ./b.php
[...]
lstat("/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot 
List.mp3", {st_mode=S_IFREG|0755, st_size=1247232, ...}) = 0
lstat("/mnt/M://BRASIL/Carlinhos Brown", {st_mode=S_IFDIR|0755, st_size=40960, 
...}) = 0
lstat("/mnt/M://BRASIL", {st_mode=S_IFDIR|0755, st_size=81920, ...}) = 0
link("/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot 
List.mp3", "/mnt/M:/NEWBASE/BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's 
Robot List.1.2.mp3") = 0
unlink("BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot List.mp3") = -1 
ENOENT (No such file or directory)
write(1, "\nWarning: unlink(BRASIL/Carlinho"..., 135
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot 
List.mp3): No such file or directory in /root/b.php on line 7
) = 135
[...]


Previous Comments:

[2012-01-27 05:42:04] carloschilazo at gmail dot com

Does this happen also in 5.3.9 ?

Please confirm so I can look into it

Thanks


[2012-01-10 19:58:07] dean at dacunha dot net

Description:

unlink() function truncates the file path name argument in some cases.

This bug appears also with the rename() function in the same cases.

The given source code use link() to duplicate a file, then unlink() to remove 
the 
source file. link() function works and unlink() bugs.

Test script:
---
#!/usr/local/bin/php



Expected result:

unlink() should remove the "/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - 
Angel's Robot List.mp3" file


Actual result:
--
root@djavanubu:/# ./b.php

Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot 
List.mp3): No such file or directory in /b.php on line 8

###
below trace shows the truncated file path given to unlink() syscall:
[...]
lstat("/mnt/M://BRASIL", {st_mode=S_IFDIR|0755, st_size=69632, ...}) = 0
link("/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot 
List.mp3", "/mnt/M:/NEWBASE/BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's 
Robot List.1.2.mp3") = 0
unlink("BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot List.mp3") = -1 
ENOENT (No such file or directory)
write(1, "\nWarning: unlink(BRASIL/Carlinho"..., 130
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot 
List.mp3): No such file or directory in /b.php on line 8
) = 130
[...]






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

Bug #60990 [Com]: Segfault when trying to allocate more memory

[stefan at nopiracy dot de]

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

 ID: 60990
 Comment by: stefan at nopiracy dot de
 Reported by:flatline at hardwired dot hu
 Summary:Segfault when trying to allocate more memory
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   Debian Squeeze x86_64
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Because you are running Suhosin you will most probably get no help here.

Anyway to increase your chances try the following:

restart PHP with the environment variable
SUHOSIN_MM_USE_CANARY_PROTECTION=0

If you do this then PHP will no longer use the memory allocator with carnaries, 
but use the normal one which is nearly identical to the vanilla one.

Check if that gives you a similar backtrace.

The code is obviously crashing while shutting down the system.
There is a NULL pointer dereference.

And the code triggering this is:
zend_hash_graceful_reverse_destroy(&EG(symbol_table));

This means something is corrupt in the symbol_table.

Do you have NO PHP code running on the system? Or does it crash always? Or...?


Previous Comments:

[2012-02-06 13:15:14] flatline at hardwired dot hu

Description:

Kernel: 2.6.32.50 with Grsecurity+PAX

PHP Version 5.3.10-1~dotdeb.1

Grsecurity/PAX installed

Additional .ini files parsed/etc/php5/fpm/conf.d/apc.ini, 
/etc/php5/fpm/conf.d/curl.ini, /etc/php5/fpm/conf.d/gd.ini, 
/etc/php5/fpm/conf.d/imagick.ini, /etc/php5/fpm/conf.d/mysql.ini, 
/etc/php5/fpm/conf.d/mysqli.ini, /etc/php5/fpm/conf.d/pdo.ini, 
/etc/php5/fpm/conf.d/pdo_mysql.ini, /etc/php5/fpm/conf.d/pdo_sqlite.ini, 
/etc/php5/fpm/conf.d/sqlite.ini, /etc/php5/fpm/conf.d/sqlite3.ini, 
/etc/php5/fpm/conf.d/suhosin.ini 



Test script:
---
-

Expected result:

-

Actual result:
--
gdb /usr/sbin/php5-fpm ./core-phpfpm
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/sbin/php5-fpm...Reading symbols from 
/usr/lib/debug/usr/sbin/php5-fpm...done.
(no debugging symbols found)...done.
Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libonig.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libonig.so.2
Reading symbols from /usr/lib/libcrypto.so.0.9.8...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libcrypto.so.0.9.8
Reading symbols from /usr/lib/libssl.so.0.9.8...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libssl.so.0.9.8
Reading symbols from /usr/lib/libdb-4.8.so...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libdb-4.8.so
Reading symbols from /usr/lib/libqdbm.so.14...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libqdbm.so.14
Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libbz2.so.1.0
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libpthread.so.0...(no debugging sym

Bug #55383 [Opn]: Trying to open big archives (~2GB) produces error: ZIPARCHIVE::ER_NOZIP

[andreas at ultra-vires dot de]

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

 ID: 55383
 User updated by:andreas at ultra-vires dot de
 Reported by:andreas at ultra-vires dot de
 Summary:Trying to open big archives (~2GB) produces error:
 ZIPARCHIVE::ER_NOZIP
 Status: Open
 Type:   Bug
 Package:Zip Related
 Operating System:   WinXP (32Bit) & SuseLinux(64Bit)
 PHP Version:5.3SVN-2011-08-08 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Hello again,

some time passed by and I did some further tests on the ZipArchive class...with 
really strange results... Here are my experiances:

Again, I have a very big archive:

Folders: 2346
Files: 109470
Size:   8158345387
Compressed: 5374915526

When I try to extract this archive with 7zip (7-Zip [64] 9.20), it tells me in 
the end: "Everything is Ok"

Trying to open this archive with PHP's ZipArchive Class, always error 
"ZIPARCHIVE:NO_ZIP" arrises (error code 19). (on the same Linux 64bit machine - 
Suse)

Well, I coded a shell execute in PHP and call the 7z binary which extracts this 
archive into a temp folder -> success, all files are extracted as expected.

Next, I create a new ZipArchive like this:
open($new_ziparchive, ZIPARCHIVE::OVERWRITE) !== true)
  die('Failed to create new ZIP-Archive: '.$new_ziparchive);
[...]
?>

No errors, since here.

Now, I recursively loop through the (sub)folders of the previously extracted 
archive (again: extracted whith 7zip) and create the new ZIP-Archive with PHP 
ZipArchive Class... Successfully!!!

After $zip->close(); I've got a valid ZIP-Archive and there is no problem to 
access it with 7Zip. I can uncompress this without any problems.

BUT: When I try to open this ZIP with the PHP's ZipArchive Class again, the 
well known Error "ER_NOZIP" (Error Code 19) comes up!

Strange: Creating very large archives is not a problem, but reading them after 
creation (whith the same library!!!) is not possible with ZipArchive Class...

What the heck...?!

Any help, ideas, hints??


Previous Comments:

[2011-08-09 09:08:19] andreas at ultra-vires dot de

Description:

I try to read ZIP-Archives and always get Error "ZIPARCHIVE::ER_NOZIP" when 
size of the archive is bigger than 1.xx GB (nearly 2 GB, and more) and ZIP 
contains more than 15.000 (bit more or less) files. 

Trying to open "very large" archives always fails with errocode 
"ZIPARCHIVE::ER_NOZIP".

Sometimes I need to open "verly large" archies (up to 10 GB, containing 30.000 
files or even more). In some cases some sub-folders inside the archive contain 
more than 10.000 files... I have no influence on the ZIP-Creation Process, so a 
tipp like "Try to create smaller ZIPs!" doesn't help me. ;-)
But I need to look inside the archives, afterwards...

I've tested under WinXP SP3 (32Bit, PHP 5.3.1) and Suse Linux (64Bit, PHP 
5.3.6).
PHP is running as Apache module. Both machines have the same phenomenon.

I did some tests with several different settings while compressing algos (using 
7zip), but always the same result. Smaller archives never produce that error. 

Do exist limits (ammount of files / ZIP-Filesize) while handling ZIP-Archives 
in PHP? Trying to list/extract theese "bad" Archives on the command line (e.g. 
with 7zip) always succeed.

This bug is different from Bug #44974: ZipArchive can't open large archives.
Again: I get "ZIPARCHIVE::ER_NOZIP", NOT "ZIPARCHIVE::ER_READ"!!
And I do not have problems on archives containing 1000, or 2000 files...

Thanks in advance.



Test script:
---
open($file, ZIPARCHIVE::CHECKCONS);
if ($errCode == ZIPARCHIVE::ER_NOZIP)
  echo "Fail.";

// Outputs "Fail." :(
?>


Expected result:

Outputs "Fail." on large archives, since they contain ten thousands of files 
or/and have filsize nearby 2GB.







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

Bug #60993 [Opn->Asn]: php_intl.dll is missing from the non-thread safe Windows version

[pajoye]

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

 ID: 60993
 Updated by: paj...@php.net
 Reported by:yoozer at gmail dot com
 Summary:php_intl.dll is missing from the non-thread safe
 Windows version
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows
 PHP Version:5.4.0RC7
-Assigned To:
+Assigned To:szarkos
 Block user comment: N
 Private report: N

 New Comment:

Steve, pls take a look at this one too


Previous Comments:

[2012-02-06 14:01:45] yoozer at gmail dot com

Description:

The php_intl.dll file is missing from the Windows (non-thread safe) version. It 
is however included in the thread-safe version. 







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

Bug #60992 [Com]: Trim / rtrim bug when we need to delete extension

[anon at anon dot anon]

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

 ID: 60992
 Comment by: anon at anon dot anon
 Reported by:elie29 at gmail dot com
 Summary:Trim / rtrim bug when we need to delete extension
 Status: Open
 Type:   Bug
 Package:Strings related
 Operating System:   windows
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

This is the correct logic for the trim functions. As stated in the 
documentation, the second parameter is a list of characters, not a solid string 
to test for verbatim. Hence `rtrim('users.php', 'ph.'))` is also 'users'. Try 
something like this instead:

function rtrim_str($str, $fragment) {
if (substr($str, -strlen($fragment)) === $fragment) $str = substr($str, 
0, -strlen($fragment));
return $str;
}


Previous Comments:

[2012-02-06 13:46:14] elie29 at gmail dot com

Description:

If we need to delete from a file name its extension using trim or rtrim 
function, 
the return value is uncorrect when your file name is ended with an 's' 
characters.

Exemple :
rtrim('users.js', '.js'); => will return user instead of users

Test script:
---
var_dump(rtrim('users.js', 'js')); // users. OK
var_dump(rtrim('users.', '.')); //users OK
var_dump(rtrim('users.js', '.js')); //  user instead of users KO
var_dump(trim('users.php', '.php')); // user instead of users KO
var_dump(rtrim('correct.js', '.js')); //correct OK
var_dump(trim('.js', '.js')); // empty string instead of  KO

Expected result:

var_dump(rtrim('users.js', 'js')); // users.
var_dump(rtrim('users.', '.')); //users
var_dump(rtrim('users.js', '.js')); //  users
var_dump(trim('users.php', '.php')); // users
var_dump(rtrim('correct.js', '.js')); //correct
var_dump(trim('.js', '.js')); // sss







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

[PHP-BUG] Bug #60993 [NEW]: php_intl.dll is missing from the non-thread safe Windows version

[yoozer at gmail dot com]

From: 
Operating system: Windows
PHP version:  5.4.0RC7
Package:  *General Issues
Bug Type: Bug
Bug description:php_intl.dll is missing from the non-thread safe Windows version

Description:

The php_intl.dll file is missing from the Windows (non-thread safe)
version. It is however included in the thread-safe version. 


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

[PHP-BUG] Bug #60992 [NEW]: Trim / rtrim bug when we need to delete extension

[elie29 at gmail dot com]

From: 
Operating system: windows
PHP version:  5.3.10
Package:  Strings related
Bug Type: Bug
Bug description:Trim / rtrim bug when we need to delete extension

Description:

If we need to delete from a file name its extension using trim or rtrim
function, 
the return value is uncorrect when your file name is ended with an 's'
characters.

Exemple :
rtrim('users.js', '.js'); => will return user instead of users

Test script:
---
var_dump(rtrim('users.js', 'js')); // users. OK
var_dump(rtrim('users.', '.')); //users OK
var_dump(rtrim('users.js', '.js')); //  user instead of users KO
var_dump(trim('users.php', '.php')); // user instead of users KO
var_dump(rtrim('correct.js', '.js')); //correct OK
var_dump(trim('.js', '.js')); // empty string instead of  KO

Expected result:

var_dump(rtrim('users.js', 'js')); // users.
var_dump(rtrim('users.', '.')); //users
var_dump(rtrim('users.js', '.js')); //  users
var_dump(trim('users.php', '.php')); // users
var_dump(rtrim('correct.js', '.js')); //correct
var_dump(trim('.js', '.js')); // sss


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

Bug #60879 [Com]: unserialize() Does not invoke __wakeup() on object

[yoozer at gmail dot com]

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

 ID: 60879
 Comment by: yoozer at gmail dot com
 Reported by:thijsputman at gmail dot com
 Summary:unserialize() Does not invoke __wakeup() on object
 Status: Closed
 Type:   Bug
 Package:Class/Object related
 Operating System:   Windows 7
 PHP Version:5.4.0RC6
 Assigned To:johannes
 Block user comment: N
 Private report: N

 New Comment:

I've just tested the official release of RC7; it still exhibits this issue with 
exactly the same testcase.


Previous Comments:

[2012-01-26 11:33:25] johan...@php.net

So let's assume this was fixed. I can't see a relevant change for this, though. 
There will be another RC soon, an you check that, too, to be safe? Thanks :-)


[2012-01-26 10:56:17] thijsputman at gmail dot com

Just tried with revision 322785 and it indeed works as expected.

To assert my sanity I re-downloaded 5.4.0RC6 (VC9 x86 Non Thread Safe, 
2012-Jan-19 23:40:07) from the QA website and in that release the problem does 
exist.


[2012-01-26 10:14:20] johan...@php.net

Please try using this snapshot:

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

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

Works for me with latest svn. Do you have any special extension loaded or some 
special configuration?


[2012-01-25 13:24:57] thijsputman at gmail dot com

Description:

When serializing/unserializing an object that contains both a __sleep() and 
__wakeup() method, serialize() invokes the __sleep() method, but unserialize() 
does *not* invoke the __wakeup() method.

Using PHP 5.4.0RC6 (x86 NTS) on Windows 7, previously used 5.4.0RC5 which did 
not exhibit this problem. See the below test script for an example (which works 
as expected in RC5, but not in RC6).

Test script:
---
class Woei{

public function __sleep(){

echo 'sleep' . PHP_EOL;

return array();
}

public function __wakeup(){

echo 'wakeup' . PHP_EOL;
}
}

$Woei = new Woei();

$s1 = serialize($Woei);
$Woei2 = unserialize($s1);

$s2 = serialize($Woei2);
$Woei3 = unserialize($s2);

Expected result:

sleep
wakeup
sleep
wakeup

Actual result:
--
sleep
sleep






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

[PHP-BUG] Bug #60990 [NEW]: Segfault when trying to allocate more memory

[flatline at hardwired dot hu]

From: 
Operating system: Debian Squeeze x86_64
PHP version:  5.3.10
Package:  FPM related
Bug Type: Bug
Bug description:Segfault when trying to allocate more memory

Description:

Kernel: 2.6.32.50 with Grsecurity+PAX

PHP Version 5.3.10-1~dotdeb.1

Grsecurity/PAX installed

Additional .ini files parsed/etc/php5/fpm/conf.d/apc.ini,
/etc/php5/fpm/conf.d/curl.ini, /etc/php5/fpm/conf.d/gd.ini,
/etc/php5/fpm/conf.d/imagick.ini, /etc/php5/fpm/conf.d/mysql.ini,
/etc/php5/fpm/conf.d/mysqli.ini, /etc/php5/fpm/conf.d/pdo.ini,
/etc/php5/fpm/conf.d/pdo_mysql.ini, /etc/php5/fpm/conf.d/pdo_sqlite.ini,
/etc/php5/fpm/conf.d/sqlite.ini, /etc/php5/fpm/conf.d/sqlite3.ini,
/etc/php5/fpm/conf.d/suhosin.ini 



Test script:
---
-

Expected result:

-

Actual result:
--
gdb /usr/sbin/php5-fpm ./core-phpfpm
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/sbin/php5-fpm...Reading symbols from
/usr/lib/debug/usr/sbin/php5-fpm...done.
(no debugging symbols found)...done.
Reading symbols from /lib/libcrypt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libonig.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libonig.so.2
Reading symbols from /usr/lib/libcrypto.so.0.9.8...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libcrypto.so.0.9.8
Reading symbols from /usr/lib/libssl.so.0.9.8...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libssl.so.0.9.8
Reading symbols from /usr/lib/libdb-4.8.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libdb-4.8.so
Reading symbols from /usr/lib/libqdbm.so.14...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libqdbm.so.14
Reading symbols from /lib/libbz2.so.1.0...(no debugging symbols
found)...done.
Loaded symbols for /lib/libbz2.so.1.0
Reading symbols from /lib/librt.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libdl.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libgssapi_krb5.so.2
Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libkrb5.so.3
Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libk5crypto.so.3
Reading symbols from /lib/libcom_err.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libresolv.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libpthread.so.0...(no debugging symbols
found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /usr/lib/libkrb5support.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libkrb5support.so.0
Reading symbols from /lib/libkeyutils.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/libkeyutils.so.1
Reading symbols from /usr/lib/php5/20090626/apc.so...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/php5/20090626/apc.so
Reading symbols from /usr/lib/php5/20090626/curl.so...Reading symbols from
/usr/lib/debug/usr/lib/php5/20090626/curl.so...done.
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/php5/20090626/curl.so
Reading symbols from /usr/lib/libcurl.so.4...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libcurl.so.4
Reading symbols from /usr/lib/libidn.so.11...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libidn.so.11
Reading symbols from /usr/lib/libssh2.so.1...(no debugging symbols
found)...done.
Loaded symbols for 

Bug #60986 [Com]: pcre_get_compiled_regex_cache: php_pcre.c: undefined reference to 'pcre_info'

[pierre at archlinux dot de]

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

 ID: 60986
 Comment by: pierre at archlinux dot de
 Reported by:j0inty at stollfuss dot net
 Summary:pcre_get_compiled_regex_cache: php_pcre.c: undefined
 reference to 'pcre_info'
 Status: Open
 Type:   Bug
 Package:PCRE related
 Operating System:   Linux
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

This also affects the 5.3 branch. The problem is the use of the pcre_info 
function which was deprecated and repalced by pcre_fullinfo 12 years ago. This 
function was now removed with pcre 8.30.

I only found one real use of it and some exports; I have attached a patch that 
might work. Note the I have no idea about php internals; so this might be 
entirely stupid or dangerous.

Also note that you might not be able to compile the apache module as apache 
itself seems also to be incompatible with pcre 8.30

Greetings,

Pierre


Previous Comments:

[2012-02-06 10:06:44] j0inty at stollfuss dot net

Description:

Hi,

If you try to compile the current RC7 of php 5.4.0 the Linker crash with the 
following message.

ext/pcre/php_pcre.o: In function `pcre_get_compiled_regex_cache':
php_pcre.c:(.text+0xb8f): undefined reference to `pcre_info'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Fehler 1

The reason is the new libpcre-8.30 which was today in my update list.

dev-libs/libpcre-8.30-r2

You can find a full build.log posted on http://paste.pocoo.org/show/546652/ .

regards
j0inty







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

[PHP-BUG] Bug #60986 [NEW]: pcre_get_compiled_regex_cache: php_pcre.c: undefined reference to 'pcre_info'

[j0inty at stollfuss dot net]

From: 
Operating system: Linux
PHP version:  5.4.0RC7
Package:  PCRE related
Bug Type: Bug
Bug description:pcre_get_compiled_regex_cache: php_pcre.c: undefined reference 
to 'pcre_info'

Description:

Hi,

If you try to compile the current RC7 of php 5.4.0 the Linker crash with
the following message.

ext/pcre/php_pcre.o: In function `pcre_get_compiled_regex_cache':
php_pcre.c:(.text+0xb8f): undefined reference to `pcre_info'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Fehler 1

The reason is the new libpcre-8.30 which was today in my update list.

dev-libs/libpcre-8.30-r2

You can find a full build.log posted on http://paste.pocoo.org/show/546652/
.

regards
j0inty


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

Bug #60978 [Com]: exit code incorrect

[larue...@php.net]

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

 ID: 60978
 Comment by: larue...@php.net
 Reported by:the...@php.net
 Summary:exit code incorrect
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows
 PHP Version:5.4.0RC7
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

I think a appropriate way to fix these issues(memleak, xdebug, this issue) is 
catch->efree->throw.  I have made a patch. 

Derick, what do you think?


Previous Comments:

[2012-02-06 09:55:47] larue...@php.net

The following patch has been added/updated:

Patch Name: wrong_exit_code.patch
Revision:   1328522147
URL:
https://bugs.php.net/patch-display.php?bug=60978&patch=wrong_exit_code.patch&revision=1328522147


[2012-02-05 13:36:33] the...@php.net

Checking SVN history revealed r322922 as the cause - see 
http://svn.php.net/viewvc?view=revision&revision=322922. Reverting it fixes 
this bug.

The commit mentions a relation to bug #60218 but I'm not sure why it 
"Reinstated correct return values". Before this fix the code in 
zend_execute_API.c read:

zend_execute(new_op_array TSRMLS_CC);
[...]
retval = SUCCESS;

After the fix it read:

zend_try {
zend_execute(new_op_array TSRMLS_CC);
} zend_end_try();
[...]
retval = SUCCESS;

Finally, r322922 changed it to:

retval = SUCCESS;
zend_try {
zend_execute(new_op_array TSRMLS_CC);
} zend_catch {
retval = FAILURE;
} zend_end_try();

The zend_catch  "block" is executed whenever SETJMP returns non-zero, so 
basically when LONGJMP is called, which is the case for zend_bailout(), which 
again is used by exit() and die(). To my eyes, this *changed* the return value 
instead of reinstating it. 


@derick, maybe you can shed some light on this commit?


[2012-02-05 10:54:30] the...@php.net

Test suite:

 0,
"exit('test');"=> 0,
"exit(2);" => 2,
"fatal();" => 255,
"\$->" => 254,
"throw new Exception('test');" => 255
  );
  
  foreach ($tests as $source => $expected) {
$cmd= '"'.$php.'" -r "'.$source.'" 2>&1';
$output= array();
exec($cmd, $output, $actual);
if ($actual === $expected) {
  printf("%-30s: [OK]\n", $source);
} else {
  printf("%-30s: [FAIL, expect %d, have %d (%s)]\n", $source, $expected, 
$actual, implode(' ', $output));
}
  }
?>


[2012-02-05 10:01:41] the...@php.net

...oh, and:

* Uncaught exception exit, `php -r 'throw new Exception("test");' ; echo $?` = 
255


[2012-02-05 09:59:54] the...@php.net

Your patch breaks the exitcode 254 for parse errors.

We have the following cases and expected exit codes:

* Clean exit, `php -r 'echo "";' ; echo $?` = 0
* Clean explicit exit with message, `php -r 'exit("test");' ; echo $?` = 0
* Clean explicit exit with exitcode, `php -r 'exit(2);' ; echo $?` = 2
* Exit after a fatal error, `php -r '$fatal->error();' ; echo $?` = 255
* Exit after compile error, `php -r '$->' ; echo $?` = 254




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


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

Bug #60978 [PATCH]: exit code incorrect

[larue...@php.net]

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

 ID: 60978
 Patch added by: larue...@php.net
 Reported by:the...@php.net
 Summary:exit code incorrect
 Status: Assigned
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows
 PHP Version:5.4.0RC7
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: wrong_exit_code.patch
Revision:   1328522147
URL:
https://bugs.php.net/patch-display.php?bug=60978&patch=wrong_exit_code.patch&revision=1328522147


Previous Comments:

[2012-02-05 13:36:33] the...@php.net

Checking SVN history revealed r322922 as the cause - see 
http://svn.php.net/viewvc?view=revision&revision=322922. Reverting it fixes 
this bug.

The commit mentions a relation to bug #60218 but I'm not sure why it 
"Reinstated correct return values". Before this fix the code in 
zend_execute_API.c read:

zend_execute(new_op_array TSRMLS_CC);
[...]
retval = SUCCESS;

After the fix it read:

zend_try {
zend_execute(new_op_array TSRMLS_CC);
} zend_end_try();
[...]
retval = SUCCESS;

Finally, r322922 changed it to:

retval = SUCCESS;
zend_try {
zend_execute(new_op_array TSRMLS_CC);
} zend_catch {
retval = FAILURE;
} zend_end_try();

The zend_catch  "block" is executed whenever SETJMP returns non-zero, so 
basically when LONGJMP is called, which is the case for zend_bailout(), which 
again is used by exit() and die(). To my eyes, this *changed* the return value 
instead of reinstating it. 


@derick, maybe you can shed some light on this commit?


[2012-02-05 10:54:30] the...@php.net

Test suite:

 0,
"exit('test');"=> 0,
"exit(2);" => 2,
"fatal();" => 255,
"\$->" => 254,
"throw new Exception('test');" => 255
  );
  
  foreach ($tests as $source => $expected) {
$cmd= '"'.$php.'" -r "'.$source.'" 2>&1';
$output= array();
exec($cmd, $output, $actual);
if ($actual === $expected) {
  printf("%-30s: [OK]\n", $source);
} else {
  printf("%-30s: [FAIL, expect %d, have %d (%s)]\n", $source, $expected, 
$actual, implode(' ', $output));
}
  }
?>


[2012-02-05 10:01:41] the...@php.net

...oh, and:

* Uncaught exception exit, `php -r 'throw new Exception("test");' ; echo $?` = 
255


[2012-02-05 09:59:54] the...@php.net

Your patch breaks the exitcode 254 for parse errors.

We have the following cases and expected exit codes:

* Clean exit, `php -r 'echo "";' ; echo $?` = 0
* Clean explicit exit with message, `php -r 'exit("test");' ; echo $?` = 0
* Clean explicit exit with exitcode, `php -r 'exit(2);' ; echo $?` = 2
* Exit after a fatal error, `php -r '$fatal->error();' ; echo $?` = 255
* Exit after compile error, `php -r '$->' ; echo $?` = 254


[2012-02-04 20:43:08] php-dev at zerocue dot com

Alright, in 5.3.10@php_cli:1023 the call to zend_eval_string_ex() never 
returned 
after a zend_bailout(), if it had this bug would have been present there 
because 
zend_bailout always returns FAILURE even in non-failure cases.  

In 5.4 and trunk, the zend_eval_string_ex() does return and hits the 
exit_status=254 line.  The proper fix would be to have zend_bailout not return 
FAILURE unless it did fail but this is a much larger change.  In this case the 
patch simply ignores the return state of the zend_eval_string_ex() and always 
returns the EG(exit_status) value.




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


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

Bug #60968 [Com]: Late static binding doesn't work with ReflectionMethod::invokeArgs()

[rosen at developer dot bg]

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

 ID: 60968
 Comment by: rosen at developer dot bg
 Reported by:rosen at developer dot bg
 Summary:Late static binding doesn't work with
 ReflectionMethod::invokeArgs()
 Status: Assigned
 Type:   Bug
 Package:Reflection related
 Operating System:   CentOS 5.6 (kernel 2.6.18-238.1)
 PHP Version:5.3.10
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

Thank you! I patched my PHP with your fix - seems to work fine now.


Previous Comments:

[2012-02-03 16:27:58] larue...@php.net

fixed in 5.3 , trunk, will close this after ci to 5.4


[2012-02-03 16:27:31] larue...@php.net

Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&revision=323045
Log: Fixed bug #60968 (Late static binding doesn't work with 
ReflectionMethod::invokeArgs())


[2012-02-03 13:18:43] rosen at developer dot bg

Description:

This bug was fixed in 5.3.9 for ReflectionMethod::invoke() (see bug #60367), 
but it still exists for ReflectionMethod::invokeArgs()

Test script:
---
getMethod('method')->invoke(null); // outputs 'B'
$b->getMethod('method')->invokeArgs(null, array()); // outputs 'A'


Expected result:

BB

Actual result:
--
BA






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

Bug #60758 [Com]: require() crashes Apache

[hannes at dorn dot cc]

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

 ID: 60758
 Comment by: hannes at dorn dot cc
 Reported by:bugzilla33 at gmail dot com
 Summary:require() crashes Apache
 Status: Not a bug
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Windows
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

Ups, sorry, 4096 byte require bug still exists in 5.3.10


Previous Comments:

[2012-02-06 08:06:51] hannes at dorn dot cc

FYI I had this problem in 5.3.9, but it is fixed in 5.3.10.


[2012-01-30 12:49:01] paj...@php.net

@homma dot teppei+php at gmail dot com

This bug has been fixed already and is totally different issue.

Thanks for your feedback.


[2012-01-30 02:26:02] homma dot teppei+php at gmail dot com

The same problem occurred with CLI version.
The file to be 'include' (or 'require'), PHP will crash if its size is 
multiples 
of 4096 bytes.

OS:
both Windows 7 Professional (x64) and Windows 7 Home Premium (32bit)

PHP:
5.3.9 (thread safe, with no extension)

Test case:
First of all, I prepared the file is filled with 4096bytes white spaces.
And save as 'test.txt'.

with command prompt
c:\php-sdk\> php.exe -a
 then crash.

another case:
test.php


with command prompt
c:\php-sdk\> php.exe test.php
 -> then crash.

Call Stack:
>   php5ts_debug.dll!lex_scan(_zval_struct * zendlval, void * * * tsrm_ls)  
line 942 + 0x12 bytes   C
php5ts_debug.dll!zendlex(_znode * zendlval, void * * * tsrm_ls)  line 
4975 + 0x10 bytes   C
php5ts_debug.dll!zendparse(void * tsrm_ls)  line 3285 + 0xd bytes   
C
php5ts_debug.dll!compile_file(_zend_file_handle * file_handle, int 
type, 
void * * * tsrm_ls)  line 364 + 0x9 bytes   C
php5ts_debug.dll!compile_filename(int type, _zval_struct * filename, 
void * * * tsrm_ls)  line 407 + 0x14 bytes  C

php5ts_debug.dll!ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER(_zend_execute_data * 
execute_data, void * * * tsrm_ls)  line 
1966 + 0x14 bytes   C
php5ts_debug.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls) 
 
line 107 + 0x11 bytes   C
php5ts_debug.dll!zend_execute_scripts(int type, void * * * tsrm_ls, 
_zval_struct * * retval, int file_count, ...)  line 
1236 + 0x21 bytes   C
php5ts_debug.dll!php_execute_script(_zend_file_handle * primary_file, 
void * * * tsrm_ls)  line 2308 + 0x1b bytes C
php.exe!main(int argc, char * * argv)  line 1184 + 0x13 bytes   C
php.exe!__tmainCRTStartup()  line 555 + 0x19 bytes  C
php.exe!mainCRTStartup()  line 371  C
kernel32.dll!7718339a()


[2012-01-28 09:35:49] paj...@php.net

There is no bug, sadly he is spamming bugs.php.net with "crash bugs" which are 
actually configuration issues.


[2012-01-28 00:47:48] ras...@php.net

Works fine on Linux. Doesn't seem like this should be an OS-specific thing. Can 
anybody else reproduce this on Windows?




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


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

Bug #60758 [Com]: require() crashes Apache

[hannes at dorn dot cc]

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

 ID: 60758
 Comment by: hannes at dorn dot cc
 Reported by:bugzilla33 at gmail dot com
 Summary:require() crashes Apache
 Status: Not a bug
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Windows
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

FYI I had this problem in 5.3.9, but it is fixed in 5.3.10.


Previous Comments:

[2012-01-30 12:49:01] paj...@php.net

@homma dot teppei+php at gmail dot com

This bug has been fixed already and is totally different issue.

Thanks for your feedback.


[2012-01-30 02:26:02] homma dot teppei+php at gmail dot com

The same problem occurred with CLI version.
The file to be 'include' (or 'require'), PHP will crash if its size is 
multiples 
of 4096 bytes.

OS:
both Windows 7 Professional (x64) and Windows 7 Home Premium (32bit)

PHP:
5.3.9 (thread safe, with no extension)

Test case:
First of all, I prepared the file is filled with 4096bytes white spaces.
And save as 'test.txt'.

with command prompt
c:\php-sdk\> php.exe -a
 then crash.

another case:
test.php


with command prompt
c:\php-sdk\> php.exe test.php
 -> then crash.

Call Stack:
>   php5ts_debug.dll!lex_scan(_zval_struct * zendlval, void * * * tsrm_ls)  
line 942 + 0x12 bytes   C
php5ts_debug.dll!zendlex(_znode * zendlval, void * * * tsrm_ls)  line 
4975 + 0x10 bytes   C
php5ts_debug.dll!zendparse(void * tsrm_ls)  line 3285 + 0xd bytes   
C
php5ts_debug.dll!compile_file(_zend_file_handle * file_handle, int 
type, 
void * * * tsrm_ls)  line 364 + 0x9 bytes   C
php5ts_debug.dll!compile_filename(int type, _zval_struct * filename, 
void * * * tsrm_ls)  line 407 + 0x14 bytes  C

php5ts_debug.dll!ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER(_zend_execute_data * 
execute_data, void * * * tsrm_ls)  line 
1966 + 0x14 bytes   C
php5ts_debug.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls) 
 
line 107 + 0x11 bytes   C
php5ts_debug.dll!zend_execute_scripts(int type, void * * * tsrm_ls, 
_zval_struct * * retval, int file_count, ...)  line 
1236 + 0x21 bytes   C
php5ts_debug.dll!php_execute_script(_zend_file_handle * primary_file, 
void * * * tsrm_ls)  line 2308 + 0x1b bytes C
php.exe!main(int argc, char * * argv)  line 1184 + 0x13 bytes   C
php.exe!__tmainCRTStartup()  line 555 + 0x19 bytes  C
php.exe!mainCRTStartup()  line 371  C
kernel32.dll!7718339a()


[2012-01-28 09:35:49] paj...@php.net

There is no bug, sadly he is spamming bugs.php.net with "crash bugs" which are 
actually configuration issues.


[2012-01-28 00:47:48] ras...@php.net

Works fine on Linux. Doesn't seem like this should be an OS-specific thing. Can 
anybody else reproduce this on Windows?


[2012-01-16 18:18:41] bugzilla33 at gmail dot com

Here you are:
http://host0001.webd.pl/bugs/php/reports/CrashHang_Report__PID_1080__01162012191518294.zip




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


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