[PHP-BUG] Req #64923 [NEW]: DateTime::CreateFromFormat return false

2013-05-25 Thread ostico at gmail dot com
From: ostico at gmail dot com
Operating system: Linux
PHP version:  Irrelevant
Package:  Class/Object related
Bug Type: Feature/Change Request
Bug description:DateTime::CreateFromFormat return false

Description:

---
>From manual page: http://www.php.net/datetime.createfromformat#refsect1-
datetime.createfromformat-returnvalues
---
I think that returning false is a bad behaviour that lead to surely
unwanted 
fatal exception when passing to it not well formatted dates.

This static method seems to be thought to get a datetime object on which
method 
format can be called inline:
DateTime::CreateFromFormat()->format()

But on not well formatted date strings the 'format' method raise an
exception 
E_ERROR because it is called on a boolean.

In my opinion CreateFromFormat should raise a throwable exception ( Best 
Solution ) or return an 
empty DateTime Object ( Unix Time 1970-01-01 ) and raise a warning, NOT a 
boolean value.


Test script:
---
php > var_dump( DateTime::CreateFromFormat('Y-m-d', '2013-05-') );
php > try { DateTime::CreateFromFormat('Y-m-d', '2013-05-'); } catch (
Exception $e ) { var_dump( 'ok' ); }
php > try { var_dump( DateTime::CreateFromFormat('Y-m-d',
'2013-05-')->format('dmY') ); } catch ( Exception $e ) { echo 'ok'; }

Expected result:

PHP Warning:  Uncaught exception 'Exception' in php shell code:1
string(2) "ok"
string(2) "ok"

//---
//alternatively the example should return an empty Datetime Object and 
raise a warning
PHP Warning:  Malformed Date String in php shell code on line 1
object(DateTime)#10 (3) {
  ["date"]=>
  string(19) "1970-01-01 00:00:00"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(13) "Europe/Berlin"
}
PHP Warning:  Malformed Date String in php shell code on line 1
PHP Warning:  Malformed Date String in php shell code on line 1
string(8) "01011970"

Actual result:
--
bool(false)
PHP Fatal error:  Call to a member function format() on a non-object in php
shell 
code on line 1

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



Bug #64921 [Opn]: Inconsistent stream_select() behavior for php://memory vs. php://temp

2013-05-25 Thread rdlowrey at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=64921&edit=1

 ID: 64921
 User updated by:rdlowrey at gmail dot com
 Reported by:rdlowrey at gmail dot com
 Summary:Inconsistent stream_select() behavior for
 php://memory vs. php://temp
 Status: Open
 Type:   Bug
 Package:Streams related
 Operating System:   Fedora 17
 PHP Version:5.4.15
 Block user comment: N
 Private report: N

 New Comment:

UPDATE:

According to http://php.net/manual/en/wrappers.php.php php://temp DOES support  
stream_select(). However, if this is the case, the behavior described here is 
still incorrect because stream_select() reports that the descriptor is readable 
 
even though it has no readable data and feof($stream) === FALSE.


Previous Comments:

[2013-05-25 00:11:00] rdlowrey at gmail dot com

Description:

Streams of type php://memory cannot be represented as selectable descriptors 
where stream_select() is concerned. Attempting to do so will (rightly) trigger 
an 
E_WARNING along the lines of "Warning: stream_select(): cannot represent a 
stream 
of type MEMORY as a select()able descriptor in ..."

I would expect streams of type php://temp to behave the same way. However, this 
is not the case. Instead, php://temp streams are immediately readable (but do 
not 
evaluate to TRUE for feof($stream). These streams should either (1) trigger an 
error similar to that of php://memory or (2) not be represented as readable by 
stream_select().

Test script:
---
$stream = fopen('php://memory', 'r+');
$r = array($stream);
$w = $e = NULL;

stream_select($r, $w, $e, 0); // E_WARNING (as expected)

$stream = fopen('php://temp', 'r');
$r = array($stream);
$w = $e = NULL;

if (stream_select($r, $w, $e, 0)) {
var_dump(feof($stream)); // this isn't readable and should never be called 
but it results in bool(false)
}

Expected result:

The test script should trigger two warnings and neither stream should report as 
readable.

Actual result:
--
php://temp streams do not trigger an error when used with stream_select() and 
are 
immediately reported as readable.






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


Bug #47689 [Com]: crash with certain regular expression

2013-05-25 Thread djokodonev at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=47689&edit=1

 ID: 47689
 Comment by: djokodonev at gmail dot com
 Reported by:vr...@php.net
 Summary:crash with certain regular expression
 Status: Not a bug
 Type:   Bug
 Package:PCRE related
 Operating System:   win32 only
 PHP Version:5.*, 6CVS (2009-03-17)
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

This should be added to the PCRE(preg_match etc..) documentation. It had me 
clules for a long time as of what it going on.


Previous Comments:

[2011-09-29 13:34:44] paj...@php.net

It would be nice to add that to both apache 2.2 configuration and pcre docs.


[2011-09-29 12:35:55] ferenczy at volny dot cz

Better way to alter Apache stack size is using the ThreadStackSize directive in 
the Apache's configuration file (httpd.conf). There is a description of the 
ThreadStackSize directive in Apache's documentation: 
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#ThreadStackSize

So increase of Apache stack size might looks like this (lines from httpd.conf):


   ThreadStackSize 8*1024*1024


It sets Apache stack size to 8 MB, so it's the same as a default value on Linux.


[2009-07-06 17:43:44] paj...@php.net

That's not something we can change for apache. You can fix the problem by 
increasing the stack size for apache using the following command:

editbin /STACK:800 c:\apache22\bin\httpd.exe

Sadly this tool is not available as a standalone app but VC Express should have 
it.

Close (bogus) this bug as it is not something we can change in PHP. We can 
increase the stack at wish but it is apache dependent. FastCGI does not seem to 
have this problem (was not able to crash it).


[2009-06-18 13:27:10] peter dot swietoslawski at me dot com

I'm experiencing similar crash on PHP 5.2.9-2, Apache 2.2.11, Vista 
SP2 
if I run simple code like:


  
  Web Services
  Integration Tools
  Developer Group
  Developer Forum
  

 
Web Services 

  
  
  ';

  $pattern = '/((.|\s)+)/i';

  preg_match($pattern, $content, $book_nav);
?>

However this works fine in PHP 5.2.8 and in CLI for 5.2.9-2.


[2009-05-21 20:25:47] paj...@php.net

Only wondering which impact has this change, have to test first before to 
increase the stack.




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


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


Req #64603 [Com]: missing function to close persistent connection

2013-05-25 Thread michael at mjburgess dot co dot uk
Edit report at https://bugs.php.net/bug.php?id=64603&edit=1

 ID: 64603
 Comment by: michael at mjburgess dot co dot uk
 Reported by:slavb18 at gmail dot com
 Summary:missing function to close persistent connection
 Status: Open
 Type:   Feature/Change Request
 Package:PDO related
 Operating System:   Any
 PHP Version:5.3.23
 Block user comment: N
 Private report: N

 New Comment:

I've confirmed this


Previous Comments:

[2013-04-07 07:24:16] slavb18 at gmail dot com

may be there is also third way to resolve problem

1. PDO class should have function
public function isValid(){
return TRUE; // or some embedded functional like start/finish transaction ? 
dont know how it work with other drivers
}
2. derived class override & implement method isValid() (like in my example)
3. php before returning PDO class from connection pool should call isValid() 
method, and if validation the result is false, then automatically refresh 
connection


[2013-04-07 07:13:03] slavb18 at gmail dot com

there is similiar Bug #40681 with oracle


[2013-04-07 07:11:12] slavb18 at gmail dot com

Description:

PHP PDO class is missing ability to close persistent connection:
__destruct does not close it, even if I call 
setAttribute(PDO::ATTR_PERSISTENT,FALSE) before destruction
May be __destruct should analyze PDO::ATTR_PERSISTENT attribute or there should 
be explicit function to close persistent connection.

Need to close invalid (shutdown) peristent connection demonstrate example below:

Example with firebird:
1. establish persistent connect in php
2. shutdown connection on server
3. try to get persistent connect from php again
there will be error "General error: -902 connection shutdown"

I can check connection validity in my pdo derived class like this:
public function isValid(){
$valid=TRUE;
try {
$this->beginTransaction();
$this->commit();
} catch (PDOException $e){
$valid=FALSE;
}
return $valid;
}

but I can not "refresh" or "close" my broken connection, there is no function 
to free it in php connection pool







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


Bug #64836 [Asn->Sus]: segfault in softmagic.c

2013-05-25 Thread ab
Edit report at https://bugs.php.net/bug.php?id=64836&edit=1

 ID: 64836
 Updated by: a...@php.net
 Reported by:r dot biegel at gmx dot at
 Summary:segfault in softmagic.c
-Status: Assigned
+Status: Suspended
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Gentoo Linux
 PHP Version:5.4.15
 Assigned To:ab
 Block user comment: N
 Private report: N

 New Comment:

Hi,

thanks for investing so much time in this ticket. After looking at the Gentoo 
tickets

- #470828 seems to report about SVN issue in apache, PHP is only mentioned aside
- #467756 looks related to PHP, however 5.4.14. As i've mentioned, libmagic is 
upgraded in 5.4.15, though one small regression was present. The crash in that 
ticket is therefore most likely not relevant for 5.4.15 and later.
- The BT in this ticket isn't reproducible anymore by you, nor I could get it 
crashy

Conclusion - I would suspend this bug and check when the new PHP version is 
out. 
May be also some more info is present in the Gentoo tickets by that time.

Have a nice weekend :)


Previous Comments:

[2013-05-23 11:04:18] r dot biegel at gmx dot at

OK, in short: I can't reproduce the segfault behaviour anymore.

Longer version:
- updated kernel from gentoo-hardened 3.8.12 to 3.9.2
- updated gcc to 4.7.3
- compiled php 5.4.13 and 5.4.14 and both work fine
- compiled php 5.4.15 again which now works fine too
- downgraded kernel and gcc to previous versions
- compiled php 5.4.15, still works

I just don't get it... I already had re-compiled php and apache before 
reporting as bug.

With "-D SVN" I meant the startup-arguments for apache on the command line. 
Don't know if this is Gentoo specific, but it controls the loading of the svn 
DAV module.

At last I'd like to link these two bugs on gentoo bugzilla, which might be 
related:
https://bugs.gentoo.org/show_bug.cgi?id=467756
https://bugs.gentoo.org/show_bug.cgi?id=470828

Thanks for your help!


[2013-05-21 08:00:47] a...@php.net

I've just compiled apache 2.4 with subversion 1.7.x module plus PHP-5.5, TS 
build. But it still doesn't crash for me. Note that the libmagic is the same in 
5.4 and 5.5 and was upgraded in 5.4.15 and 5.5.0 beta4.

To diagnose it further, is it possible you to check if the behavior is the same 
with the earlier php versions? May be 5.4.14 or 5.5.0 beta3. Also i think this 
behaviour is TS specific, svn might be even not the cause, too.

btw what do you mean "not using -D SVN"? As i've experienced the mod_dav_svn.so 
has to be built from the subversion sources and is not contained in the apache 
source tree.

Thanks.


[2013-05-19 15:31:46] r dot biegel at gmx dot at

I used this little script to test the finfo_file function on its own. Crashes 
in apache (if the file $fn exists, filetype doesn't matter), but it works on 
cli:




So it has something to do with apache i thought and it turned out that 
disabling SVN DAV in apache (not using -D SVN) fixes the problem. How can I 
investigate further? Btw, I already upgraded from apache 2.2 to 2.4 before my 
first report.


Here another (more detailed) bt:

Thread 28 (Thread 0x7fffd9feb700 (LWP 24821)):
#0  0x7fffeeec2e6b in mget (ms=0x7fffd411c5f0, s=0x7fffd8896030 "GIF89a", 
m=0x7fffd8a69268, nbytes=1218, o=0, cont_level=0, mode=32, text=0, flip=0, 
recursion_level=1, printed_something=0x7fffd9fe7dd4, 
need_separator=0x7fffd9fe7dd8, returnval=0x7fffd9fe7d24)
at ext/fileinfo/libmagic/softmagic.c:1610
off = 0
soffset = 410814606
offset = 0
count = 0
rv = -207172457
oneed_separator = 994741513
sbuf = 0x5cb76acd3615aac9 
rbuf = 0x8efc10f4e7cb6d6d 
p = 0x7fffd411c660
ml = {magic = 0x180ffedff931d7c7, nmagic = 1473718312, map = 
0xd8c865c8, next = 0x7fffd411c5f0, prev = 0x1a09a2a9d9c97089}
#1  0x7fffeeebede8 in match (ms=0x7fffd411c5f0, magic=0x7fffd89170e8, 
nmagic=9629, s=0x7fffd8896030 "GIF89a", nbytes=1218, offset=0, mode=32, text=0, 
flip=0, recursion_level=0, printed_something=0x7fffd9fe7dd4, 
need_separator=0x7fffd9fe7dd8, returnval=0x7fffd9fe7d24)
at ext/fileinfo/libmagic/softmagic.c:157
flush = 0
m = 0x7fffd8a69268
magindex = 5584
cont_level = 0
returnvalv = 0
e = -647236122
firstline = 1
print = 0
#2  0x7fffeeebeb19 in file_softmagic (ms=0x7fffd411c5f0, buf=0x7fffd8896030 
"GIF89a", nbytes=1218, mode=32, text=0)
at ext/fileinfo/libmagic/softmagic.c:82
ml = 0x7fffd40efb50
rv = 32767
printed_something = 0
need_separator = 0
#3  0x7fffeeebc3a5 in file_buffer (ms=0x7fffd411c5f0, 
stream=0x7fffd8d70