Bug #13245 [Com]: Hard 8Mb limit on file uploads?

2013-08-02 Thread 979894238 at qq dot com
Edit report at https://bugs.php.net/bug.php?id=13245edit=1

 ID: 13245
 Comment by: 979894238 at qq dot com
 Reported by:boaz at corky dot net
 Summary:Hard 8Mb limit on file uploads?
 Status: Closed
 Type:   Bug
 Package:HTTP related
 Operating System:   linux
 PHP Version:4.0.6
 Block user comment: N
 Private report: N

 New Comment:

Can anyone tell me how to handle this WARNING?
i want to transform this WARNING to an exception and catch it.


Previous Comments:

[2002-07-03 10:55:14] boaz at corky dot net

post_max_size fixed my problem.

thanks.


[2001-10-28 17:12:04] sni...@php.net

The http upload stuff has been rewritten in CVS.
Try the latest CVS snapshot from http://snaps.php.net/
Also check the ulimit issue Hartmut mentioned.

--Jani



[2001-10-23 11:23:36] sni...@php.net

status - feedback


[2001-10-06 08:12:44] hholz...@php.net

quick guess: process resource limits active?

see man ulimit ...


[2001-10-06 08:06:28] jmo...@php.net

yep, I have lots of times.. must be a memory limit somewhere in your system 
stopping PHP getting enough memory to perform the upload. can you try the exact 
settings jani said (the 16M ones) and lets see if that works.

- James




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


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


[PHP-BUG] Bug #65375 [NEW]: DOMXPath query registerNodeNS produces unexpected behavior

2013-08-02 Thread goetas at lignano dot it
From: goetas at lignano dot it
Operating system: ubuntu 12.04
PHP version:  5.4.17
Package:  DOM XML related
Bug Type: Bug
Bug description:DOMXPath query registerNodeNS produces unexpected behavior

Description:

registerNodeNS option (default to true) added with php 5.3.3 produces
unexpected behavior and BC issue.

$registerNodeNS = true seems to remove (overwrite)  registered namespaces
with DOMXPath::registerNamespace() method,

Similar problem has been reported with #55700

Test script:
---
?php
$dom = new DOMDocument('1.0', 'UTF-8');
$dom-loadXML('
ns1:tag xmlns:ns1=http://my.com/ns1; xmlns:ns2=http://my.com/ns2;
  ns1:tag-2/  
  ns2:extra/  
/ns1:tag');


$xpath = new DOMXPath($dom);
$xpath-registerNamespace(ns2, http://my.com/ns1;);

echo $xpath-query(//ns2:tag-2, null, false)-length.\n; 
echo $xpath-query(//ns2:tag-2, null, true)-length,\n; 
/*
* registerNodeNS option should skip prefix registration if
* same prefix is already registered with registerNamespace() method.
*/

Expected result:

1
1

Actual result:
--
1
0

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



Bug #13245 [Csd]: Hard 8Mb limit on file uploads?

2013-08-02 Thread mike
Edit report at https://bugs.php.net/bug.php?id=13245edit=1

 ID: 13245
 Updated by: m...@php.net
 Reported by:boaz at corky dot net
 Summary:Hard 8Mb limit on file uploads?
 Status: Closed
 Type:   Bug
 Package:HTTP related
 Operating System:   linux
 PHP Version:4.0.6
-Assigned To:
+Assigned To:mike
 Block user comment: N
 Private report: N

 New Comment:

This is not a support forum.

It happens prior your code is run, so it cannot be caught.


Previous Comments:

[2013-08-02 07:07:22] 979894238 at qq dot com

Can anyone tell me how to handle this WARNING?
i want to transform this WARNING to an exception and catch it.


[2002-07-03 10:55:14] boaz at corky dot net

post_max_size fixed my problem.

thanks.


[2001-10-28 17:12:04] sni...@php.net

The http upload stuff has been rewritten in CVS.
Try the latest CVS snapshot from http://snaps.php.net/
Also check the ulimit issue Hartmut mentioned.

--Jani



[2001-10-23 11:23:36] sni...@php.net

status - feedback


[2001-10-06 08:12:44] hholz...@php.net

quick guess: process resource limits active?

see man ulimit ...




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


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


Bug #65367 [Fbk]: Segmentation fault when mixing = and =

2013-08-02 Thread mbeccati
Edit report at https://bugs.php.net/bug.php?id=65367edit=1

 ID: 65367
 Updated by: mbecc...@php.net
 Reported by:mbecc...@php.net
 Summary:Segmentation fault when mixing = and =
 Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Any
 PHP Version:5.5.1
 Block user comment: N
 Private report: N

 New Comment:

Yes, the patch fixes the issue as far as I can tell. Well done!


Previous Comments:

[2013-08-02 02:00:15] larue...@php.net

could you please verify the fix I attached at #65372?
thanks


[2013-08-02 01:11:26] larue...@php.net

Seems similar to #65372


[2013-07-31 11:13:15] mbecc...@php.net

I forgot to mention that you can easily install the necessary PEAR libraries in 
the current dir without polluting the global PEAR installation with:

pear install -R . MDB2 MDB2#pgsql


[2013-07-31 11:10:29] mbecc...@php.net

Description:

While updating an old open source application to work with PHP 5.4 and 5.5, I 
somehow managed to trigger a segmentation fault when removing an = assignment. 
I've been able to write a small reproduce script, which however still requires 
MDB2 from PEAR (tested only with the pgsql driver).

Changing back a specific assignment to = prevents the shutdown segfault from 
happening.

The code works fine with 5.3 and crashes on 5.4+. Tested on Windows and Linux.

Test script:
---
?php

require './usr/share/php/MDB2.php';

class A {
static function singleton()
{
$db = 
MDB2::connect('pgsql://postgres:password@localhost/postgres');
$db-loadModule('Datatype');

$GLOBALS['DB'] = $db; // Using = $db doesn't crash

return $GLOBALS['DB'];
}
}

class B {
function __construct()
{
$this-db = $this-getDb();
}

function getDB()
{
return A::singleton();
}
}

$b = new B();


Expected result:

PHP Notice:  Only variable references should be returned by reference in 
foobar.php on line 25


Actual result:
--
#0  0x00812979 in gc_zval_possible_root (zv=0x7fffeef256e0) at 
/root/compile/php-5.5.1/Zend/zend_gc.c:143
No locals.
#1  0x00801268 in zend_hash_destroy (ht=0x7fffeef2b4a0) at 
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2b860
q = 0x7fffeef2b7b0
#2  0x007f206b in _zval_dtor_func (zvalue=0x7fffeef2b470) at 
/root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#3  0x007e3178 in _zval_dtor (zvalue=0x7fffeef2b470) at 
/root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#4  i_zval_ptr_dtor (zval_ptr=0x7fffeef2b470) at 
/root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#5  _zval_ptr_dtor (zval_ptr=optimized out) at 
/root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#6  0x00801268 in zend_hash_destroy (ht=0x7fffeef28b10) at 
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2bfd0
q = 0x7fffeef2ba80
#7  0x007f206b in _zval_dtor_func (zvalue=0x7fffeef28778) at 
/root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#8  0x007e3178 in _zval_dtor (zvalue=0x7fffeef28778) at 
/root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#9  i_zval_ptr_dtor (zval_ptr=0x7fffeef28778) at 
/root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#10 _zval_ptr_dtor (zval_ptr=optimized out) at 
/root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#11 0x00801268 in zend_hash_destroy (ht=0x7fffeef2cbb8) at 
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2ce78
q = 0x7fffeef2ce20
#12 0x0081579c in zend_object_std_dtor (object=0x7fffeef27cb0) at 
/root/compile/php-5.5.1/Zend/zend_objects.c:44
No locals.
#13 0x00815829 in zend_objects_free_object_storage 
(object=0x7fffeef27cb0) at /root/compile/php-5.5.1/Zend/zend_objects.c:137
No locals.
#14 0x0081b476 in zend_objects_store_free_object_storage 
(objects=0x1085120)
at /root/compile/php-5.5.1/Zend/zend_objects_API.c:92
obj = optimized out
i = optimized out
#15 0x007e37e3 in shutdown_executor () at 
/root/compile/php-5.5.1/Zend/zend_execute_API.c:293
__orig_bailout = 0x7fffe460
__bailout = {{__jmpbuf = {17321344, -8869895244590628792, 0, 0, 0, 
17333536, 8869894737283235912, -8869895235585851320},
__mask_was_saved = 0, __saved_mask = {__val = {9576849035021516823, 
0, 8402366, 17291648, 17319392, 140737353913872,
140737353912280, 140737353913920, 

Bug #65367 [Fbk-Opn]: Segmentation fault when mixing = and =

2013-08-02 Thread mbeccati
Edit report at https://bugs.php.net/bug.php?id=65367edit=1

 ID: 65367
 Updated by: mbecc...@php.net
 Reported by:mbecc...@php.net
 Summary:Segmentation fault when mixing = and =
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Any
 PHP Version:5.5.1
 Block user comment: N
 Private report: N



Previous Comments:

[2013-08-02 07:29:59] mbecc...@php.net

Yes, the patch fixes the issue as far as I can tell. Well done!


[2013-08-02 02:00:15] larue...@php.net

could you please verify the fix I attached at #65372?
thanks


[2013-08-02 01:11:26] larue...@php.net

Seems similar to #65372


[2013-07-31 11:13:15] mbecc...@php.net

I forgot to mention that you can easily install the necessary PEAR libraries in 
the current dir without polluting the global PEAR installation with:

pear install -R . MDB2 MDB2#pgsql


[2013-07-31 11:10:29] mbecc...@php.net

Description:

While updating an old open source application to work with PHP 5.4 and 5.5, I 
somehow managed to trigger a segmentation fault when removing an = assignment. 
I've been able to write a small reproduce script, which however still requires 
MDB2 from PEAR (tested only with the pgsql driver).

Changing back a specific assignment to = prevents the shutdown segfault from 
happening.

The code works fine with 5.3 and crashes on 5.4+. Tested on Windows and Linux.

Test script:
---
?php

require './usr/share/php/MDB2.php';

class A {
static function singleton()
{
$db = 
MDB2::connect('pgsql://postgres:password@localhost/postgres');
$db-loadModule('Datatype');

$GLOBALS['DB'] = $db; // Using = $db doesn't crash

return $GLOBALS['DB'];
}
}

class B {
function __construct()
{
$this-db = $this-getDb();
}

function getDB()
{
return A::singleton();
}
}

$b = new B();


Expected result:

PHP Notice:  Only variable references should be returned by reference in 
foobar.php on line 25


Actual result:
--
#0  0x00812979 in gc_zval_possible_root (zv=0x7fffeef256e0) at 
/root/compile/php-5.5.1/Zend/zend_gc.c:143
No locals.
#1  0x00801268 in zend_hash_destroy (ht=0x7fffeef2b4a0) at 
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2b860
q = 0x7fffeef2b7b0
#2  0x007f206b in _zval_dtor_func (zvalue=0x7fffeef2b470) at 
/root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#3  0x007e3178 in _zval_dtor (zvalue=0x7fffeef2b470) at 
/root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#4  i_zval_ptr_dtor (zval_ptr=0x7fffeef2b470) at 
/root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#5  _zval_ptr_dtor (zval_ptr=optimized out) at 
/root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#6  0x00801268 in zend_hash_destroy (ht=0x7fffeef28b10) at 
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2bfd0
q = 0x7fffeef2ba80
#7  0x007f206b in _zval_dtor_func (zvalue=0x7fffeef28778) at 
/root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#8  0x007e3178 in _zval_dtor (zvalue=0x7fffeef28778) at 
/root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#9  i_zval_ptr_dtor (zval_ptr=0x7fffeef28778) at 
/root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#10 _zval_ptr_dtor (zval_ptr=optimized out) at 
/root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#11 0x00801268 in zend_hash_destroy (ht=0x7fffeef2cbb8) at 
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2ce78
q = 0x7fffeef2ce20
#12 0x0081579c in zend_object_std_dtor (object=0x7fffeef27cb0) at 
/root/compile/php-5.5.1/Zend/zend_objects.c:44
No locals.
#13 0x00815829 in zend_objects_free_object_storage 
(object=0x7fffeef27cb0) at /root/compile/php-5.5.1/Zend/zend_objects.c:137
No locals.
#14 0x0081b476 in zend_objects_store_free_object_storage 
(objects=0x1085120)
at /root/compile/php-5.5.1/Zend/zend_objects_API.c:92
obj = optimized out
i = optimized out
#15 0x007e37e3 in shutdown_executor () at 
/root/compile/php-5.5.1/Zend/zend_execute_API.c:293
__orig_bailout = 0x7fffe460
__bailout = {{__jmpbuf = {17321344, -8869895244590628792, 0, 0, 0, 
17333536, 8869894737283235912, -8869895235585851320},
__mask_was_saved = 0, __saved_mask = {__val = 

[PHP-BUG] Bug #65376 [NEW]: Unserialize function issue

2013-08-02 Thread carlosV2 dot 0 at gmail dot com
From: carlosV2 dot 0 at gmail dot com
Operating system: Mac OS X
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Bug
Bug description:Unserialize function issue

Description:

I think the unserialize method should have a final string length check.

You can make objects disappear just running the code in the Test Script:

This code outputs just the first object.
This is something it can easily happend when you are working with sockets
or data 
streams.

Probably it is the developer's fault but actually to serialized objects
together 
are not only one object.

I think checking the string length at the end of the parser and rising a
warning 
is enough to alert the developer that this things are happening.

Test script:
---
$o1 = new stdClass();
$o1-name = 'Object1';

$o2 = new stdClass();
$o2-name = 'Object2';

$objects = serialize($o1) . serialize($o2);
print_r(unserialize($objects));

Expected result:

A warning

Actual result:
--
Only the first object:

stdClass Object
(
[name] = Object1
)

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



Bug #65376 [Opn-Nab]: Unserialize function issue

2013-08-02 Thread mike
Edit report at https://bugs.php.net/bug.php?id=65376edit=1

 ID: 65376
 Updated by: m...@php.net
 Reported by:carlosV2 dot 0 at gmail dot com
 Summary:Unserialize function issue
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:*General Issues
 Operating System:   Mac OS X
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

.


Previous Comments:

[2013-08-02 08:27:35] carlosV2 dot 0 at gmail dot com

Description:

I think the unserialize method should have a final string length check.

You can make objects disappear just running the code in the Test Script:

This code outputs just the first object.
This is something it can easily happend when you are working with sockets or 
data 
streams.

Probably it is the developer's fault but actually to serialized objects 
together 
are not only one object.

I think checking the string length at the end of the parser and rising a 
warning 
is enough to alert the developer that this things are happening.

Test script:
---
$o1 = new stdClass();
$o1-name = 'Object1';

$o2 = new stdClass();
$o2-name = 'Object2';

$objects = serialize($o1) . serialize($o2);
print_r(unserialize($objects));

Expected result:

A warning

Actual result:
--
Only the first object:

stdClass Object
(
[name] = Object1
)






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


Bug #55701 [Com]: GlobIterator throws LogicException with message 'The parent constructor was not

2013-08-02 Thread rosier at interstroom dot nl
Edit report at https://bugs.php.net/bug.php?id=55701edit=1

 ID: 55701
 Comment by: rosier at interstroom dot nl
 Reported by:b...@php.net
 Summary:GlobIterator throws LogicException with message 'The
 parent constructor was not
 Status: Assigned
 Type:   Bug
 Package:SPL related
 Operating System:   Linux, OSX
 PHP Version:5.3.8
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

I can confirm this unexpected result also for php54 and php55

Test script:
---
?php

$path_to_files = sys_get_temp_dir();

// Next works as expected: no xml files found = no output
foreach (new GlobIterator($path_to_files . '/*.xml') as $fileinfo) {
echo $fileinfo-getFilename() . \n;
}

$it = new GlobIterator($path_to_files . '/*.xml');
// Expected result: count = 0
// Instead next line will crash php if no xml files are found
if ($it-count()) {
// do something...
}

?


Previous Comments:

[2013-01-28 07:38:40] sergei dot solomonov at gmail dot com

I have same problem too.
OS: windows 7 x64, PHP 5.4.7 (built: Sep 12 2012 23:48:31).
I working with ZF2, when I trying to use phar-packed modules same error occured.
But in Ubuntu works fine.


[2012-12-21 12:18:51] ivanderberg at hostnet dot nl

I can confirm what [2012-03-19 21:24 UTC] maciej dot sz at gmail dot com said 
in a more simplistic way. This class fails in my current version (PHP 5.3.14 
(cli) (built: Jun 19 2012 07:35:36)) on $this-touchLockFile(...)

As I really need $file before calling the parent constructor, I have no other 
option than making it static

?php
/**
 * @author Iltar van der Berg ivanderb...@hostnet.nl
 */
class Lock extends \SplFileObject
{
  /**
   * @param string $file_name
   * @param string $open_mode
   * @param Filesystem $filesystem
   * @param string $lock_directory
   */
  public function __construct($file_name, $open_mode = 'r', Filesystem 
$filesystem = null, $lock_directory = '/var/lock')
  {
$filesystem = $filesystem ?: new Filesystem();
$file = $this-touchLockFile($file_name, $lock_directory, $filesystem);
parent::__construct($file, $open_mode);
  }

  /**
   * Returns true if the lock is placed, false if unable to
   *
   * @return boolean
   */
  public function lock()
  {
return $this-flock(LOCK_EX | LOCK_NB);
  }

  /**
   * Returns true if the lock is released
   *
   * @return bool
   */
  public function release()
  {
return $this-flock(LOCK_UN);
  }

  /**
   * Attempts to create a lock file for a given filename and directory
   * it will return a string if the file is touched
   *
   * @param  string $file_name
   * @param  string $lock_directory
   * @param  Filesystem $filesystem
   * @return string
   */
  private function touchLockFile($file_name, $lock_directory, Filesystem 
$filesystem)
  {
$lock_file_path = explode('/', $file_name);
$lock_file  = array_pop($path);

$path = empty($lock_file_path)
  ? $lock_directory/$lock_file
  :  $lock_directory . implode('/', $lock_file_path);

$lock_file = $path/$lock_file.lock;

if(!$filesystem-exists($path) || !is_dir($path)) {
  $filesystem-mkdir($path, 0733);
}

// some modes create this file already, but we force it in
// that way the lock file always exists no matter what mode
$filesystem-touch($lock_file);
return $lock_file;
  }
}
?


[2012-03-19 21:24:42] maciej dot sz at gmail dot com

Not sure if this is the same issue, but I've experienced something very similar 
when extending SplFileObject (see Script 1 below). This might seem to be of 
very 
little importance, as no one would ever want to extend this class in that way. 
But with the introduction of traits this became a real problem, becouse using 
trait methods that share the same name with a SplFileObject method causes to 
throw the mentioned LogicException. This happens when the method is used in 
constructor prior to calling the parent constructor even if the trait method is 
aliased (see Script 2 below).


Script 1:
--
?php

class MyFileObject extends \SplFileObject
{
public function __construct($fname)
{
/**
 * This throws LogicException despite of that we have
 * overloaded the getRealPath method making it independent
 * of the object state.
 */
$new_fname = $this-getRealPath();

parent::__construct($fname);
}

public function getRealPath()
{
return '/tmp/foo.txt';
}
}

$f1 = new MyFileObject(__FILE__);




Script 2
--
?php

trait NewFileTrait
{
public function getRealPath()
{
return __FILE__ . '.new';
}
}

class 

Bug #55634 [Opn]: ./configure does not fail if invalid option is used

2013-08-02 Thread mike
Edit report at https://bugs.php.net/bug.php?id=55634edit=1

 ID: 55634
 Updated by: m...@php.net
 Reported by:cwei...@php.net
 Summary:./configure does not fail if invalid option is used
 Status: Open
 Type:   Bug
 Package:*Configuration Issues
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

It's not always been like that, there have been times where configure ignored 
unknown arguments silently.  So, I'd say, we're open for improvements.


Previous Comments:

[2011-09-22 19:09:58] paj...@php.net

well, I do consider it as a bug fix.


[2011-09-22 19:07:27] ashn...@php.net

Perhaps a BC compromise here would be to at least *also* echo to stderr, while 
leaving the existing echo to stdout in place?


[2011-09-07 22:28:17] f...@php.net

I'm not saying this behaviour is wrong or right, I've been bitten by this 
already myself, but I do think that could be considered a BC break, as I 
remember it always being like that, although I'm only 100% sure on 5.2+


[2011-09-07 13:17:55] cwei...@php.net

Description:

When using ./configure --with-foo, configure tells me at the end:
 Notice: Following unknown configure options were used:
 --with-foo

There are two problems:
- This problem is echoed to stdout, not stderr where capturing it would be 
possible
- The exit code is still 0, although I clearly issued a wrong option.

In the end I cannot figure out if the configure run was *fully* successful.

Expected result:

1. config option errors echoed to stderr
2. exit code of configure script != 0







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


Req #36696 [Com]: __destruct() is called before serialize() when object stored in session

2013-08-02 Thread info at djdb dot be
Edit report at https://bugs.php.net/bug.php?id=36696edit=1

 ID: 36696
 Comment by: info at djdb dot be
 Reported by:iain at iaindooley dot com
 Summary:__destruct() is called before serialize() when
 object stored in session
 Status: Assigned
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:*
 Assigned To:sas
 Block user comment: N
 Private report: N

 New Comment:

/**
 * @param mixed $user
 * @return void
 */
function setsessionuser($user){
$_SESSION['user']=serialize($user);
}
/**
 * getsessionuser()
 * @return object User
 */ 
function getsessionuser(){
return(isset($_SESSION['user']))?unserialize($_SESSION['user']):null;
}
class User extends User_data{
test and remake


Previous Comments:

[2013-06-27 22:20:01] yohg...@php.net

There is exact dup bug report, but I cannot find.
Workaround is call before session_write_close() before shutdown, but __destruct 
should be the last magicmethod to be called, isn't it?


[2008-06-26 09:38:09] margus dot sipria at gmail dot com

duplicate with a bug http://bugs.php.net/bug.php?id=33772


[2006-03-23 00:27:58] iain at iaindooley dot com

in a garbage collection system, the destructor shouldn't be called on an object 
until the last reference to it is destroyed. if i do:

$_SESSION['var'] = new Var();

then a reference to that object that was created should be stored in the 
$_SESSION array, and __destruct() should not be called until the $_SESSION 
array is destoryed. so clearly the session array must be being destroyed before 
the objects within it are serialized, which isn't right.


[2006-03-22 18:13:41] il...@php.net

There is nothing wrong with the order here. Temp var gets destroyed as soon as 
it is created, while session serialization happens at the end of the script.


[2006-03-21 23:34:59] iain at iaindooley dot com

i would say that the fact the order of operations changes for a temp var or an 
assigned var is a bug.




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

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


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


Bug #54158 [Com]: MYSQLND + PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE

2013-08-02 Thread chris dot de dot kok at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=54158edit=1

 ID: 54158
 Comment by: chris dot de dot kok at gmail dot com
 Reported by:tamas at ideaweb dot hu
 Summary:MYSQLND + PDO MySQL requires #define
 MYSQL_OPT_LOCAL_INFILE
 Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Linux
 PHP Version:5.3.5
 Assigned To:mysql
 Block user comment: N
 Private report: N

 New Comment:

I still seem to have this problem on: PHP 5.4.17-1~precise+1
Ubuntu 12.04


Previous Comments:

[2012-01-15 03:20:00] denis_truffaut at hotmail dot com

ext/pdo_mysql/mysql_driver.c, line 635 :


if (mysql_options(H-sergedit ver, MYSQL_OPT_LOCAL_INFILE, (const char 
*)local_infile)) {


Should be


local_infile = 1;
if (mysql_options(H-sergedit ver, MYSQL_OPT_LOCAL_INFILE, (const char 
*)local_infile)) {


You can achieve this dirty and quickly in doing :


sudo sed -ie 's/if (mysql_options(H-server, 
MYSQL_OPT_LOCAL_INFILE/local_infile 
= 1;if (mysql_options(H-server, MYSQL_OPT_LOCAL_INFILE/g' 
ext/pdo_mysql/mysql_driver.c


[2012-01-15 00:31:54] denis_truffaut at hotmail dot com

I just compiled PHP 5.4 RC5, on a Debian 6... and the bug is still there :(


[2011-10-20 12:57:11] denis_truffaut at hotmail dot com

Some bug fix is planned for PHP 5.4 :

http://php.net/releases/NEWS_5_4_0_beta1.txt

- PDO MySQL driver:
  . Fixed bug #54158 (MYSQLND+PDO MySQL requires #define MYSQL_OPT_LOCAL_INFILE)
  (Andrey)


[2011-10-18 16:35:31] richardpq at gmail dot com

I don't get it, after 5.3.6 release was working? because I have 5.3.8 and it is 
no working

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


[2011-09-09 07:03:01] and...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.






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


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


Bug #49155 [Com]: SoapServer passes parameters as null if one has special wsdl definition

2013-08-02 Thread jeroen at asystance dot nl
Edit report at https://bugs.php.net/bug.php?id=49155edit=1

 ID: 49155
 Comment by: jeroen at asystance dot nl
 Reported by:jeroen at asystance dot nl
 Summary:SoapServer passes parameters as null if one has
 special wsdl definition
 Status: Feedback
 Type:   Bug
 Package:SOAP related
 Operating System:   linux
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Still not fixed in PHP 5.4.19-dev


Previous Comments:

[2013-08-02 04:26:54] yohg...@php.net

Please try using this snapshot:

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

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

I see several fixes in soap module. Could you try 5.4?


[2012-04-26 08:30:22] nicolodien at gmx dot de

Hi everybody

I just want to confirm that this is still an issue! I've spent more than 3 
hours debugging until I finally found this bug description giving me a 
solution. 

Please DO fix this problem...
Thanks


[2011-02-11 12:25:22] jeroen at asystance dot nl

Just wanted to verify that this bug is still present in 5.3.3


[2009-08-05 12:22:29] jeroen at asystance dot nl

Sorry for posting yet another comment, but it gets even weirder:

wsdl:message name=someRequest
  wsdl:part name=customerId element=tns:customerId/wsdl:part
  wsdl:part name=customerDetails element=tns:customer/wsdl:part
/wsdl:message
This will not work, because in the first part, the name==element

However,
wsdl:message name=someRequest
  wsdl:part name=customerId element=tns:customerId/wsdl:part
  wsdl:part name=customer element=tns:customer/wsdl:part
/wsdl:message
_will_ work! Notice that now both parts are specified with name==element!


My conclusion so far is that either _all_ of the parts need to be specified 
with the name==element pattern, or _none_. If one of the parts uses the 
pattern, the rest needs to conform, or else the SoapServer passes them as null.

I sure hope this helps! I've been struggling with this for a while now.


[2009-08-05 11:53:25] jeroen at asystance dot nl

I have been able to further pin down the bug. The 2nd parameter is passed as 
null if, in the wsdl:message definition, the 1st wsdl:part element's name 
attribute is the same as the element attribute!

wsdl:message name=someRequest
  wsdl:part name=customerId element=tns:customerId/wsdl:part
  wsdl:part name=fail element=tns:customerId/wsdl:part
/wsdl:message
Here the 1st parameter works, but the second is always null!

wsdl:message name=someRequest
  wsdl:part name=cid element=tns:customerId/wsdl:part
  wsdl:part name=win element=tns:customerId/wsdl:part
/wsdl:message
Now both parameters work.


More generally, if one wsdl:part is specified in this way (name and element 
are the same), _every other parameter_ is passed as null:

wsdl:message name=someRequest
  wsdl:part name=p1 element=tns:customerId/wsdl:part
  wsdl:part name=customerId element=tns:customerId/wsdl:part
  wsdl:part name=p3 element=tns:customerId/wsdl:part
/wsdl:message
Here, p1 and p2 will be null, and customerId will work.

Happy bugfixing! :)




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


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


Bug #65372 [Ver-Csd]: Segfault in gc_zval_possible_root when return reference fails

2013-08-02 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=65372edit=1

 ID: 65372
 Updated by: larue...@php.net
 Reported by:sreed at ontraport dot com
 Summary:Segfault in gc_zval_possible_root when return
 reference fails
-Status: Verified
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Fedora
 PHP Version:5.4Git-2013-08-01 (Git)
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

fixed in http://git.php.net/?p=php-
src.git;a=commitdiff;h=ce9169e360701ea3b1ab2366171c24d4de5e78e3


Previous Comments:

[2013-08-02 01:59:23] larue...@php.net

The following patch has been added/updated:

Patch Name: bug65372.patch
Revision:   1375408763
URL:
https://bugs.php.net/patch-display.php?bug=65372patch=bug65372.patchrevision=1375408763


[2013-08-01 19:18:26] sreed at ontraport dot com

Description:

PHP is segfaulting during shutdown in gc_zval_possible_root. This bug appears 
to 
have appeared in version 5.4: http://3v4l.org/qLqe3.


Test script:
---
https://gist.github.com/sreed-ontraport/6134324

Expected result:

Script executes and PHP exits cleanly

Actual result:
--
0x006a0032 in gc_zval_possible_root (zv=0x77fc5108) at /tmp/php5.4-
201308011830/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);

(gdb) bt
#0  0x006a0032 in gc_zval_possible_root (zv=0x77fc5108) at 
/tmp/php5.4-201308011830/Zend/zend_gc.c:143
#1  0x006a1c47 in zend_object_std_dtor (object=0x77fc8970) at 
/tmp/php5.4-201308011830/Zend/zend_objects.c:54
#2  0x006a1c79 in zend_objects_free_object_storage 
(object=0x77fc8970) at /tmp/php5.4-201308011830/Zend/zend_objects.c:137
#3  0x006a74c8 in zend_objects_store_free_object_storage 
(objects=0xd8a0a0 executor_globals+960) at /tmp/php5.4-
201308011830/Zend/zend_objects_API.c:92
#4  0x0067396b in shutdown_executor () at /tmp/php5.4-
201308011830/Zend/zend_execute_API.c:295
#5  0x00681aa6 in zend_deactivate () at /tmp/php5.4-
201308011830/Zend/zend.c:938
#6  0x0062417d in php_request_shutdown (dummy=dummy@entry=0x0) at 
/tmp/php5.4-201308011830/main/main.c:1803
#7  0x00726094 in do_cli (argc=2, argv=0x7fffe148) at /tmp/php5.4-
201308011830/sapi/cli/php_cli.c:1172
#8  0x004255ca in main (argc=2, argv=0x7fffe148) at /tmp/php5.4-
201308011830/sapi/cli/php_cli.c:1365






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


Bug #65367 [Opn-Csd]: Segmentation fault when mixing = and =

2013-08-02 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=65367edit=1

 ID: 65367
 Updated by: larue...@php.net
 Reported by:mbecc...@php.net
 Summary:Segmentation fault when mixing = and =
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Any
 PHP Version:5.5.1
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

fixed in http://git.php.net/?p=php-
src.git;a=commitdiff;h=ce9169e360701ea3b1ab2366171c24d4de5e78e3


Previous Comments:

[2013-08-02 07:29:59] mbecc...@php.net

Yes, the patch fixes the issue as far as I can tell. Well done!


[2013-08-02 02:00:15] larue...@php.net

could you please verify the fix I attached at #65372?
thanks


[2013-08-02 01:11:26] larue...@php.net

Seems similar to #65372


[2013-07-31 11:13:15] mbecc...@php.net

I forgot to mention that you can easily install the necessary PEAR libraries in 
the current dir without polluting the global PEAR installation with:

pear install -R . MDB2 MDB2#pgsql


[2013-07-31 11:10:29] mbecc...@php.net

Description:

While updating an old open source application to work with PHP 5.4 and 5.5, I 
somehow managed to trigger a segmentation fault when removing an = assignment. 
I've been able to write a small reproduce script, which however still requires 
MDB2 from PEAR (tested only with the pgsql driver).

Changing back a specific assignment to = prevents the shutdown segfault from 
happening.

The code works fine with 5.3 and crashes on 5.4+. Tested on Windows and Linux.

Test script:
---
?php

require './usr/share/php/MDB2.php';

class A {
static function singleton()
{
$db = 
MDB2::connect('pgsql://postgres:password@localhost/postgres');
$db-loadModule('Datatype');

$GLOBALS['DB'] = $db; // Using = $db doesn't crash

return $GLOBALS['DB'];
}
}

class B {
function __construct()
{
$this-db = $this-getDb();
}

function getDB()
{
return A::singleton();
}
}

$b = new B();


Expected result:

PHP Notice:  Only variable references should be returned by reference in 
foobar.php on line 25


Actual result:
--
#0  0x00812979 in gc_zval_possible_root (zv=0x7fffeef256e0) at 
/root/compile/php-5.5.1/Zend/zend_gc.c:143
No locals.
#1  0x00801268 in zend_hash_destroy (ht=0x7fffeef2b4a0) at 
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2b860
q = 0x7fffeef2b7b0
#2  0x007f206b in _zval_dtor_func (zvalue=0x7fffeef2b470) at 
/root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#3  0x007e3178 in _zval_dtor (zvalue=0x7fffeef2b470) at 
/root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#4  i_zval_ptr_dtor (zval_ptr=0x7fffeef2b470) at 
/root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#5  _zval_ptr_dtor (zval_ptr=optimized out) at 
/root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#6  0x00801268 in zend_hash_destroy (ht=0x7fffeef28b10) at 
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2bfd0
q = 0x7fffeef2ba80
#7  0x007f206b in _zval_dtor_func (zvalue=0x7fffeef28778) at 
/root/compile/php-5.5.1/Zend/zend_variables.c:45
No locals.
#8  0x007e3178 in _zval_dtor (zvalue=0x7fffeef28778) at 
/root/compile/php-5.5.1/Zend/zend_variables.h:35
No locals.
#9  i_zval_ptr_dtor (zval_ptr=0x7fffeef28778) at 
/root/compile/php-5.5.1/Zend/zend_execute.h:81
No locals.
#10 _zval_ptr_dtor (zval_ptr=optimized out) at 
/root/compile/php-5.5.1/Zend/zend_execute_API.c:426
No locals.
#11 0x00801268 in zend_hash_destroy (ht=0x7fffeef2cbb8) at 
/root/compile/php-5.5.1/Zend/zend_hash.c:560
p = 0x7fffeef2ce78
q = 0x7fffeef2ce20
#12 0x0081579c in zend_object_std_dtor (object=0x7fffeef27cb0) at 
/root/compile/php-5.5.1/Zend/zend_objects.c:44
No locals.
#13 0x00815829 in zend_objects_free_object_storage 
(object=0x7fffeef27cb0) at /root/compile/php-5.5.1/Zend/zend_objects.c:137
No locals.
#14 0x0081b476 in zend_objects_store_free_object_storage 
(objects=0x1085120)
at /root/compile/php-5.5.1/Zend/zend_objects_API.c:92
obj = optimized out
i = optimized out
#15 0x007e37e3 in shutdown_executor () at 
/root/compile/php-5.5.1/Zend/zend_execute_API.c:293
__orig_bailout = 0x7fffe460
__bailout = {{__jmpbuf = 

Bug #65230 [Ana-Wfx]: setting locale randomly broken

2013-08-02 Thread ab
Edit report at https://bugs.php.net/bug.php?id=65230edit=1

 ID: 65230
 Updated by: a...@php.net
 Reported by:xrstf-misc at yahoo dot com
 Summary:setting locale randomly broken
-Status: Analyzed
+Status: Wont fix
 Type:   Bug
 Package:*General Issues
 Operating System:   Windows 7 x64
 PHP Version:5.5.0
 Block user comment: N
 Private report: N

 New Comment:

And after all, locale has such issues on any platform. The solution is to use 
intl 
or custom localization functionality.


Previous Comments:

[2013-07-30 15:54:08] a...@php.net

This isnt 5.5 issue only, you can find it in any PHP version starting with 5.3. 
localeconv() isnt thread safe and using it with _configthreadlocale() might 
lead 
to unpredictable results. That's why bug #63688 was marked won't fix - a 
solution, if any, might be very tricky.


[2013-07-09 22:45:26] xrstf-misc at yahoo dot com

Description:

I am experiencing trouble setting the locale (with setlocale(LC_ALL, ...)) in 
my 
code. With PHP 5.4, it always worked as expected, with 5.5 it appears that the 
locale has been changed, but localeconv() is still returning old values and 
functions like printf('%f') do not behave as expected.

I have disabled the new Opcache, but the random behaviour persisted. I can't 
tell 
when it happens and why it sometimes doesn't work. It seems (to me) that there 
is 
some kind of threading problem, as I can have the same code in different 
browser 
tabs and get different results.

I am using PHP 5.5.0 VC11 TS x86 on Windows 7 x64, loaded as a module into my 
Apache 2.4.3, which is running as a service.

Test script:
---
?php

function test($locale, $value) {
  $newlocale = setlocale(LC_ALL, $locale);
  $conv  = localeconv();
  $sep   = $conv['decimal_point'];

  printf(%s\n--\n, $newlocale);
  printf( sep: %s\n, $sep);
  printf(  %%f: %f\n, $value);
  printf(  %%F: %F\n, $value);
  printf(date: %s\n, strftime('%x'));
  printf(\n);
}

test('german', 3.41);
test('english', 3.41);
test('french', 3.41);
test('german', 3.41);

Expected result:

German_Germany.1252
--
 sep: ,
  %f: 3,41
  %F: 3.41
date: 10.07.2013

English_United States.1252
--
 sep: .
  %f: 3.41
  %F: 3.41
date: 7/10/2013

French_France.1252
--
 sep: ,
  %f: 3,41
  %F: 3.41
date: 10/07/2013

German_Germany.1252
--
 sep: ,
  %f: 3,41
  %F: 3.41
date: 10.07.2013


Actual result:
--
German_Germany.1252
--
 sep: .
  %f: 3.41
  %F: 3.41
date: 10.07.2013

English_United States.1252
--
 sep: .
  %f: 3.41
  %F: 3.41
date: 7/10/2013

French_France.1252
--
 sep: .
  %f: 3.41
  %F: 3.41
date: 10/07/2013

German_Germany.1252
--
 sep: .
  %f: 3.41
  %F: 3.41
date: 10.07.2013







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


Bug #61268 [Asn]: --enable-dtrace leads make to clobber Zend/zend_dtrace.d

2013-08-02 Thread sixd
Edit report at https://bugs.php.net/bug.php?id=61268edit=1

 ID: 61268
 Updated by: s...@php.net
 Reported by:mike at harschsystems dot com
 Summary:--enable-dtrace leads make to clobber
 Zend/zend_dtrace.d
 Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   solaris
 PHP Version:5.4.0
 Assigned To:dsp
 Block user comment: N
 Private report: N

 New Comment:

After some investigation, I think the easiest patch is below.  This has only 
been tested on Linux in one install scenario.  I'll continuing testing after 
the weekend.

diff --git a/acinclude.m4 b/acinclude.m4
index 07b1f8e..01eabf2 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -2962,8 +2962,12 @@ dnl DTrace objects
   esac
 
 dnl Generate Makefile.objects entries
+dnl The empty $ac_provsrc command stops an implicit circular dependency
+dnl triggering which lead to the .d file being overwritten with GNU make (Bug 
61268)
   catMakefile.objectsEOF
 
+$abs_srcdir/$ac_provsrc:;
+
 $ac_bdir[$]ac_hdrobj: $abs_srcdir/$ac_provsrc
CFLAGS=\$(CFLAGS_CLEAN) dtrace -h -C -s $ac_srcdir[$]ac_provsrc -o 
\$[]@  cp \$[]@ \$[]@.bak  \$(SED) 's,PHP_,DTRACE_,g' \$[]@.bak  \$[]@


Previous Comments:

[2013-08-03 01:14:49] s...@php.net

Related To: Bug #61268


[2013-07-23 10:54:27] eugene at zhegan dot in

Still there on 5.5.1.


[2013-02-18 16:11:27] mike at harschsystems dot com

Change from closed to assigned.


[2013-02-18 16:10:16] mike at harschsystems dot com

This bug should not be closed unless someone can confirm that the broken 
behavior 
has been corrected.  The issue is described in detail below.  The requested 
feedback was provided and the issue was reproduced by multiple people on 
several 
versions.


[2013-02-18 00:35:43] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.




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


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