Bug #26049 [Com]: Cannot connect to ODBC source (MyODBC)

[saketisthere at gmail dot com]

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

 ID: 26049
 Comment by: saketisthere at gmail dot com
 Reported by:miroslav dot sulc at startnet dot cz
 Summary:Cannot connect to ODBC source (MyODBC)
 Status: Not a bug
 Type:   Bug
 Package:ODBC related
 Operating System:   Linux (Gentoo)
 PHP Version:4.3.3
 Block user comment: N
 Private report: N

 New Comment:

Hello,

Hvae you modified the odbc.ini and odbcinst.ini files also you need to set your 
environment variables along with the LD_LIBRARY_PATH so that it finds that 
driver.

Currently it is not able to find the driver it needs to use to get connected

Saket Kale.


Previous Comments:

[2003-12-09 11:18:57] sirb3r at yahoo dot ca

Same problem trying to get to Access:

Warning: odbc_connect(): SQL error: [unixODBC][Driver Manager]Can't open lib 
'/usr/lib/libmdbodbc.so' : unknown error, SQL state IM003 in SQLConnect in 
/home/httpd/htdocs/migrate.php on line 3


[2003-10-31 11:02:36] miroslav dot sulc at startnet dot cz

Does it mean that it is sure that this behaviour is caused by misconfiguration 
and not by PHP bug? Do you know what problem I am dealing with and what is the 
solution? I have been looking for an answer to my problem for several hours and 
found nothing usefull.


[2003-10-31 09:22:22] kalow...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Please read how to configure your unixODBC system.  


[2003-10-31 05:00:28] miroslav dot sulc at startnet dot cz

Description:

I cannot connect with:
$var=odbc_connect('myodbc-test','root','password');
to my MyODBC data source.

Here is the error:
Warning: odbc_connect(): SQL error: [unixODBC][Driver Manager]Can't open lib 
'/usr/lib/libmyodbc3.so' : unknown error, SQL state IM003 in SQLConnect in 
/home/httpd/bagr/docs/test.php on line 2

I would appreciate any help. Below is some more info.

isql command work fine:
echo "show tables;
> " | isql myodbc-test root password
+---+
| Connected!|
|   |
| sql-command   |
| help [tablename]  |
| quit  |
|   |
+---+
SQL> +-+
| Tables_in_test  |
+-+
+-+
0 rows affected


Here is PHP configuration:
'./configure' '--prefix=/usr' '--host=i686-pc-linux-gnu' 
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' 
'--sysconfdir=/etc' '--localstatedir=/var/lib' '--without-readline' 
'--with-apxs2=/usr/sbin/apxs2' '--with-ndbm=/usr' '--with-db4=/usr' 
'--with-mcrypt=/usr' '--with-mhash=/usr' '--with-ming=/usr' '--with-swf=/usr' 
'--with-sybase=/usr' '--with-gdbm=/usr' '--with-java=/opt/blackdown-jdk-1.4.1' 
'--with-mcal=/usr' '--with-unixODBC=/usr' '--with-pgsql=/usr' 
'--with-snmp=/usr' '--enable-ucd-snmp-hack' '--with-pdflib=/usr' '--with-gd' 
'--enable-gd-native-ttf' '--with-png' '--with-png-dir=/usr' '--with-jpeg' 
'--with-jpeg-dir=/usr' '--enable-exif' '--with-tiff' '--with-tiff-dir=/usr' 
'--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' 
'--with-freetype-dir=/usr' '--with-ttf=/usr' '--with-t1lib=/usr' 
'--with-gettext' '--without-qtdom' '--with-pspell=/usr' '--with-openssl=/usr' 
'--with-imap=/usr' '--with-ldap=/usr' '--with-dom=/usr' '--with-dom-xslt=/usr' 
'--with-dom-exslt=/usr' '--with-kerberos=/usr' '--with-pam' 
'--disable-memory-limit' '--disable-ipv6' '--with-curlwrappers' 
'--with-curl=/usr' '--enable-dbx' '--with-imap-ssl' '--with-zlib' 
'--with-zlib-dir=/usr' '--with-sablot=/usr' '--enable-xslt' 
'--with-xslt-sablot' '--with-xmlrpc' '--enable-wddx' '--with-xml' 
'--enable-mbstring=all' '--enable-mbregex' '--with-bz2=/usr' 
'--with-crack=/usr' '--with-cdb' '--enable-bcmath' '--enable-calendar' 
'--enable-dbase' '--enable-filepro' '--enable-ftp' '--with-mime-magic' 
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvipc' 
'--with-iconv' '--enable-shmop' '--enable-dio' '--enable-inline-optimization' 
'--enable-track-vars' '--enable-trans-sid' '--enable-versioning'

Bug #19795 [Com]: Problems with strnatcmp and strnatcasecmp

[redrat at mail dot ru]

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

 ID: 19795
 Comment by: redrat at mail dot ru
 Reported by:doc at nitramlexa dot com
 Summary:Problems with strnatcmp and strnatcasecmp
 Status: Closed
 Type:   Bug
 Package:Strings related
 Operating System:   FreeBSD 4.6
 PHP Version:4.2.2
 Block user comment: N
 Private report: N

 New Comment:

This bug still has place in PHP 5.3.10 for all cyrillic letters (and I think 
for other non-ASCII letters too). This bug-report was filled almost 10 years 
ago! Could anybody do something with it?


Previous Comments:

[2004-07-29 10:42:28] larry at kamsha dot ru

I have PHP 5.0.0 release with same bug (with cyrillic characters). I've 
analized sources and found out that comparison is made on "char" values. So all 
extended characters (with hi-order bit 1) treated as negative.
Changing "char" to "unsigned char" would place national characters after 
english characters (greater in terms of compare), that is correct, but 
locale-specific collation problem will remain. This is not important for CP1251 
or CP866 cyrillic encodings, because theese already have characters sorted by 
values correctly. But there will be problem for KOI8-R encoding (for which this 
is not the case).
The problem can be easily solved by using "strcoll" (in place of dumb value 
compare), I guess.


[2004-07-16 04:32:57] mbp at sourcefrog dot net

This bug does seem to still be present in php5 CVS.  The comparison is simply 
by byte values, not taking character set or locale into account.


[2004-06-28 14:55:26] mikael at chl dot chalmers dot se

This bug seems to have popped back again in version 4.3.7

When using setlocale(LC_ALL, 'sv_SE') the national chars åäö get sorted before 
other international chars, they should appear at the bottom.


[2003-04-16 16:11:22] moriyo...@php.net

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




[2003-01-27 16:11:34] kamikaze at yifan dot net

I have the same problem, with æøå. strtoupper() does, for example, not 
uppercase those letters.

Also i 4.2.3




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

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


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

Bug #46851 [Com]: Strict standards: Declaration of ... should be compatible with that of ...

[eyal dot t at zend dot com]

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

 ID: 46851
 Comment by: eyal dot t at zend dot com
 Reported by:oliver at teqneers dot de
 Summary:Strict standards: Declaration of ... should be
 compatible with that of ...
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   OpenSuSE 11.0
 PHP Version:5.2.8
 Block user comment: N
 Private report: N

 New Comment:

was wondering why the order of the class declarations affects whether a notice 
is given, that is while

abstract class B extends A {
 public static function foo($str){ echo $str; }
}

abstract class A {
 public static function foo(){ echo 'bar'; }
}

causes the strict standard notice to show, the reversed order does not:

abstract class A {
 public static function foo(){ echo 'bar'; }
}

abstract class B extends A {
 public static function foo($str){ echo $str; }
}


Previous Comments:

[2011-08-03 21:32:13] josh dot x dot guthrie at gmail dot com

This is not a bug in PHP, this is a flaw in your understanding of PHP and how 
it 
handles method overloading.  If your child class inherits from the parent class 
and you override one of the parent class's methods, you must still pass it the 
same number of parameters.  Ex:

abstract class B extends A {
 public static function foo($str){ echo $str; }
}

abstract class A {
 public static function foo(){ echo 'bar'; }
}

What you will notice is that class A has a method "foo" which takes no 
parameters.  We then extend A with class B which overrides the method "foo" and 
gives it a parameter "$str".  This method overload is causing the strict error. 
 
If you want a fix, make the parameter optional and it should remove the strict 
warning.  This fix has been tested with the __autoload function for class 
loading.


[2010-11-09 02:49:37] gabriel dot delepine at gmail dot com

I have exactly the same problem. 
Autoload() is called for the subclass before the class. A error E_STRICT is 
throw.

I use PHP 5.3.2-1 on Ubuntu Serveur 10.04

It append for me when I use the design pattern sigleton and when I call the 
function getInstance() of the subclass. This function have to return an 
instance 
of the subclass but the error E_STRICT is throw.

I check the change log of PHP 5.3.3-1 but I seen nothing about this.


[2010-07-14 21:46:58] demaio at vanylla dot it

I sthis a PHP bug then?
Is this bug going to be fixed?


[2010-07-11 16:45:07] col...@php.net

What change?

The error is in both cases here, only that in one case, it is not displayed 
because at the time it is emitted, error_reporting does not contain E_STRICT 
(.e. php.ini).

It's not about ensuring class loading order. It is simply that if you define 
classes in a "wrong" order, or if you use autoload, classes loading will get 
postponed at runtime, hence errors will be triggered at runtime i.e. after the 
error_reporting call.


[2010-07-11 14:48:04] david at customcode dot co dot za

Surely this counts as a bug when you consider it in the context of applications 
that make extensive use autoload. I realise I am a bit late to this party but 
from what I can see the strict standard was changed in php 5.2.10 but I can't 
seem to find any mention of this change in the changelog. This appears to be a 
fairly major change potentially affecting alot of people's code. I would expect 
at least some documentation of the rationale behind the change and at least 
some guidelines. That being said, surely when it comes to ensuring that classes 
are loaded/compiled in the correct order, classes that needed to be autoloaded 
should be loaded first before the child class is compiled. Or am I missing 
something?




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


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

[PHP-BUG] Bug #61022 [NEW]: DateTime constructor ignores DateTimeZone argument in favor of string TZ

[kavi at postpro dot net]

From: 
Operating system: n/a
PHP version:  trunk-SVN-2012-02-09 (SVN)
Package:  Date/time related
Bug Type: Bug
Bug description:DateTime constructor ignores DateTimeZone argument in favor of 
string TZ

Description:

When creating a new DateTime object, if given a parseable string with a
timezone 
descriptor such as "Monday, 15-Aug-05 15:52:01 PDT" AND a DateTimeZone
argument, 
the DateTimeZone argument will be completely ignored.

Please either reopen #40743 or fix this bug if it is a regression for a
different 
reason.

This is broken on 5.3.3 and trunk.

Test script:
---
$a = new DateTime('Monday, 15-Aug-05 15:52:01 PDT', new
DateTimeZone('America/New_York'));
print_r($a);


Expected result:

An exception.

If you absolutely must, which you shouldn't, a warning and an automatic
conversion 
of the date string to the proper time in America/New_York.

Actual result:
--
DateTime Object
(
[date] => 2005-08-15 15:52:01
[timezone_type] => 2
[timezone] => PDT
)


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

Bug #40743 [Com]: DateTime ignores the TimeZone object passed to the constructor

[kavi at postpro dot net]

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

 ID: 40743
 Comment by: kavi at postpro dot net
 Reported by:ddb at bitxtender dot de
 Summary:DateTime ignores the TimeZone object passed to the
 constructor
 Status: Closed
 Type:   Bug
 Package:Date/time related
 Operating System:   Win XP
 PHP Version:5.2.1
 Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

This bug is NOT fixed on 5.3.3 or trunk.

$ php

 2005-08-15 15:52:01
[timezone_type] => 2
[timezone] => PDT
)


Previous Comments:

[2008-01-17 18:50:12] der...@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




[2007-04-19 20:53:33] artur at jedlinski dot pl

It is ignoring the #2 parameter when you put the timezone info inside the #1. 
It's *absolutely* unacceptable.

// Europe/Warsaw = GMT +0200
$dateSrc = '2007-04-19 12:50:00 GMT';
$dateTime = new DateTime($dateSrc, new DateTimeZone('Europe/Warsaw'));
echo $dateTime->format('H:i:s')."";
// RESULT: 12:50:00 (expected: 14:50:00)

$dateTime->setTimeZone(new DateTimeZone('Europe/Warsaw'));
echo $dateTime->format('H:i:s')."";
// RESULT: 14:50:00 (correct)

IMHO the most intuitive way is to create the date based on the #1, but displays 
it using #2.

It's not only strange it ignores #2, but in fact it's strange that the internal 
DateTime pointer is set to timezone provided in #1 at all. If the 
date_default_timezone_set() was set to some TZ, it should create dates within 
this timezone if one doesn't state otherwise (using #2). Of course the timezone 
info from #1 should be used, but only to calculate the actual timestamp.

date_default_timezone_set('Europe/Warsaw');
$dateSrc = '2007-04-19 12:50:00 GMT';
$dateTime = new DateTime($dateSrc);
echo $dateTime->format('H:i:s')."";
// RESULT: 12:50:00 (expected: 14:50:00)

Currently, it's pretty complicated to translate dates from one timezone to 
another - you have to use DateTime::setTimeZone(), when one line should do the 
thing:

$dateTime = new DateTime($dateWithSrcTimeZone, $timeZoneToDisplay);
(or even without $timeZoneToDisplay if you want to use your current TZ).


[2007-04-11 14:45:46] der...@php.net

It's not totally ignored, but something fishy is going on. See the following 
script + output:

format(DATE_RFC822 . " e T O"), "\n";

$dt = new DateTime('@' . time());
echo $dt->format(DATE_RFC822 . " e T O"), "\n";

$dt = new DateTime('@' . time(), new DateTimeZone('Europe/Berlin'));
echo $dt->format(DATE_RFC822 . " e T O"), "\n";
?>

Wed, 11 Apr 07 16:42:40 +0200 Europe/Oslo CEST +0200
Wed, 11 Apr 07 14:42:40 +0100 Europe/Oslo GMT+0100 +0100
Wed, 11 Apr 07 14:42:40 +0100 Europe/Berlin GMT+0100 +0100



[2007-03-06 23:27:24] ddb at bitxtender dot de

Description:

when you create a new DateTime object the timezone object you pass along in the 
constructor is ignored.
setting the timezone using setTimeZone works as expected.
also tested with 5.2-dev and 6.0-dev

Reproduce code:
---
$dt = new DateTime('@' . time(), new DateTimeZone('Europe/Berlin'));
echo $dt->format(DATE_RFC822);

Expected result:

Tue, 07 Mar 07 01:22:55 +0100

Actual result:
--
Tue, 07 Mar 07 00:22:55 +






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

Req #40799 [Com]: change string conversion behaviour for objects not implementing __toString()

[kavi at postpro dot net]

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

 ID: 40799
 Comment by: kavi at postpro dot net
 Reported by:oliver dot graetz at gmx dot de
 Summary:change string conversion behaviour for objects not
 implementing __toString()
 Status: Open
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   any
 PHP Version:5.2.1
 Block user comment: N
 Private report: N

 New Comment:

Open for almost five years now without a single comment from a core developer.


Previous Comments:

[2011-09-09 11:26:38] oliver dot graetz at gmx dot de

First of all: Fixing the DateTime class is a good start but this is really just 
one of many problems.

Four and a half years have passed and with the current PHP the problem still 
persists: Put any object not implementing __toString() into code where it is 
converted to string (for example using "implode()") and you get a catchable 
fatal error.

PHP is a language ultimately designed to produce strings in 99.999% of all 
calls to any PHP script. Introducing language changes that make this harder is 
not a good idea.

There are many situations when code runs through a list or hierarchy of 
variables. The current situation forces the programmer to check whether a cast 
to string for any variables is safe:

  $printable = (!is_object($var) or method_exists($var, '__toString'));

This is really a joke on its own: For arrays and even resources there is a 
fallback (e.g. "Resource id #17"), only for objects someone decided that it 
would be a good idea to instead produce catchable fatal errors under certain 
circumstances.

For me there currently remain some questions:

1. Why is there still no output for engine internal classes like DateTime where 
there is good reason to actually provide a default output?

2. Why is there no "is_printable($var)" function if PHP changed to a language 
where not all variables can be printed? The above code should not be needed to 
answer such a basic question. Thinking about a "Printable" interface would also 
be a good idea if the current situation with triggering errors remains.

3. Why is there a fallback "Array" for arrays but not "Object" or something 
else for objects not providing the __toString method?

4. Why does this have to be a catchable fatal error that forces the programmer 
to provide an error handler that purposely ignores it to continue script 
execution? Wouldn't an E_WARNING have sufficed?


[2010-02-16 22:24:56] none at mialinator dot com

just fix datetime!


[2007-03-14 03:51:50] oliver dot graetz at gmx dot de

Description:

Yes, I read the upgrade guide and the other bug reports regarding this topic so 
this is not a bug report but a plea for reconsideration.

I really like that finally __toString() works in every situation but the 
inability to output object instances without __toString() defined is just too 
annoying. PHP preaches the KISS principle and on this issue the language is 
breaking its own rules.

First of all, there are engine internal classes where the programmer is unable 
to provide a __toString method. Subclassing all of these classes upon usage 
just "to be on the safe side" is nonsense. If object output can't be changed to 
provide a fallback if __toString() is missing then at least all engine internal 
classes should implement their own default output.

Secondly, for safety many programmers might be tempted to make all classes 
extend a common superclass just "to be on the safe side". This is braindead for 
the sake of any OOP concept but I already see some guys on the horizon ready to 
do it.

And at last: There are so many convenient functions that just break if their 
input contains "problem objects". It just makes no sense that PHP forces me to 
implement an "object safe" version of implode()! I just had to do that and the 
loss of performance makes me shudder. Rasmus once said that PHP should only be 
a frontend for "PHP templates" that make use of as much precompiled code as 
possible. So why are these "templates" forced to implement ever more stuff in 
the userland?

Suggestions:

- at least implement default output for all engine internal classes

- change __toString() to have a fallback, even "[__toString() missing]" 
improves on the current situation

-- if this isn't POSSIBLE: PLEASE clearly state why at prominent places in the 
documentation.

-- if this isn't WANTED: make it configurable or better, add a magic function, 
for example __tostring_fallback(), which should return a string. If it doesn't 
exist or doesn't return a string: go ahead raising the recoverable error! 
Abusing an error handler to do this is NOT a so

Req #61021 [Opn->Wfx]: chaging keyword 'empty' to 'isempty'

[aharvey]

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

 ID: 61021
 Updated by: ahar...@php.net
 Reported by:milevyo at gmail dot com
 Summary:chaging keyword 'empty' to 'isempty'
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:PHP options/info functions
 Operating System:   all
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Given the massive backward compatibility break this would entail for people 
using 
empty(), not to mention the many hits on Koders for PHP code that has declared 
a 
function called isempty(), I don't think there's any feasible way this could be 
done.


Previous Comments:

[2012-02-09 01:01:33] milevyo at gmail dot com

Description:

if (empty($var)){
   ...
}

this has an impression that we are trying freeing up $var and making it 'NULL'
it sound like 'DoEmpty()' or 'SetEmpty()'

but what this function realy is: 
isEmpty()

the script should looks like this:
if(isempty($var)){
   ...
}
because IMHO 'do','set' and 'let' are optional prefixes, which let you 
understand that this function is an order (a command)
but not the prefix 'is' which is if we can say a test prefix.









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

Bug #61020 [Opn]: Security risk from find usage recommendation

[aharvey]

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

 ID: 61020
 Updated by: ahar...@php.net
 Reported by:ond...@php.net
 Summary:Security risk from find usage recommendation
 Status: Open
 Type:   Bug
 Package:*Configuration Issues
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

One problem with all of the options here is that they're a fair way from POSIX 
compliant -- fuser on OS X doesn't support -s, for instance, nor does find 
support -execdir. Solaris find doesn't even support -delete or -print0. 
Obviously this is less of an issue in Debian. :)

Given the (pretty severe) restrictions if we want to cover all of the non-
Windows platforms PHP runs on, do we even want to recommend a one-liner in 
php.ini? Maybe it would be better to come up with a short, portable shell 
script 
and include it in the session reference in the manual and link to that.


Previous Comments:

[2012-02-09 00:41:43] ond...@php.net

s/most error-prone/least error-prone/


[2012-02-09 00:31:44] ond...@php.net

And if you cannot use find with -delete or -execdir at least do:

find /path/to/sessions -mindepth 1 -maxdepth 1 -cmin +24 -execdir rm "{}" \;


[2012-02-09 00:29:10] ond...@php.net

Description:

; NOTE: If you are using the subdirectory option for storing session files
[...]
;  find /path/to/sessions -cmin +24 | xargs rm

because it is prone to '\n' attack. You can see the security
considerations of GNU find.

Much better would be:

find /path/to/sessions -cmin +24 -delete
or at least
find /path/to/sessions -cmin +24 -execdir rm "{}" \; (GNU find)

The most error-prone way is something we cooked up in Debian:

find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f
-ignore_readdir_race -cmin +24 ! -execdir fuser -s {} 2>/dev/null \;
-delete

which depends on fuser at least version 22.15 (which has removed
fork() call which was able to swamp up whole system with zombies).

The fuser call checks if the session file is still in use, because the
script was deleting still active sessions opened 24+ mins ago.


Test script:
---
Race condition for -exec rm {} \;:

while true; do
  mkdir /var/lib/php5/blah
  touch /var/lib/php5/blah/passwd
  rmdir /var/lib/php5/blah
  ln -s /etc /var/lib/php5/blah
done

xargs attack:

ondrej@howl:/tmp/php_sess$ touch bar
ondrej@howl:/tmp/php_sess$ touch -t 20120101 "$(echo -e 'foo\nbar')"
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Feb  9 01:26 bar
-rw-r--r-- 1 ondrej ondrej 0 Jan  1 00:00 foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24
/tmp/php_sess/foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24 | xargs rm
rm: cannot remove `/tmp/php_sess/foo': No such file or directory
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Jan  1 00:00 foo?bar








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

[PHP-BUG] Req #61021 [NEW]: chaging keyword 'empty' to 'isempty'

[milevyo at gmail dot com]

From: 
Operating system: all
PHP version:  Irrelevant
Package:  PHP options/info functions
Bug Type: Feature/Change Request
Bug description:chaging keyword 'empty' to 'isempty'

Description:

if (empty($var)){
   ...
}

this has an impression that we are trying freeing up $var and making it
'NULL'
it sound like 'DoEmpty()' or 'SetEmpty()'

but what this function realy is: 
isEmpty()

the script should looks like this:
if(isempty($var)){
   ...
}
because IMHO 'do','set' and 'let' are optional prefixes, which let you
understand that this function is an order (a command)
but not the prefix 'is' which is if we can say a test prefix.




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

Bug #61010 [Asn->Nab]: Segfault (11) on oci_connect

[sixd]

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

 ID: 61010
 Updated by: s...@php.net
 Reported by:lars at larsdebruin dot net
 Summary:Segfault (11) on oci_connect
-Status: Assigned
+Status: Not a bug
 Type:   Bug
 Package:OCI8 related
 Operating System:   Redhat Linux 6.2
 PHP Version:5.3.10
 Assigned To:sixd
 Block user comment: N
 Private report: N

 New Comment:

Doesn't reproduce for me on Oracle Linux 6.2.  I spent some time
getting as close to your configuration as possible.  I saw no failures
with various scenarios including invalid passwords, invalid connection
strings and expired passwords (https://bugs.php.net/bug.php?id=58477)

$ php -r '$c = oci_connect("cj", "cj", "mymachine/abc");
var_dump($c);' resource(5) of type (oci8 connection)

Some comments:

1. Oracle Instant Client 10.1 is very old.  Unless you need it for a
reason reason, use at least 11.2.
http://www.oracle.com/technetwork/topics/linuxx86-64soft-092277.html

2. Oracle DB & client isn't certified on RHEL 6, so all bets about
behavior are off.

3. Why build only OCI8 shared?

4. The configure line has "--enable-mysqlnd" but none of the MySQL
extension options say to use mysqlnd, so the MySQL client libraries
are still being used.


Previous Comments:

[2012-02-08 13:31:12] lars at larsdebruin dot net

Description:

build:
./configure --with-libxml-dir --enable-bcmath --with-openssl --with-kerberos --
with-zlib --with-bz2 --with-libdir=lib64 --enable-calendar --with-curl --enable-
exif --enable-ftp --with-gd --with-ldap --with-ldap-sasl --enable-mbstring --
with-mcrypt --with-mysql --with-pdo-mysql --with-mysqli --with-
oci8=shared,instantclient,/root/oracle --enable-soap --enable-sockets --with-
gettext --enable-zip --with-mhash --with-pcre-regex --enable-shmop --enable-
sysvmsg --enable-mysqlnd --with-unixODBC --with-apxs2=/usr/sbin/apxs --disable-
cgi

PHPinfo: 
OCI8 Supportenabled
Version 1.4.7
Revision$Revision: 321634 $
Active Persistent Connections   0
Active Connections  0
Oracle Instant Client Version   10.1
Temporary Lob support   enabled
Collections support enabled

Test script:
---


Expected result:

<>: php oracleconnect.php
Segmentation fault (core dumped)

Core dump is NOT generated



Actual result:
--
Core dump is not generated by PHP?






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

Bug #61020 [Opn]: Security risk from find usage recommendation

[ond...@php.net]

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

 ID: 61020
 User updated by:ond...@php.net
 Reported by:ond...@php.net
 Summary:Security risk from find usage recommendation
 Status: Open
 Type:   Bug
 Package:*Configuration Issues
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

s/most error-prone/least error-prone/


Previous Comments:

[2012-02-09 00:31:44] ond...@php.net

And if you cannot use find with -delete or -execdir at least do:

find /path/to/sessions -mindepth 1 -maxdepth 1 -cmin +24 -execdir rm "{}" \;


[2012-02-09 00:29:10] ond...@php.net

Description:

; NOTE: If you are using the subdirectory option for storing session files
[...]
;  find /path/to/sessions -cmin +24 | xargs rm

because it is prone to '\n' attack. You can see the security
considerations of GNU find.

Much better would be:

find /path/to/sessions -cmin +24 -delete
or at least
find /path/to/sessions -cmin +24 -execdir rm "{}" \; (GNU find)

The most error-prone way is something we cooked up in Debian:

find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f
-ignore_readdir_race -cmin +24 ! -execdir fuser -s {} 2>/dev/null \;
-delete

which depends on fuser at least version 22.15 (which has removed
fork() call which was able to swamp up whole system with zombies).

The fuser call checks if the session file is still in use, because the
script was deleting still active sessions opened 24+ mins ago.


Test script:
---
Race condition for -exec rm {} \;:

while true; do
  mkdir /var/lib/php5/blah
  touch /var/lib/php5/blah/passwd
  rmdir /var/lib/php5/blah
  ln -s /etc /var/lib/php5/blah
done

xargs attack:

ondrej@howl:/tmp/php_sess$ touch bar
ondrej@howl:/tmp/php_sess$ touch -t 20120101 "$(echo -e 'foo\nbar')"
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Feb  9 01:26 bar
-rw-r--r-- 1 ondrej ondrej 0 Jan  1 00:00 foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24
/tmp/php_sess/foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24 | xargs rm
rm: cannot remove `/tmp/php_sess/foo': No such file or directory
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Jan  1 00:00 foo?bar








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

Bug #61020 [Opn]: Security risk from find usage recommendation

[ond...@php.net]

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

 ID: 61020
 User updated by:ond...@php.net
 Reported by:ond...@php.net
 Summary:Security risk from find usage recommendation
 Status: Open
 Type:   Bug
 Package:*Configuration Issues
 PHP Version:5.4.0RC7
 Block user comment: N
 Private report: N

 New Comment:

And if you cannot use find with -delete or -execdir at least do:

find /path/to/sessions -mindepth 1 -maxdepth 1 -cmin +24 -execdir rm "{}" \;


Previous Comments:

[2012-02-09 00:29:10] ond...@php.net

Description:

; NOTE: If you are using the subdirectory option for storing session files
[...]
;  find /path/to/sessions -cmin +24 | xargs rm

because it is prone to '\n' attack. You can see the security
considerations of GNU find.

Much better would be:

find /path/to/sessions -cmin +24 -delete
or at least
find /path/to/sessions -cmin +24 -execdir rm "{}" \; (GNU find)

The most error-prone way is something we cooked up in Debian:

find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f
-ignore_readdir_race -cmin +24 ! -execdir fuser -s {} 2>/dev/null \;
-delete

which depends on fuser at least version 22.15 (which has removed
fork() call which was able to swamp up whole system with zombies).

The fuser call checks if the session file is still in use, because the
script was deleting still active sessions opened 24+ mins ago.


Test script:
---
Race condition for -exec rm {} \;:

while true; do
  mkdir /var/lib/php5/blah
  touch /var/lib/php5/blah/passwd
  rmdir /var/lib/php5/blah
  ln -s /etc /var/lib/php5/blah
done

xargs attack:

ondrej@howl:/tmp/php_sess$ touch bar
ondrej@howl:/tmp/php_sess$ touch -t 20120101 "$(echo -e 'foo\nbar')"
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Feb  9 01:26 bar
-rw-r--r-- 1 ondrej ondrej 0 Jan  1 00:00 foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24
/tmp/php_sess/foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24 | xargs rm
rm: cannot remove `/tmp/php_sess/foo': No such file or directory
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Jan  1 00:00 foo?bar








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

Req #61004 [Opn->Wfx]: Add mysql_safe_query

[aharvey]

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

 ID: 61004
 Updated by: ahar...@php.net
 Reported by:pazzo at bahnhof dot se
 Summary:Add mysql_safe_query
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:MySQL related
 Operating System:   Any
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

ext/mysql is deprecated in PHP 5.4 (albeit without actual PHP warnings until 
PHP 
5.5). Migrating to mysqli or PDO is strongly recommended at this time, and the 
legacy MySQL extension won't be receiving new features.


Previous Comments:

[2012-02-08 21:59:43] phpmpan at mpan dot pl

Since people rarely refresh their knowledge, even when they know it's old, 
those links may help realizing that for at least few years there are newer and 
more secure solutions than old mysql extension:
- http://www.php.net/manual/en/book.pdo.php
- http://www.php.net/manual/en/book.mysqli.php


[2012-02-07 15:03:13] pazzo at bahnhof dot se

Description:

Since people are bad at securing their code, even when they know how, this 
function may give securer and more readable code:

mysql_safe_query('UPDATE people SET (name, number) VALUES ? WHERE name = ? or 
?` 
= ?',
 array('new name', 5553475), 'old name', 'custom field', 5);


I've provided an example of how to solve this using php code.

Test script:
---
http://pastebin.com/8EcS9y1B







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

[PHP-BUG] Bug #61020 [NEW]: Security risk from find usage recommendation

[ond...@php.net]

From: ondrej
Operating system: 
PHP version:  5.4.0RC7
Package:  *Configuration Issues
Bug Type: Bug
Bug description:Security risk from find usage recommendation

Description:

; NOTE: If you are using the subdirectory option for storing session files
[...]
;  find /path/to/sessions -cmin +24 | xargs rm

because it is prone to '\n' attack. You can see the security
considerations of GNU find.

Much better would be:

find /path/to/sessions -cmin +24 -delete
or at least
find /path/to/sessions -cmin +24 -execdir rm "{}" \; (GNU find)

The most error-prone way is something we cooked up in Debian:

find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f
-ignore_readdir_race -cmin +24 ! -execdir fuser -s {} 2>/dev/null \;
-delete

which depends on fuser at least version 22.15 (which has removed
fork() call which was able to swamp up whole system with zombies).

The fuser call checks if the session file is still in use, because the
script was deleting still active sessions opened 24+ mins ago.


Test script:
---
Race condition for -exec rm {} \;:

while true; do
  mkdir /var/lib/php5/blah
  touch /var/lib/php5/blah/passwd
  rmdir /var/lib/php5/blah
  ln -s /etc /var/lib/php5/blah
done

xargs attack:

ondrej@howl:/tmp/php_sess$ touch bar
ondrej@howl:/tmp/php_sess$ touch -t 20120101 "$(echo -e 'foo\nbar')"
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Feb  9 01:26 bar
-rw-r--r-- 1 ondrej ondrej 0 Jan  1 00:00 foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24
/tmp/php_sess/foo?bar
ondrej@howl:/tmp/php_sess$ find /tmp/php_sess -mmin +24 | xargs rm
rm: cannot remove `/tmp/php_sess/foo': No such file or directory
ondrej@howl:/tmp/php_sess$ ls -l
total 0
-rw-r--r-- 1 ondrej ondrej 0 Jan  1 00:00 foo?bar



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

Bug #61013 [Opn->Dup]: Php logging to a file now defaults to UTC?

[aharvey]

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

 ID: 61013
 Updated by: ahar...@php.net
 Reported by:mgoebel at emich dot edu
 Summary:Php logging to a file now defaults to UTC?
-Status: Open
+Status: Duplicate
 Type:   Bug
 Package:Date/time related
 Operating System:   Solaris 10, and SLES 11.1
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Duplicate of bug #60723.


Previous Comments:

[2012-02-08 21:05:40] carloschilazo at gmail dot com

The issue was that the local time flag was set to 0, with attached fix the 
local 
time flag is now fixed and the log string now contains the local time instead 
of 
UTC


[2012-02-08 16:20:36] mgoebel at emich dot edu

Description:

I have a pretty generic setup on both Solaris 10 and SLES 11.1, and both setups 
have "date.timezone = America/Detroit" in their php.ini files.  After I 
upgraded from 5.3.8 to 5.3.10 all of the log entries are now using UTC instead 
of the localy defined timezone.

[08-Feb-2012 09:59:38] PHP Deprecated: ...
[08-Feb-2012 09:59:38] PHP Deprecated: ...
[08-Feb-2012 15:00:15 UTC] PHP Deprecated: ... 
[08-Feb-2012 15:00:15 UTC] PHP Deprecated: ... 
[08-Feb-2012 15:00:37 UTC] PHP Warning: ...

All of webpages seem to be handing date/times correctly, just the logging seems 
to be having issues.







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

Bug #47761 [Com]: Since 5.2.9 SoapClient no longer attempts Basic auth to retrieve a WSDL file

[clockw...@php.net]

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

 ID: 47761
 Comment by: clockw...@php.net
 Reported by:marques at displague dot com
 Summary:Since 5.2.9 SoapClient no longer attempts Basic auth
 to retrieve a WSDL file
 Status: No Feedback
 Type:   Bug
 Package:SOAP related
 Operating System:   *
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

Further exploration of this issue, after ensuring everything is running happily 
on https:

Configuring a URI of https://name/path/to/wsdl

and receiving a WSDL with 
https://name:443/path/to/WSDL/bit

... fails to trigger the authentication.

Evidently, "https://name:443"; and "https://name"; are considered different URIs, 
even if they are equivalent.


Previous Comments:

[2012-02-08 05:38:38] clockw...@php.net

See https://gist.github.com/1765797

The WSDL depicted there is behind a load balancer which deals with the SSL bits 
- it's actually served 
over https.

While the initial basic auth works, further requests don't appear to.

I suspect>
 1. WSDL loaded over HTTPS with HTTP Basic Auth
 2. WSDL points to a http address with a port, which is not recognised as the 
same site
 3. A new request is made to grab the xsd bits
 4. The server redirects http to https

Expected:
At step 4, the http basic auth credentials are used

Actual:
SoapFault exception: [WSDL] SOAP-ERROR: Parsing Schema: can't import schema 
from 
'http://*:80/codetable-service/CodeTableService?xsd=3' in settings.php:82
Stack trace:
#0 settings.php(82): SoapClient->SoapClient('https://...', Array)
#1 ettings.php(2): require('...')
#2 {main}

Warning: 
SoapClient::SoapClient(http://:80/codetable-service/CodeTableService?xsd=3) 
[soapclient.soapclient]: failed to open stream: HTTP request failed! HTTP/1.1 
401 Unauthorized in 
settings.php on line 82

Warning: SoapClient::SoapClient() [soapclient.soapclient]: I/O warning : failed 
to load external entity 
"http://:80/codetable-service/CodeTableService?xsd=3"; in settings.php on 
line 82


[2012-02-08 05:31:24] clockw...@php.net

$ php -v
PHP 5.2.17-0.dotdeb.0 with Suhosin-Patch 0.9.7 (cli) (built: Jan  7 2011 
07:47:48)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies

Doing:

 '...',
'password' => '...',
'trace' => 1,
'exceptions' => true,
);
$code_table_client = new RPDesktopCodeTableSoapClient(new SoapClient($wsdl, 
$soapOptions));

The basic auth works for the initial connection, but other components of the 
WSDL that are being referred to don't load the credentials.


[2009-10-07 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


[2009-09-29 11:20:40] sjo...@php.net

Thank you for your bug report.

How did you try to pass the username and password to the SOAP client? Please 
try putting them in the URL, like this:
http://user:p...@www.example.com/service.wsdl


[2009-08-07 03:52:10] marques at displague dot com

One scenario, you are making your own SOAP Server service.  It is  more 
difficult to write a digest auth server than it is to write a basic auth 
server.  Again, consider that PHP web requests are all made as HTTP/1.0 because 
Chunk decoding is not handled properly (or at all) and so Digest, which is 
HTTP/1.1 specific is technically not an option without a good deal of custom 
coding.

Aside from that, I imagine there are just some HTTP/1.0 or Basic only servers 
out there.




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


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

[PHP-BUG] Bug #61019 [NEW]: Out of memory on command stream_get_contents

[sachse at gmx dot net]

From: 
Operating system: Linux testsystem1 3.0
PHP version:  5.3.10
Package:  Streams related
Bug Type: Bug
Bug description:Out of memory on command stream_get_contents

Description:

Very seldom the script works but in most cases it crashes.
Segmentation fault were also seen.
ini_set("memory_limit", "4g"); - does also not help

1st run = OK
All further runs crashes.



Test script:
---
 array("pipe", "r"),  // stdin is a pipe that
the child will read from
  1 => array("pipe", 
"w"),  // stdout is a pipe that
the child will write to
  2 => array("pipe", 
"w")   // stderr is a pipe that the
child will write to
 );
 
  $process=proc_open("echo testtext",$descriptorspec,$pipes);
  if(is_resource($process))
  {
stream_set_blocking($pipes[0],false);
stream_set_blocking($pipes[1],false);
stream_set_blocking($pipes[2],false);
stream_set_write_buffer($pipes[0],0);
stream_set_read_buffer($pipes[1],0);
stream_set_read_buffer($pipes[2],0);
$stdin_stream="";
$stderr_stream="";

echo "External command executed\n"; 
do  
{
  $process_state=proc_get_status($process);
$tmp_stdin=stream_get_contents($pipes[1]);  
  if($tmp_stdin) 
  {
 $stdin_stream=$stdin_stream.$tmp_stdin;
}
$tmp_stderr=stream_get_contents($pipes[2]);
if($tmp_stderr) 
{
  $stderr_stream=$stderr_stream.$tmp_stderr;
}
  sleep(1);
}while($process_state['running']);

echo "External command exit: ".$process_state['exitcode']."\n";

//read outstanding data
$tmp_stdin=stream_get_contents($pipes[1]);  
  if($tmp_stdin) 
  {
 $stdin_stream=$stdin_stream.$tmp_stdin;
}
$tmp_stderr=stream_get_contents($pipes[2]);
if($tmp_stderr) 
{
  $stderr_stream=$stderr_stream.$tmp_stderr;
}

fclose ($pipes[0]);
fclose ($pipes[1]);
fclose ($pipes[2]);
  
proc_close($process);

echo "STDOUT: ".$stdin_stream."\n";
echo "STDERR: ".$stderr_stream."\n";
  }
  else
  {
echo "Can't start external command\n";
  } 
?>


Expected result:

External command executed
External command exit: 0
STDOUT: testtext

STDERR: 

Actual result:
--
External command executed
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried
to allocate 133431296 bytes) in
/var/www/localhost/htdocs/jobmanager/runcmd.php on line 23

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 133431296 bytes) in
/var/www/localhost/htdocs/jobmanager/runcmd.php on line 23

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

Req #61004 [Com]: Add mysql_safe_query

[phpmpan at mpan dot pl]

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

 ID: 61004
 Comment by: phpmpan at mpan dot pl
 Reported by:pazzo at bahnhof dot se
 Summary:Add mysql_safe_query
 Status: Open
 Type:   Feature/Change Request
 Package:MySQL related
 Operating System:   Any
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Since people rarely refresh their knowledge, even when they know it's old, 
those links may help realizing that for at least few years there are newer and 
more secure solutions than old mysql extension:
- http://www.php.net/manual/en/book.pdo.php
- http://www.php.net/manual/en/book.mysqli.php


Previous Comments:

[2012-02-07 15:03:13] pazzo at bahnhof dot se

Description:

Since people are bad at securing their code, even when they know how, this 
function may give securer and more readable code:

mysql_safe_query('UPDATE people SET (name, number) VALUES ? WHERE name = ? or 
?` 
= ?',
 array('new name', 5553475), 'old name', 'custom field', 5);


I've provided an example of how to solve this using php code.

Test script:
---
http://pastebin.com/8EcS9y1B







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

Bug #61013 [Com]: Php logging to a file now defaults to UTC?

[carloschilazo at gmail dot com]

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

 ID: 61013
 Comment by: carloschilazo at gmail dot com
 Reported by:mgoebel at emich dot edu
 Summary:Php logging to a file now defaults to UTC?
 Status: Open
 Type:   Bug
 Package:Date/time related
 Operating System:   Solaris 10, and SLES 11.1
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

The issue was that the local time flag was set to 0, with attached fix the 
local 
time flag is now fixed and the log string now contains the local time instead 
of 
UTC


Previous Comments:

[2012-02-08 16:20:36] mgoebel at emich dot edu

Description:

I have a pretty generic setup on both Solaris 10 and SLES 11.1, and both setups 
have "date.timezone = America/Detroit" in their php.ini files.  After I 
upgraded from 5.3.8 to 5.3.10 all of the log entries are now using UTC instead 
of the localy defined timezone.

[08-Feb-2012 09:59:38] PHP Deprecated: ...
[08-Feb-2012 09:59:38] PHP Deprecated: ...
[08-Feb-2012 15:00:15 UTC] PHP Deprecated: ... 
[08-Feb-2012 15:00:15 UTC] PHP Deprecated: ... 
[08-Feb-2012 15:00:37 UTC] PHP Warning: ...

All of webpages seem to be handing date/times correctly, just the logging seems 
to be having issues.







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

Bug #52376 [Com]: opendir() cannot open UNC paths in IIS7 using passthrough auth.

[mike dot riendeau at gmail dot com]

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

 ID: 52376
 Comment by: mike dot riendeau at gmail dot com
 Reported by:ryan at kisc dot edu dot np
 Summary:opendir() cannot open UNC paths in IIS7 using
 passthrough auth.
 Status: Assigned
 Type:   Bug
 Package:*Directory/Filesystem functions
 Operating System:   win64 - W2008R2
 PHP Version:5.3.2
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

I fixed this in Win7 IIS7 Through the inetmgr.
WebSite->Authentication->Anonymous Authentication (edit on side panel)
I changed the Specific User (IUSR) to Application pool identity.
I am only using it for local development, so I'm not sure how this affects 
security.


Previous Comments:

[2011-10-13 09:57:29] em at ducommun dot ch

I have exactly the same problem.

I have tried to map the share to a letter, exemple Z:/ same result.
This is not a permissions problem.

Please help.

Config: xampp running under w2k3r2 server, with php 5.3.5

Thanks!


[2011-08-05 15:14:58] marc dot seitz at ww-informatik dot de

Hi Guys,

we have exactly the same problem now.
We want to migrate to Windows Server 2008 R2 with IIS 7.5, FastCGI, PHP 5.3.6.

When I try to do a file_get_contents() or opendir() I 
always will get the error:
Warning: fopen(): failed to open stream: Permission denied in 
D:\inetpub\wwwroot\XXX.php on line 26

The Application-Pools of the IIS are running under a Domain-Account which has 
access to the Network Share.

I don't know how to solve this problem.

Any ideas of you?

Thanks 
Marc


[2011-01-13 04:24:50] mark at internode dot on dot net

Hi I am having the same problem with PHP 5.3.5 running under IIS 7.5, FastCGI, 
Windows Server 2008 R2 where I am simply trying to access a file on another 
server using a UNC path.

$uploadfile = "\.txt";
$fh = fopen($uploadfile, 'r') or die("Can't open file $uploadfile");

I have tried granting "everyone" full permissions for the share and the file 
system but it still does not work.

This code works perfectly if the file is stored on the same server and is 
accessed through a local path.

Other things I have tried inlcude:
- setting the defaultappool to use a specific user and granting that user 
permissions on the share and file system
- using "network" as above

Any other ideas on this one?


[2010-07-20 04:42:43] ahar...@php.net

(Restoring status.)

As a fellow Chrome user, I feel your pain. :)


[2010-07-20 04:08:58] ryan at kisc dot edu dot np

sorry about the line breaks, apparently this site doesn't like what Chrome does 
when I resize the text box. I'll be more careful in the future. Actually this 
site seems to hate Chrome altogether. 
I keep getting "incorrect username" constantly. The bug site is buggy, at least 
in Chrome.




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


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

Bug #61014 [Com]: Memory leak on unserialize for certain nested objects

[carloschilazo at gmail dot com]

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

 ID: 61014
 Comment by: carloschilazo at gmail dot com
 Reported by:npm at nuestrared dot com
 Summary:Memory leak on unserialize for certain nested
 objects
 Status: Open
 Type:   Bug
 Package:Performance problem
 Operating System:   Debian Linux
 PHP Version:5.4SVN-2012-02-08 (snap)
 Block user comment: N
 Private report: N

 New Comment:

I'm not sure the problem is on the unserialize function;

I saved the value of $str (after gzuncompress/base64_decode) (so I got the 
original serialized string, and hardcoded it on the script)

Then ran the script and got consistent memory usage...


Previous Comments:

[2012-02-08 16:24:02] npm at nuestrared dot com

Description:

Unserializing certain objects on a loop, incurs in increased memory consumption 
even when the garbage collector is enables and gc_collect_cycles() is called 
after each iteration.  

For the test script there is an increase of almost 5MB, after 100 runs, it 
doesn't happen with every object, but it does with the one on the test. 
The increase is not with every iteration but every couple of iterations, until 
it 
reaches a maximum, in this case the 4980736 bytes.

This report is related to bug #60937, I had no reply on my comments.
Thanks,

Test script:
---
The test script can be found at:
http://dl.dropbox.com/u/7170408/unserialize_memleak.php

Expected result:

Consistent memory usage.

Actual result:
--
The output of the script:

Iteration 0  Start Mem 786432 Cicle Mem 3145728 Diff 2359296
Iteration 1  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 2  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 3  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 4  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 5  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 6  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 7  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 8  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 9  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 10 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 11 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 12 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 13 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 14 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 15 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 16 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 17 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 18 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 19 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 20 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 21 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 22 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 23 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 24 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 25 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 26 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 27 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 28 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 29 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 30 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 31 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 32 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 33 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 34 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 35 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 36 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 37 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 38 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 39 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 40 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 41 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 42 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 43 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 44 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 45 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 46 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 47 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 48 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 49 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 50 Start Mem 786

Bug #61012 [Nab]: filter_var don't pass valid email address

[rasmus]

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

 ID: 61012
 Updated by: ras...@php.net
 Reported by:sucotronic at gmail dot com
 Summary:filter_var don't pass valid email address
 Status: Not a bug
 Type:   Bug
 Package:Mail related
 Operating System:   linux ubuntu 10.04
 PHP Version:5.3SVN-2012-02-08 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Yes, this was fixed in July 2010 in 5.3.3.


Previous Comments:

[2012-02-08 18:12:10] anon at anon dot anon

I also get false, using PHP 5.3.2/Windows.

But according to the change log, FILTER_VALIDATE_EMAIL was overhauled in PHP 
5.3.3, in July 2010, after this bug report: 
https://bugs.php.net/bug.php?id=49576


[2012-02-08 17:55:28] sucotronic at gmail dot com

More exactly, my version is: 5.3.2-1ubuntu4.11


[2012-02-08 16:49:29] ras...@php.net

Unable to reproduce in 5.3/5.4:

php > echo filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL);
+4654651...@test.com

Make sure you are actually trying this in 5.3. This may have been broken in 
5.2, 
but was fixed years ago in 5.3.


[2012-02-08 14:58:45] sucotronic at gmail dot com

Description:

If you use the filter_var function to test an email address, and the address 
starts with the '+' sign, it's marked as invalid, but it isn't.

Test script:
---
filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL)

Expected result:

Return the string and not false.

Actual result:
--
false






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

[PHP-BUG] Bug #61018 [NEW]: Unexplained bool(false) returned from preg_match

[dey101+php at gmail dot com]

From: 
Operating system: Windows Server 2008
PHP version:  5.3.10
Package:  PCRE related
Bug Type: Bug
Bug description:Unexplained bool(false) returned from preg_match

Description:

PHP VC9 x86 Thread Safe (from http://windows.php.net/download/)

Using a regex to validate if a string is a valid hostname (host or FQDN).

It seems that for certain length strings trying to match a literal period
at the end will cause the preg_match to return false if the string does not
have a period in it. It also will return false if the string has a period
at the end, and the regex does not try to match them.

The regex is using subpatterns ()to apply the zero or more repetition
quantifier *. I tried with both capturing and non-capturing (?:), both
yield the same result. However, if I use the one or more quantifier + it
does not return bool(false). Using {0,} instead of * does not change the
outcome.

It seems that the cutoff length for the string is about 20 characters. Less
than that, the results are int(0) or int(1) depending on if the regex
matches, longer than that, and bool(false) is returned.

If the subpattern is part of a longer string, it does work as anticipated.

Matching a literal period at the beginning of the pattern does not yield an
error.

Substituting a-zA-Z0-9 for the [:alnum:] character class does not affect
the results.

error_get_last() does not return anything, nothing is showing up in logs
with error_reporting(-1) set either.

Test script:
---
$regexs = array
(
'/^[[:alnum:]](?:[[:alnum:]\-]*[[:alnum:]])*$/',
'/^(?:[[:alnum:]](?:[[:alnum:]\-]*[[:alnum:]])*\.)*$/',
'/^(?:[[:alnum:]](?:[[:alnum:]\-]*[[:alnum:]])*\.)+$/',

'/^(?:[[:alnum:]](?:[[:alnum:]\-]*[[:alnum:]])*\.)*[[:alnum:]](?:[[:alnum:]\-]*[[:alnum:]])*$/'
);

$hosts = array
(
'ABCDEFGHIJ1234567890.', // long string with period at end
'ABCDEFGHI234567890.', // slightly shorter string with period at end
'ABCDEFGHIJ1234567890', // long string no period
'ABCDEFGHI1234567890', // a little shorter
'ABCDEFGHI123456789', // even shorter
'ABCDEFGHIJ-1234567890', // long with hyphen
'ABCDEFGHIJ-123456789', // sorter with hyphen
'ABCDEFGHI-123456789', // even shorter with hyphen
'WWW.ABCDEFGHIJ-1234567890.COM', // a FQDN with long sting and hyphen

'WWW.SUB-SUBDOMAIN.SUBDOMAIN.ABCD-EFGH-IJKL-MNOP-QRST-UVWX-YZ-12345-67890-abcd-efgh-hijk.COM'
// a really long FQDN
);

foreach ($regexs as $regex)
{
echo "\nRegex: $regex\n";

foreach ($hosts as $host)
{
echo "  Host: $host\n";

$result = preg_match($regex, $host);

echo 'Result: ';
if ($result === false)
{
echo '(error) ';
print_r(error_get_last()); // never prints anything?
}
else
{
echo ($result) ? '(match) ' : '(no match) ';
}

var_dump($result);
}
}

Expected result:

none of the results should yield bool(false)

Actual result:
--
// just the output from the last regex, but others yield bool(false)
Regex:
/^(?:[[:alnum:]](?:[[:alnum:]\-]*[[:alnum:]])*\.)*[[:alnum:]](?:[[:alnum:]\-]*[[:alnum:]])*$/
  Host: ABCDEFGHIJ1234567890.
Result: (error) bool(false)
  Host: ABCDEFGHI234567890.
Result: (error) bool(false)
  Host: .ABCDEFGHIJ1234567890
Result: (no match) int(0)
  Host: ABCDEFGHIJ1234567890
Result: (error) bool(false)
  Host: ABCDEFGHI1234567890
Result: (error) bool(false)
  Host: ABCDEFGHI123456789
Result: (match) int(1)
  Host: ABCDEFGHIJ-1234567890
Result: (error) bool(false)
  Host: ABCDEFGHIJ-123456789
Result: (error) bool(false)
  Host: ABCDEFGHI-123456789
Result: (match) int(1)
  Host: WWW.ABCDEFGHIJ-1234567890.COM
Result: (match) int(1)
  Host:
WWW.SUB-SUBDOMAIN.SUBDOMAIN.ABCD-EFGH-IJKL-MNOP-QRST-UVWX-YZ-12345-67890-abcd-efgh-hijk.COM
Result: (match) int(1)

-- 
Edit bug report at https://bugs.php.net/bug.php?id=61018&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61018&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61018&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=61018&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61018&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=61018&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61018&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=61018&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=61018&r=needscript
Try newer version:   
https://bugs.php.net/

Bug #61012 [Com]: filter_var don't pass valid email address

[anon at anon dot anon]

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

 ID: 61012
 Comment by: anon at anon dot anon
 Reported by:sucotronic at gmail dot com
 Summary:filter_var don't pass valid email address
 Status: Not a bug
 Type:   Bug
 Package:Mail related
 Operating System:   linux ubuntu 10.04
 PHP Version:5.3SVN-2012-02-08 (snap)
 Block user comment: N
 Private report: N

 New Comment:

I also get false, using PHP 5.3.2/Windows.

But according to the change log, FILTER_VALIDATE_EMAIL was overhauled in PHP 
5.3.3, in July 2010, after this bug report: 
https://bugs.php.net/bug.php?id=49576


Previous Comments:

[2012-02-08 17:55:28] sucotronic at gmail dot com

More exactly, my version is: 5.3.2-1ubuntu4.11


[2012-02-08 16:49:29] ras...@php.net

Unable to reproduce in 5.3/5.4:

php > echo filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL);
+4654651...@test.com

Make sure you are actually trying this in 5.3. This may have been broken in 
5.2, 
but was fixed years ago in 5.3.


[2012-02-08 14:58:45] sucotronic at gmail dot com

Description:

If you use the filter_var function to test an email address, and the address 
starts with the '+' sign, it's marked as invalid, but it isn't.

Test script:
---
filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL)

Expected result:

Return the string and not false.

Actual result:
--
false






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

Bug #61012 [Nab]: filter_var don't pass valid email address

[sucotronic at gmail dot com]

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

 ID: 61012
 User updated by:sucotronic at gmail dot com
 Reported by:sucotronic at gmail dot com
 Summary:filter_var don't pass valid email address
 Status: Not a bug
 Type:   Bug
 Package:Mail related
 Operating System:   linux ubuntu 10.04
 PHP Version:5.3SVN-2012-02-08 (snap)
 Block user comment: N
 Private report: N

 New Comment:

More exactly, my version is: 5.3.2-1ubuntu4.11


Previous Comments:

[2012-02-08 16:49:29] ras...@php.net

Unable to reproduce in 5.3/5.4:

php > echo filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL);
+4654651...@test.com

Make sure you are actually trying this in 5.3. This may have been broken in 
5.2, 
but was fixed years ago in 5.3.


[2012-02-08 14:58:45] sucotronic at gmail dot com

Description:

If you use the filter_var function to test an email address, and the address 
starts with the '+' sign, it's marked as invalid, but it isn't.

Test script:
---
filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL)

Expected result:

Return the string and not false.

Actual result:
--
false






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

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

[mmoreno at pobox dot com]

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

 ID: 60758
 Comment by: mmoreno at pobox dot com
 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:

I too am experiencing this same problem on 5.3.10 running on Windows 2008 SP2.  
I have also confirmed that this is crashing when trying to include() a file 
that happens to be exactly 4096 bytes.

Can you explain how this is "has already been fixed" and/or "is a different 
issue"?  Am I missing something?  Unfortunately, I don't have the means to 
build and test a snapshot.


Full Call Stack



Function Arg 1 Arg 2 Arg 3 Arg 4   Source 
php5ts!lex_scan+d12 0363e348 027adb48 027adb48 0363e374   
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_language_scanner.c @ 2507 + 
12 
php5ts!zendlex+4e 0363e340 027adb48 06826510 027adb48   
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_compile.c @ 4975 + b 
php5ts!zendparse+1d4 027adb48 06826510 0002 0040   
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_language_parser.c @ 3285 + 
b 
php5ts!compile_file+e4 0363f99c 0008 027adb00 027adb48   
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_language_scanner.l @ 365 
php5ts!phar_compile_file+1e6 0363f99c 0008 027adb48 
027adb48   c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\ext\phar\phar.c @ 3393 + 
1b 
php5ts!ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER+251 040d6eb8 0363fab4 
027adb48 03b70124   
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 22510 
php5ts!execute+2e8 041e7fb0 027adb01 027adb48 052690a0   
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 107 + a 
php5ts!zend_call_function+862  0363faa0 03b70280 
   c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_execute_api.c @ 
969 + 1b 
php5ts!zif_call_user_func_array+63 0002 06623018  
   
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\ext\standard\basic_functions.c @ 4803 
+ 18 
php5ts!zend_do_fcall_common_helper_SPEC+920 03b70280 027adb00 
027adb48 03b70280   
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 320 + 41 
php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+11a 027adb48 0363fbb8 
 0363fe44   
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 1640 + e 
php5ts!execute+2e8 03b3e5e0 027adb00 027adb48    
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend_vm_execute.h @ 107 + a 
php5ts!zend_execute_scripts+fe 0008 027adb48  
0003   c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\zend\zend.c @ 1237 
php5ts!php_execute_script+24c 0363fe44 027adb48 0005 
018a416c   c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\main\main.c @ 2308 + 12 
php5apache2_2!php_handler+634 0268f050 0268f050 018a4ce0 
6eecd540   
c:\php-sdk\snap_5_3\vc9\x86\php-5.3.10-ts\sapi\apache2handler\sapi_apache2.c @ 
669 + e 
libhttpd!ap_run_handler+25


Previous Comments:

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

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


[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 * fi

Req #61017 [Opn->Fbk]: ~ in include_path

[rasmus]

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

 ID: 61017
 Updated by: ras...@php.net
 Reported by:spamik at yum dot pl
 Summary:~ in include_path
-Status: Open
+Status: Feedback
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

How would that work? Generally the web server will run as some generic user, so 
~ 
and $LOGIN will not have a meaningful value.


Previous Comments:

[2012-02-08 17:21:02] spamik at yum dot pl

Description:

include_path needs something for home directory or username substitution. 
Without 
it tens of tousands of unmanagable php.ini specific to every username are 
needed.

in php.ini
include_path = ".:~/pear/php/"
or
include_path = ".:/home/$LOGIN/pear/php/"










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

Bug #61016 [Nab]: ZEND_EXTENSION_API_NO typo

[rasmus]

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

 ID: 61016
 Updated by: ras...@php.net
 Reported by:jbnance at tresgeek dot net
 Summary:ZEND_EXTENSION_API_NO typo
 Status: Not a bug
 Type:   Bug
 Package:Dynamic loading
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

The comment in the code just above that #define is:

/* The first number is the engine version and the rest is the date.
 * This way engine 2/3 API no. is always greater than engine 1 API no..
 */


Previous Comments:

[2012-02-08 17:21:09] der...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

No, it's correct. The first 2 is for "zend engine 2".


[2012-02-08 17:10:15] jbnance at tresgeek dot net

Description:

There appears to be a typo in the version number for the ZEND_EXTENSION_API_NO:

Zend/zend_extensions.h:#define ZEND_EXTENSION_API_NO  220090626

I believe that is supposed to be "20090626".

Patch included.







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

Bug #61016 [Opn->Nab]: ZEND_EXTENSION_API_NO typo

[derick]

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

 ID: 61016
 Updated by: der...@php.net
 Reported by:jbnance at tresgeek dot net
 Summary:ZEND_EXTENSION_API_NO typo
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Dynamic loading
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

No, it's correct. The first 2 is for "zend engine 2".


Previous Comments:

[2012-02-08 17:10:15] jbnance at tresgeek dot net

Description:

There appears to be a typo in the version number for the ZEND_EXTENSION_API_NO:

Zend/zend_extensions.h:#define ZEND_EXTENSION_API_NO  220090626

I believe that is supposed to be "20090626".

Patch included.







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

[PHP-BUG] Req #61017 [NEW]: ~ in include_path

[spamik at yum dot pl]

From: 
Operating system: 
PHP version:  5.3.10
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:~ in include_path

Description:

include_path needs something for home directory or username substitution.
Without 
it tens of tousands of unmanagable php.ini specific to every username are
needed.

in php.ini
include_path = ".:~/pear/php/"
or
include_path = ".:/home/$LOGIN/pear/php/"





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

[PHP-BUG] Bug #61016 [NEW]: ZEND_EXTENSION_API_NO typo

[jbnance at tresgeek dot net]

From: 
Operating system: 
PHP version:  5.3.10
Package:  Dynamic loading
Bug Type: Bug
Bug description:ZEND_EXTENSION_API_NO typo

Description:

There appears to be a typo in the version number for the
ZEND_EXTENSION_API_NO:

Zend/zend_extensions.h:#define ZEND_EXTENSION_API_NO  220090626

I believe that is supposed to be "20090626".

Patch included.


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

Bug #61012 [Opn->Nab]: filter_var don't pass valid email address

[rasmus]

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

 ID: 61012
 Updated by: ras...@php.net
 Reported by:sucotronic at gmail dot com
 Summary:filter_var don't pass valid email address
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Mail related
 Operating System:   linux ubuntu 10.04
 PHP Version:5.3SVN-2012-02-08 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Unable to reproduce in 5.3/5.4:

php > echo filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL);
+4654651...@test.com

Make sure you are actually trying this in 5.3. This may have been broken in 
5.2, 
but was fixed years ago in 5.3.


Previous Comments:

[2012-02-08 14:58:45] sucotronic at gmail dot com

Description:

If you use the filter_var function to test an email address, and the address 
starts with the '+' sign, it's marked as invalid, but it isn't.

Test script:
---
filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL)

Expected result:

Return the string and not false.

Actual result:
--
false






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

[PHP-BUG] Bug #61014 [NEW]: Memory leak on unserialize for certain nested objects

[npm at nuestrared dot com]

From: 
Operating system: Debian Linux
PHP version:  5.4SVN-2012-02-08 (snap)
Package:  Performance problem
Bug Type: Bug
Bug description:Memory leak on unserialize for certain nested objects

Description:

Unserializing certain objects on a loop, incurs in increased memory
consumption 
even when the garbage collector is enables and gc_collect_cycles() is
called 
after each iteration.  

For the test script there is an increase of almost 5MB, after 100 runs, it

doesn't happen with every object, but it does with the one on the test. 
The increase is not with every iteration but every couple of iterations,
until it 
reaches a maximum, in this case the 4980736 bytes.

This report is related to bug #60937, I had no reply on my comments.
Thanks,

Test script:
---
The test script can be found at:
http://dl.dropbox.com/u/7170408/unserialize_memleak.php

Expected result:

Consistent memory usage.

Actual result:
--
The output of the script:

Iteration 0  Start Mem 786432 Cicle Mem 3145728 Diff 2359296
Iteration 1  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 2  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 3  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 4  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 5  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 6  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 7  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 8  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 9  Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 10 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 11 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 12 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 13 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 14 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 15 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 16 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 17 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 18 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 19 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 20 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 21 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 22 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 23 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 24 Start Mem 786432 Cicle Mem 5505024 Diff 4718592
Iteration 25 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 26 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 27 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 28 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 29 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 30 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 31 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 32 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 33 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 34 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 35 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 36 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 37 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 38 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 39 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 40 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 41 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 42 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 43 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 44 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 45 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 46 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 47 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 48 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 49 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 50 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 51 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 52 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 53 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 54 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 55 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 56 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 57 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 58 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 59 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
Iteration 60 Start Mem 786432 Cicle Mem 5767168 Diff 4980736
It

[PHP-BUG] Bug #61013 [NEW]: Php logging to a file now defaults to UTC?

[mgoebel at emich dot edu]

From: 
Operating system: Solaris 10, and SLES 11.1
PHP version:  5.3.10
Package:  Date/time related
Bug Type: Bug
Bug description:Php logging to a file now defaults to UTC?

Description:

I have a pretty generic setup on both Solaris 10 and SLES 11.1, and both
setups have "date.timezone = America/Detroit" in their php.ini files. 
After I upgraded from 5.3.8 to 5.3.10 all of the log entries are now using
UTC instead of the localy defined timezone.

[08-Feb-2012 09:59:38] PHP Deprecated: ...
[08-Feb-2012 09:59:38] PHP Deprecated: ...
[08-Feb-2012 15:00:15 UTC] PHP Deprecated: ... 
[08-Feb-2012 15:00:15 UTC] PHP Deprecated: ... 
[08-Feb-2012 15:00:37 UTC] PHP Warning: ...

All of webpages seem to be handing date/times correctly, just the logging
seems to be having issues.


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

Bug #61011 [Com]: Crash when an exception is thrown by __autoload accessing a static property

[larue...@php.net]

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

 ID: 61011
 Comment by: larue...@php.net
 Reported by:ahar...@php.net
 Summary:Crash when an exception is thrown by __autoload
 accessing a static property
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   OSX 10.6.8 & Linux
 PHP Version:5.4SVN-2012-02-08 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

I am not sure whether the patch is okey(it seems related to CACHE mechanism). 
anyway the patch will show where the problem comes from. 

Dmitry, could plz look at this?  thanks .


Previous Comments:

[2012-02-08 16:05:58] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.phpt
Revision:   1328717158
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328717158


[2012-02-08 16:05:36] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.patch
Revision:   1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135


[2012-02-08 14:47:27] ahar...@php.net

Description:

I get a reproducible crash on PHP_5_4 and trunk when accessing a static 
property 
on a non-existent class with an autoloader registered if the __autoload() 
function 
throws an exception.

PHP_5_3 doesn't crash, and throws an exception as expected.

Test script:
---
http://gnu.org/licenses/gpl.html>
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 "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php 
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php 
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object... 
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54  if (ht->inconsistent==HT_OK) {
(gdb) bt
#0  0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1  0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40 "property", 
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2  0x083f1711 in zend_std_get_static_property (ce=0x0, 
property_name=0xb7b60d40 
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3  0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0, 
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4  0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER 
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5  0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6  0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7  0x08348b0e in php_execute_script (primary_file=0xb518) at 
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8  0x084da44e in do_cli (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:983
#9  0x084db492 in main (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:1356
(gdb) 






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

Bug #61011 [PATCH]: Crash when an exception is thrown by __autoload accessing a static property

[larue...@php.net]

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

 ID: 61011
 Patch added by: larue...@php.net
 Reported by:ahar...@php.net
 Summary:Crash when an exception is thrown by __autoload
 accessing a static property
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   OSX 10.6.8 & Linux
 PHP Version:5.4SVN-2012-02-08 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug61011.phpt
Revision:   1328717158
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328717158


Previous Comments:

[2012-02-08 16:05:36] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61011.patch
Revision:   1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135


[2012-02-08 14:47:27] ahar...@php.net

Description:

I get a reproducible crash on PHP_5_4 and trunk when accessing a static 
property 
on a non-existent class with an autoloader registered if the __autoload() 
function 
throws an exception.

PHP_5_3 doesn't crash, and throws an exception as expected.

Test script:
---
http://gnu.org/licenses/gpl.html>
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 "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php 
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php 
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object... 
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54  if (ht->inconsistent==HT_OK) {
(gdb) bt
#0  0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1  0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40 "property", 
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2  0x083f1711 in zend_std_get_static_property (ce=0x0, 
property_name=0xb7b60d40 
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3  0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0, 
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4  0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER 
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5  0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6  0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7  0x08348b0e in php_execute_script (primary_file=0xb518) at 
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8  0x084da44e in do_cli (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:983
#9  0x084db492 in main (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:1356
(gdb) 






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

Bug #61011 [PATCH]: Crash when an exception is thrown by __autoload accessing a static property

[larue...@php.net]

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

 ID: 61011
 Patch added by: larue...@php.net
 Reported by:ahar...@php.net
 Summary:Crash when an exception is thrown by __autoload
 accessing a static property
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   OSX 10.6.8 & Linux
 PHP Version:5.4SVN-2012-02-08 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug61011.patch
Revision:   1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135


Previous Comments:

[2012-02-08 14:47:27] ahar...@php.net

Description:

I get a reproducible crash on PHP_5_4 and trunk when accessing a static 
property 
on a non-existent class with an autoloader registered if the __autoload() 
function 
throws an exception.

PHP_5_3 doesn't crash, and throws an exception as expected.

Test script:
---
http://gnu.org/licenses/gpl.html>
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 "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php 
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php 
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object... 
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54  if (ht->inconsistent==HT_OK) {
(gdb) bt
#0  0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1  0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40 "property", 
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2  0x083f1711 in zend_std_get_static_property (ce=0x0, 
property_name=0xb7b60d40 
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3  0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0, 
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4  0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER 
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5  0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6  0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7  0x08348b0e in php_execute_script (primary_file=0xb518) at 
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8  0x084da44e in do_cli (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:983
#9  0x084db492 in main (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:1356
(gdb) 






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

[PHP-BUG] Bug #61012 [NEW]: filter_var don't pass valid email address

[sucotronic at gmail dot com]

From: 
Operating system: linux ubuntu 10.04
PHP version:  5.3SVN-2012-02-08 (snap)
Package:  Mail related
Bug Type: Bug
Bug description:filter_var don't pass valid email address

Description:

If you use the filter_var function to test an email address, and the
address 
starts with the '+' sign, it's marked as invalid, but it isn't.

Test script:
---
filter_var("+4654651...@test.com", FILTER_VALIDATE_EMAIL)

Expected result:

Return the string and not false.

Actual result:
--
false

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

[PHP-BUG] Bug #61011 [NEW]: Crash when an exception is thrown by __autoload accessing a static property

[ahar...@php.net]

From: aharvey
Operating system: OSX 10.6.8 & Linux
PHP version:  5.4SVN-2012-02-08 (SVN)
Package:  Reproducible crash
Bug Type: Bug
Bug description:Crash when an exception is thrown by __autoload accessing a 
static property

Description:

I get a reproducible crash on PHP_5_4 and trunk when accessing a static
property 
on a non-existent class with an autoloader registered if the __autoload()
function 
throws an exception.

PHP_5_3 doesn't crash, and throws an exception as expected.

Test script:
---
http://gnu.org/licenses/gpl.html>
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 "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php 
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php 
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object... 
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at

/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54  if (ht->inconsistent==HT_OK) {
(gdb) bt
#0  0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748 
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at

/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1  0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40
"property", 
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2  0x083f1711 in zend_std_get_static_property (ce=0x0,
property_name=0xb7b60d40 
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3  0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0, 
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4  0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER 
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5  0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6  0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at 
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7  0x08348b0e in php_execute_script (primary_file=0xb518) at 
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8  0x084da44e in do_cli (argc=2, argv=0xb7a4) at
/home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:983
#9  0x084db492 in main (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:1356
(gdb) 

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

Bug #61000 [Opn]: Exceeding max nesting level doesn't delete numerical vars

[laruence]

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

 ID: 61000
 Updated by: larue...@php.net
 Reported by:cataphr...@php.net
 Summary:Exceeding max nesting level doesn't delete numerical
 vars
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Irrelevant
 PHP Version:trunk-SVN-2012-02-07 (snap)
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

fixed in 5.3, trunk. will close this when I commit to 5.4 after 5.4 release. 
thanks


Previous Comments:

[2012-02-08 14:07:28] larue...@php.net

Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&revision=323123
Log: Fixed bug #61000 (Exceeding max nesting level doesn't delete numerical 
vars).


[2012-02-08 06:10:48] larue...@php.net

I am wondering that was there a disscussion about how to fix this? seems 
replace 
zend_hash_del with zend_symbol_del will solve this issue. 

since it is so suspicious(seems too easy), so I attached my fix.

 I was wondering is there already a discussion about how to fix it ?  
if not, I think zend_symbol_del will works
 I think Catahract already had a fix, didn't he?
 it was probably just that though

thanks


[2012-02-08 06:08:12] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61000.patch
Revision:   1328681292
URL:
https://bugs.php.net/patch-display.php?bug=61000&patch=bug61000.patch&revision=1328681292


[2012-02-07 09:45:58] cataphr...@php.net

Description:

Exceeding the max nesting level doesn't delete numerical vars, while it deletes 
the non-numerical ones. php_register_variable_ex inappropriately uses 
zend_hash_del.

(Found out by Stefan Esser, who points this can be used, together with 
max_input_vars, to determine whether PHP is a 32-bit or 64-bit process)

Test script:
---
With max nesting level=2:

http://nebm.ist.utl.pt/phpinfo?1[a][]=foo&1[a][b][c]=bar



Expected result:

_GET is empty

Actual result:
--
_GET["1"] =
Array
(
[a] => Array
(
[0] => foo
)

)






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

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

[thijsputman at gmail dot com]

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

 ID: 60879
 User updated by:thijsputman at gmail dot com
 Reported by:thijsputman at gmail dot com
 Summary:unserialize() Does not invoke __wakeup() on object
 Status: Assigned
 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:

The configure commands between RC7-dev (which works properly) and RC7 (which 
exhibits the problem) seem to differ a bit, could that be the cause?

RC7 contains the following elements not contained in RC7-dev:
--disable-nsapi --with-enchant=shared --disable-static-analyze --with-pgo

RC7-dev contains the following not contained in RC7:
--enable-object-out-dir=d:/temp/obj/nts-windows-vc9-x86

Also, there seems to be a small typo in the RC7-dev configure command:
"--enable-snapshot-build --disable-zts --disable-isapi --enable-debug-pack 
--disable-isapi" 

ISAPI is disabled twice (I'm guessing the second one should be nsapi?)


Previous Comments:

[2012-02-08 13:46:27] thijsputman at gmail dot com

Just tried with RC7 (VC9 x86 Non Thread Safe - 2012-Feb-06 23:40:37) and the 
problem has reappeared...


[2012-02-06 13:44:29] yoozer at gmail dot com

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


[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?




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


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

Bug #60879 [Csd->Asn]: unserialize() Does not invoke __wakeup() on object

[thijsputman at gmail dot com]

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

 ID: 60879
 User updated by:thijsputman at gmail dot com
 Reported by:thijsputman at gmail dot com
 Summary:unserialize() Does not invoke __wakeup() on object
-Status: Closed
+Status: Assigned
 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:

Just tried with RC7 (VC9 x86 Non Thread Safe - 2012-Feb-06 23:40:37) and the 
problem has reappeared...


Previous Comments:

[2012-02-06 13:44:29] yoozer at gmail dot com

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


[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

Bug #61009 [Nab]: max_input_vars

[j dot hensoldt at gmx dot de]

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

 ID: 61009
 User updated by:j dot hensoldt at gmx dot de
 Reported by:j dot hensoldt at gmx dot de
 Summary:max_input_vars
 Status: Not a bug
 Type:   Bug
 Package:PHP options/info functions
 Operating System:   Debian squeeze
 PHP Version:5.3SVN-2012-02-08 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

ok, max_input_vars cant´t be set using ini_set().  I did not know that - 
thanks.

But i cant´t set max_input_vars in php.ini too. phpinfo() displays the 
correctly changed value (for example max_input_vars=5000), but the 
array-input-variables with index > 1000 are truncated. (sorry for my english, i 
hope you can understand me)


Previous Comments:

[2012-02-08 13:14:26] ahar...@php.net

As http://au2.php.net/manual/en/info.configuration.php says, max_input_vars is 
PHP_INI_PERDIR, so can't be set with ini_set().


[2012-02-08 13:00:06] j dot hensoldt at gmx dot de

Description:

I am using PHP 5.3.3-7+squeeze7 on Debian+Apache2.

I cann´t change the parameter max_input_vars.



A change of max_input_vars in php.ini does not work too. phpinfo() displays the 
correctly changed value, but the internal value of max_input_vars is not 
changed and is always 1000.








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

[PHP-BUG] Bug #61010 [NEW]: Segfault (11) on oci_connect

[lars at larsdebruin dot net]

From: 
Operating system: Redhat Linux 6.2
PHP version:  5.3.10
Package:  OCI8 related
Bug Type: Bug
Bug description:Segfault (11) on oci_connect

Description:

build:
./configure --with-libxml-dir --enable-bcmath --with-openssl
--with-kerberos --
with-zlib --with-bz2 --with-libdir=lib64 --enable-calendar --with-curl
--enable-
exif --enable-ftp --with-gd --with-ldap --with-ldap-sasl --enable-mbstring
--
with-mcrypt --with-mysql --with-pdo-mysql --with-mysqli --with-
oci8=shared,instantclient,/root/oracle --enable-soap --enable-sockets
--with-
gettext --enable-zip --with-mhash --with-pcre-regex --enable-shmop
--enable-
sysvmsg --enable-mysqlnd --with-unixODBC --with-apxs2=/usr/sbin/apxs
--disable-
cgi

PHPinfo: 
OCI8 Supportenabled
Version 1.4.7
Revision$Revision: 321634 $
Active Persistent Connections   0
Active Connections  0
Oracle Instant Client Version   10.1
Temporary Lob support   enabled
Collections support enabled

Test script:
---


Expected result:

<>: php oracleconnect.php
Segmentation fault (core dumped)

Core dump is NOT generated



Actual result:
--
Core dump is not generated by PHP?

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

Bug #61009 [Opn->Nab]: max_input_vars

[aharvey]

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

 ID: 61009
 Updated by: ahar...@php.net
 Reported by:j dot hensoldt at gmx dot de
 Summary:max_input_vars
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:PHP options/info functions
 Operating System:   Debian squeeze
 PHP Version:5.3SVN-2012-02-08 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

As http://au2.php.net/manual/en/info.configuration.php says, max_input_vars is 
PHP_INI_PERDIR, so can't be set with ini_set().


Previous Comments:

[2012-02-08 13:00:06] j dot hensoldt at gmx dot de

Description:

I am using PHP 5.3.3-7+squeeze7 on Debian+Apache2.

I cann´t change the parameter max_input_vars.



A change of max_input_vars in php.ini does not work too. phpinfo() displays the 
correctly changed value, but the internal value of max_input_vars is not 
changed and is always 1000.








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

[PHP-BUG] Bug #61009 [NEW]: max_input_vars

[j dot hensoldt at gmx dot de]

From: 
Operating system: Debian squeeze
PHP version:  5.3SVN-2012-02-08 (SVN)
Package:  PHP options/info functions
Bug Type: Bug
Bug description:max_input_vars 

Description:

I am using PHP 5.3.3-7+squeeze7 on Debian+Apache2.

I cann´t change the parameter max_input_vars.



A change of max_input_vars in php.ini does not work too. phpinfo() displays
the correctly changed value, but the internal value of max_input_vars is
not changed and is always 1000.



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

Bug #51533 [Com]: [recursive reference In Array] Nesting level too deep

[herb at bobbingwide dot com]

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

 ID: 51533
 Comment by: herb at bobbingwide dot com
 Reported by:neel dot basu dot z at gmail dot com
 Summary:[recursive reference In Array] Nesting level too
 deep
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.3.2
 Block user comment: N
 Private report: N

 New Comment:

There is a comment in http://us.php.net/manual/en/function.is-array.php#98156
which suggests using casting to array to check if an array is actually an 
array. I was 
using this solution within a function that returns a default if the array index 
is not 
defined. It worked quite nicely until I tried to apply it to $GLOBALS  and I 
got the 
Nesting level too deep.

So I'm looking for another, highly efficient, solution that won't issue php 
notices for 
undefined indexes.

Test script:



Expected result:

boolean true or false

Actual result:
--
Fatal error: Nesting level too deep - recursive dependency? in 
/Server/http/php-bugs/nesting.php on line 8






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

[PHP-BUG] Bug #61008 [NEW]: not enough shared memory left

[shenkong at qq dot com]

From: 
Operating system: CentOS 6.0
PHP version:  5.3.10
Package:  Semaphore related
Bug Type: Bug
Bug description:not enough shared memory left

Description:

i run the code below in the cmd, it tooks warning Warning: shm_put_var():
not 
enough shared memory left in 
/usr/local/agent/bin/a.php on line 15
i set the shmmax > 100M
when the process > 1 ,the error shows
when the process = 1, it seems ok.

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

Actual result:
--
Warning: shm_put_var(): not enough shared memory left in 
/usr/local/agent/bin/a.php on line 15


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

Bug #52752 [Com]: Program terminated with signal 7, Bus error.

[vc at artstyle dot ru]

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

 ID: 52752
 Comment by: vc at artstyle dot ru
 Reported by:paulgao at yeah dot net
 Summary:Program terminated with signal 7, Bus error.
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Centos 5 32bit
 PHP Version:5.3SVN-2010-08-31 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

About the only way - disable use of mmap() on PHP code files. Need to patch and 
recompile. Something like this:

--- main/main.c~2012-02-08 06:00:52.0 +0400
+++ main/main.c 2012-02-08 06:01:28.0 +0400
@@ -1229,7 +1229,7 @@
/* can we mmap immeadiately? */
memset(&handle->handle.stream.mmap, 0, 
sizeof(handle->handle.stream.mmap)); 
len = php_zend_stream_fsizer(stream TSRMLS_CC);
-   if (len != 0
+   if (0 && len != 0
 #if HAVE_MMAP  
&& ((len - 1) % page_size) <= page_size - ZEND_MMAP_AHEAD
 #endif


Previous Comments:

[2012-02-07 18:57:30] mbreid at thepei dot com

I believe I'm running into this exact same error. I'm new to PHP-FPM (v5.3.9) 
as well as GDB, so here's what I managed to pull from the "core dump" / gdb 
backtrace log:

Core was generated by `php-fpm: pool www '.
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=0x7fffbe65e368) at Zend/zend_language_scanner.l:1801
1801if (*YYCURSOR == '\'') {

AND


#0  lex_scan (zendlval=0x7fffbe65e368) at Zend/zend_language_scanner.l:1801
#1  0x0076fe90 in zendlex (zendlval=0x7fffbe65e360)
at /usr/src/install/php-5.3.9/Zend/zend_compile.c:4975
#2  0x007598ae in zendparse ()
at /usr/src/install/php-5.3.9/Zend/zend_language_parser.c:3285
#3  0x00765268 in compile_file (file_handle=0x7fffbe65e6e0, type=2)
at Zend/zend_language_scanner.l:364
#4  0x005ee40a in phar_compile_file (file_handle=, 
type=) at 
/usr/src/install/php-5.3.9/ext/phar/phar.c:3393
#5  0x007b88ac in ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER 
(execute_data=0x31432a8)
at /usr/src/install/php-5.3.9/Zend/zend_vm_execute.h:5234
#6  0x007ad538 in execute (op_array=0x32c4900)
at /usr/src/install/php-5.3.9/Zend/zend_vm_execute.h:107
#7  0x0078806a in zend_execute_scripts (type=8, retval=, 
file_count=3) at /usr/src/install/php-5.3.9/Zend/zend.c:1236
#8  0x0073686d in php_execute_script (primary_file=)
at /usr/src/install/php-5.3.9/main/main.c:2308
#9  0x00817545 in main (argc=, argv=)
at /usr/src/install/php-5.3.9/sapi/fpm/fpm/fpm_main.c:1858

I'm running Ubuntu 10.10 (64-bit) -- Any ideas one what could be happening here 
or ways to address this moving forward?


[2011-12-22 23:56:52] vc at artstyle dot ru

Test case:

# cat test3.php 
 0) {
  while ($argv[1]--) file_put_contents('test.tpl', "\n", LOCK_EX);
} else {
  $p2 = popen("php test3.php 100", "r");
  while (1) include 'test.tpl';
}
?>
# php test3.php 
Bus error
# php test3.php 
Bus error
# php test3.php 
Bus error
# php test3.php 
PHP Parse error:  syntax error, unexpected $end, expecting T_VARIABLE or 
T_DOLLAR_OPEN_CURLY_BRACES or T_CURLY_OPEN in /var/tmp/test.tpl on line 1
Parse error: syntax error, unexpected $end, expecting T_VARIABLE or 
T_DOLLAR_OPEN_CURLY_BRACES or T_CURLY_OPEN in /var/tmp/test.tpl on line 1

In my case it's an application (Bitrix) to blame. Ugly code that frequently 
rewrites cached template in place, instead of creating new and renaming it.


[2011-12-22 22:36:53] vc at artstyle dot ru

Same here. Apache doesn't matter, I've get this SIGBUS couple times a day. With 
APC or xcache different versions,latest - all the same. PHP is stock Debian:
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 13:13:26) 
Using fastcgi SAPI with pretty large PHP application (thousands of files).
I'll try to make it reproducible.

# gdb /usr/lib/cgi-bin/php5-fcgi ./3002.php5-fcgi.7.9143
[...]
Program terminated with signal 7, Bus error.
#0  lex_scan (zendlval=0xbfffa2ec) at 
/build/buildd-php5_5.3.3-7+squeeze3-i386-H_HNTR/php5-5.3.3/Zend/zend_language_scanner.c:940
940 yych = *YYCURSOR;
(gdb) l
935   0,   0,   0,   0,   0,   0,   0,   0, 
936 };
937 
938 YYDEBUG(0, *YYCURSOR);
939 YYFILL(8);
940 yych = *YYCURSOR;
941 if (yych != '<') goto yy4;
942 YYDEBUG(2, *YYCURSOR);
943 yyaccept = 0;
944 yych = *(YYMARKER = ++YYCURSOR);

(gdb) p language_scanner_globals.yy_c