Bug #51347 [Fbk->Opn]: mysqli_close / connection memory leak

2010-05-14 Thread mat999 at gmail dot com 
Edit report at http://bugs.php.net/bug.php?id=51347&edit=1

 ID:   51347
 User updated by:  mat999 at gmail dot com
 Reported by:  mat999 at gmail dot com
 Summary:  mysqli_close / connection memory leak
-Status:   Feedback
+Status:   Open
 Type: Bug
 Package:  MySQLi related
 Operating System: Debian Lenny / Linux
 PHP Version:  5.3.2
 Assigned To:  mysql

 New Comment:

Thanks, your patch has fixed the issue.



Memory consumption after 0 iterations is 628552

Memory consumption after 1000 iterations is 628584

Memory consumption after 2000 iterations is 628584

Memory consumption after 3000 iterations is 628584

Memory consumption after 4000 iterations is 628584

Memory consumption after 5000 iterations is 628584

Memory consumption after 6000 iterations is 628584

Memory consumption after 7000 iterations is 628584

Memory consumption after 8000 iterations is 628584

Memory consumption after 9000 iterations is 628584

Memory consumption after 1 iterations is 628584

Memory consumption after 11000 iterations is 628584

Memory consumption after 12000 iterations is 628584

Memory consumption after 13000 iterations is 628584

Memory consumption after 14000 iterations is 628584

Memory consumption after 15000 iterations is 628584

Memory consumption after 16000 iterations is 628584

Memory consumption after 17000 iterations is 628584

Memory consumption after 18000 iterations is 628584

Memory consumption after 19000 iterations is 628584

Memory consumption after 2 iterations is 628584

Memory consumption after 21000 iterations is 628584

Memory consumption after 22000 iterations is 628584

Memory consumption after 23000 iterations is 628584

Memory consumption after 24000 iterations is 628584

Memory consumption after 25000 iterations is 628584

Memory consumption after 26000 iterations is 628584

Memory consumption after 27000 iterations is 628584

Memory consumption after 28000 iterations is 628584

Memory consumption after 29000 iterations is 628584

Memory consumption after 3 iterations is 628584

Memory consumption after 31000 iterations is 628584

Memory consumption after 32000 iterations is 628584

Memory consumption after 33000 iterations is 628584

Memory consumption after 34000 iterations is 628584

Memory consumption after 35000 iterations is 628584

Memory consumption after 36000 iterations is 628584

Memory consumption after 37000 iterations is 628584

Memory consumption after 38000 iterations is 628584

Memory consumption after 39000 iterations is 628584

Memory consumption after 4 iterations is 628584

Memory consumption after 41000 iterations is 628584

Memory consumption after 42000 iterations is 628584

Memory consumption after 43000 iterations is 628584

Memory consumption after 44000 iterations is 628584

Memory consumption after 45000 iterations is 628584

Memory consumption after 46000 iterations is 628584


Previous Comments:

[2010-05-14 15:16:37] mat999 at gmail dot com

Working on it at the moment. Ill try to get results by the end of the
weekend.


[2010-05-11 12:10:19] and...@php.net

Yes, 5.3.2 has it, the fix I committed is in 5.3.3-dev, the future
5.3.3. I asked that you try it, if possible. Sources are available at
http://snaps.php.net


[2010-04-25 07:08:57] mat999 at gmail dot com

Ok tested it on php 5.3.2, sorry had issues getting php to build on my
server (some hacks to get other stuff compiled have screwed with libs)



Memory consumption after 0 iterations is 637088

Memory consumption after 1000 iterations is 829464

Memory consumption after 2000 iterations is 1021680

Memory consumption after 3000 iterations is 1222080

Memory consumption after 4000 iterations is 1406088

Memory consumption after 5000 iterations is 1622856

Memory consumption after 6000 iterations is 1806856

Memory consumption after 7000 iterations is 1990864

Memory consumption after 8000 iterations is 2174872

Memory consumption after 9000 iterations is 2424448

Memory consumption after 1 iterations is 2608448

Memory consumption after 11000 iterations is 2792464

Memory consumption after 12000 iterations is 2976472

Memory consumption after 13000 iterations is 3160480

Memory consumption after 14000 iterations is 3344480

Memory consumption after 15000 iterations is 3528496

Memory consumption after 16000 iterations is 3712504

Memory consumption after 17000 iterations is 4027576

Memory consumption after 18000 iterations is 4211640

Memory consumption after 19000 iterations is 4395640

Memory consumption after 2 iterations is 4579648

Memory consumption after 21000 iterations is 4763656

Memory consumption after 22000 iterations is 4947656

Memory consumption after 23000 iterations is 5131672

Bug #51827 [Opn->Csd]: Bad warning when register_shutdown_function called with wrong num of parameters

2010-05-14 Thread felipe 
Edit report at http://bugs.php.net/bug.php?id=51827&edit=1

 ID:   51827
 Updated by:   fel...@php.net
 Reported by:  andrew dot guertin at uvm dot edu
 Summary:  Bad warning when register_shutdown_function called
   with wrong num of parameters
-Status:   Open
+Status:   Closed
 Type: Bug
 Package:  Unknown/Other Function
 Operating System: Linux
 PHP Version:  5.3.2
-Assigned To:  
+Assigned To:  felipe

 New Comment:

This bug has been fixed in SVN.

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




Previous Comments:

[2010-05-15 01:48:06] fel...@php.net

Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=299395
Log: - Fixed bug #51827 (Bad warning when register_shutdown_function
called with wrong num of parameters)


[2010-05-14 17:42:27] andrew dot guertin at uvm dot edu

Description:

When register_shutdown_function is called with a function that expects a
certain number of parameters, and a different number are given, a very
unhelpful warning is printed:



Warning: (null)() expects exactly 1 parameter, 0 given in Unknown on
line 0



This can take slightly different forms:



Warning: (null)() expects at least 2 parameters, 1 given in Unknown on
line 0



or on a different server:



Warning: Wrong parameter count for (null)() in Unknown on line 0

Test script:
---


Expected result:

I expect to be given the correct function name, filename, and line
number in the warning.

Actual result:
--
I am given useless information for function name, filename, and line
number.






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

Bug #51829 [Opn->Bgs]: Array output unexpected result

2010-05-14 Thread dtajchreber 
Edit report at http://bugs.php.net/bug.php?id=51829&edit=1

 ID:   51829
 Updated by:   dtajchre...@php.net
 Reported by:  josefrancklin at yahoo dot com dot br
 Summary:  Array output unexpected result
-Status:   Open
+Status:   Bogus
 Type: Bug
 Package:  Arrays related
 Operating System: Windows XP
 PHP Version:  5.3.2

 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

You have discovered type juggling. See:
http://www.php.net/manual/en/language.types.string.php#language.types.string.conversion



'x' turns into 0. 0 == 0. Your if statement is never executed.


Previous Comments:

[2010-05-14 20:09:16] josefrancklin at yahoo dot com dot br

Description:

Code typed below generates unexpected result in the [0] term from an
array.

Test script:
---
for ($i=0;$i<3;$i++)

{

$array_id=array( 0 => 0 , 1 => 1 , 2 => 2 );

$array_id[$i]="x";

for ($j=0;$j<3;$j++)

{

print "term [$j] is $array_id[$j]";

if ($array_id[$j]!=$j)

print ", not $j";

print "\n";

}

print "\n";

}



Expected result:

term [0] is x, not 0

term [1] is 1

term [2] is 2



term [0] is 0

term [1] is x, not 1

term [2] is 2



term [0] is 0

term [1] is 1

term [2] is x, not 2





Actual result:
--
array[0] is x

array[1] is 1

array[2] is 2



array[0] is 0

array[1] is x, not 1

array[2] is 2



array[0] is 0

array[1] is 1

array[2] is x, not 2










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

Bug #51760 [Opn]: Memory Leak: zend hash not properly destroyed in CGI main

2010-05-14 Thread russell dot tempero at rightnow dot com 
Edit report at http://bugs.php.net/bug.php?id=51760&edit=1

 ID:   51760
 User updated by:  russell dot tempero at rightnow dot com
 Reported by:  russell dot tempero at rightnow dot com
 Summary:  Memory Leak: zend hash not properly destroyed in CGI
   main
 Status:   Open
 Type: Bug
 Package:  Performance problem
 Operating System: Linux
 PHP Version:  5.3.2

 New Comment:

In my patch I forgot to set ht->pListHead to NULL. The following line
should be added toward the end of the zend_hash_destroy() function:



ht->pListHead = NULL;


Previous Comments:

[2010-05-06 23:57:27] russell dot tempero at rightnow dot com

Description:

After upgrading to PHP 5.3.2, we ran it through Purify and noticed the
following memory leak:



MLK: 32 bytes leaked at 0x9b70ca8

  * This memory was allocated from:

calloc [rtlib.o]

_zend_hash_init [zend_hash.c:168]

php_cgi_globals_ctor [cgi_main.c:1429]

allocate_new_resource [TSRM.c:303]

ts_resource_ex [TSRM.c:370]

.

.

.



The problem is that php_cgi_globals_ctor() (the constructor) is calling
zend_hash_init() but there is no corresponding destructor to call
zend_hash_destroy(). I have attached a patch that will fix this.



You will notice in the patch that I had to make changes to
zend_hash_destroy() to prevent a double free. Apparently there are
places that are already calling zend_hash_destroy() for the hash that is
initialized in php_cgi_globals_ctor(), but it is not currently getting
called all of the time. Perhaps a more correct fix would be to find
where these other calls to zend_hash_destroy() are being made and either
eliminate them altogether or make sure they are called all of the time
and not have the destructor function.







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

[PHP-BUG] Bug #51829 [NEW]: Array output unexpected result

2010-05-14 Thread josefrancklin at yahoo dot com dot br 
From: 
Operating system: Windows XP
PHP version:  5.3.2
Package:  Arrays related
Bug Type: Bug
Bug description:Array output unexpected result

Description:

Code typed below generates unexpected result in the [0] term from an array.

Test script:
---
for ($i=0;$i<3;$i++)

{

$array_id=array( 0 => 0 , 1 => 1 , 2 => 2 );

$array_id[$i]="x";

for ($j=0;$j<3;$j++)

{

print "term [$j] is $array_id[$j]";

if ($array_id[$j]!=$j)

print ", not $j";

print "\n";

}

print "\n";

}



Expected result:

term [0] is x, not 0

term [1] is 1

term [2] is 2



term [0] is 0

term [1] is x, not 1

term [2] is 2



term [0] is 0

term [1] is 1

term [2] is x, not 2





Actual result:
--
array[0] is x

array[1] is 1

array[2] is 2



array[0] is 0

array[1] is x, not 1

array[2] is 2



array[0] is 0

array[1] is 1

array[2] is x, not 2





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

Bug #51826 [Opn]: maybe a wrong oop logic.

2010-05-14 Thread 1000235409 at smail dot shnu dot edu dot cn 
Edit report at http://bugs.php.net/bug.php?id=51826&edit=1

 ID:   51826
 User updated by:  1000235409 at smail dot shnu dot edu dot cn
 Reported by:  1000235409 at smail dot shnu dot edu dot cn
 Summary:  maybe a wrong oop logic.
 Status:   Open
 Type: Bug
 Package:  Class/Object related
 Operating System: WINDOWS
 PHP Version:  5.3SVN-2010-05-14 (SVN)

 New Comment:

I have adapted those code(see it below) into delphi(object pascal, on 

Delphi2010), however, nothing wrong at all. so i think it should be a
wrong oop 

logic in php5(5.2 included also, since i've tested then...)



Type

  TAbstractParam = Class(TInterfacedObject)

Procedure getType(); Virtual; Abstract;

  End;



  IParam = Interface

Procedure getType();

  End;



  TPrimativeParam = Class(TAbstractParam, IParam)

Procedure getType();

  End;

//Other code omitted...


Previous Comments:

[2010-05-14 17:15:02] 1000235409 at smail dot shnu dot edu dot cn

Description:

A fatal error generates when a class extends from an abstract class and
implements 

from an interface both with a same named abstract (all methods defined
inside 

interfaces are abstract) method inside.

Test script:
---
http://bugs.php.net/bug.php?id=51826&edit=1

[PHP-BUG] Bug #51827 [NEW]: Bad warning when register_shutdown_function called with wrong num of parameters

2010-05-14 Thread andrew dot guertin at uvm dot edu 
From: 
Operating system: Linux
PHP version:  5.3.2
Package:  Unknown/Other Function
Bug Type: Bug
Bug description:Bad warning when register_shutdown_function called with wrong 
num of parameters

Description:

When register_shutdown_function is called with a function that expects a
certain number of parameters, and a different number are given, a very
unhelpful warning is printed:



Warning: (null)() expects exactly 1 parameter, 0 given in Unknown on line
0



This can take slightly different forms:



Warning: (null)() expects at least 2 parameters, 1 given in Unknown on line
0



or on a different server:



Warning: Wrong parameter count for (null)() in Unknown on line 0

Test script:
---


Expected result:

I expect to be given the correct function name, filename, and line number
in the warning.

Actual result:
--
I am given useless information for function name, filename, and line
number.

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

[PHP-BUG] Bug #51826 [NEW]: maybe a wrong oop logic.

2010-05-14 Thread 1000235409 at smail dot shnu dot edu dot cn 
From: 
Operating system: WINDOWS
PHP version:  5.3SVN-2010-05-14 (SVN)
Package:  Class/Object related
Bug Type: Bug
Bug description:maybe a wrong oop logic.

Description:

A fatal error generates when a class extends from an abstract class and
implements 

from an interface both with a same named abstract (all methods defined
inside 

interfaces are abstract) method inside.

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

Bug #51825 [Opn->Bgs]: Calling a static property with a dynamic class name fails

2010-05-14 Thread felipe 
Edit report at http://bugs.php.net/bug.php?id=51825&edit=1

 ID:   51825
 Updated by:   fel...@php.net
 Reported by:  anis dot berejeb at gmail dot com
 Summary:  Calling a static property with a dynamic class name
   fails
-Status:   Open
+Status:   Bogus
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: Ubuntu 9.10
 PHP Version:  5.2.13

 New Comment:

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

This feature was added in 5.3.0.



http://docs.php.net/manual/en/language.oop5.static.php


Previous Comments:

[2010-05-14 17:07:53] anis dot berejeb at gmail dot com

Description:

When we call a static property with a dynamic class name, the call fails

Test script:
---
http://bugs.php.net/bug.php?id=51825&edit=1

[PHP-BUG] Bug #51825 [NEW]: Calling a static property with a dynamic class name fails

2010-05-14 Thread anis dot berejeb at gmail dot com 
From: 
Operating system: Ubuntu 9.10
PHP version:  5.2.13
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Calling a static property with a dynamic class name fails

Description:

When we call a static property with a dynamic class name, the call fails

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

[PHP-BUG] Bug #51824 [NEW]: date('I') always return '0' in Windows

2010-05-14 Thread ng4rrjanbiah at rediffmail dot com 
From: 
Operating system: Windows XP
PHP version:  5.3.2
Package:  Date/time related
Bug Type: Bug
Bug description:date('I') always return '0' in Windows

Description:

date('I') always return 0 in Windows; but returns according to DST in
Linux



Note: found http://bugs.php.net/13900 which is filed for PHP4 and flagged
as 

"bogus"

Test script:
---







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

Bug #51822 [Com]: Segfault with strange __destruct() for static class variables

2010-05-14 Thread daan at react dot com 
Edit report at http://bugs.php.net/bug.php?id=51822&edit=1

 ID:   51822
 Comment by:   daan at react dot com
 Reported by:  daan at react dot com
 Summary:  Segfault with strange __destruct() for static class
   variables
 Status:   Verified
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: Debian Etch
 PHP Version:  5.2.13

 New Comment:

Reference to bugreport at xdebug:

http://bugs.xdebug.org/view.php?id=580


Previous Comments:

[2010-05-14 15:14:51] daan at react dot com

Hmm looks like it might be xdebug related.. 

"#1  0xb739e2f2 in xdebug_execute (op_array=0x9ce5214) at
/tmp/pear/temp/xdebug/xdebug.c:1392"



I tried it on a non-xdebug php 5.2.10, and that had no problems - the
5.3.1 I tested with did not have xdebug installed either.



Will throw the bug that way then.. apologies for the misdirected bug
report!


[2010-05-14 15:04:40] daan at react dot com

JIC you still need it - a trace:



#0  0x0837f473 in zend_hash_find (ht=0x9ce0398, arKey=0xb73babed "",
nKeyLength=5, pData=0xbfc0ea7c)

at /usr/src/php-5.2.13/Zend/zend_hash.c:880

#1  0xb739e2f2 in xdebug_execute (op_array=0x9ce5214) at
/tmp/pear/temp/xdebug/xdebug.c:1392

#2  0x08368c20 in zend_call_function (fci=0xbfc0ebec,
fci_cache=0xbfc0ec10)

at /usr/src/php-5.2.13/Zend/zend_execute_API.c:1039

#3  0x08387b2c in zend_call_method (object_pp=0xbfc0ec94,
obj_ce=0x9ce3c0c, fn_proxy=0xbfc0ec98, 

function_name=0x8638cb8 "__destruct", function_name_len=10,
retval_ptr_ptr=0x0, param_count=0, arg1=0x0, 

arg2=0x0) at /usr/src/php-5.2.13/Zend/zend_interfaces.c:88

#4  0x0838da67 in zend_objects_destroy_object (object=0x9ce4898,
handle=1)

at /usr/src/php-5.2.13/Zend/zend_objects.c:101

#5  0x08390d30 in zend_objects_store_del_ref_by_handle (handle=1)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:198

#6  0x08390d75 in zend_objects_store_del_ref (zobject=0x9ce22c4)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:169

#7  0x08367ee9 in _zval_ptr_dtor (zval_ptr=0x9ce4928) at
/usr/src/php-5.2.13/Zend/zend_variables.h:35

#8  0x0837e245 in zend_hash_destroy (ht=0x9ce48ec) at
/usr/src/php-5.2.13/Zend/zend_hash.c:526

#9  0x0838dc07 in zend_object_std_dtor (object=0x9ce3284) at
/usr/src/php-5.2.13/Zend/zend_objects.c:45

#10 0x0838dc40 in zend_objects_free_object_storage (object=0x9ce3284)

at /usr/src/php-5.2.13/Zend/zend_objects.c:122

#11 0x08390d52 in zend_objects_store_del_ref_by_handle (handle=2)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:211

#12 0x08390d75 in zend_objects_store_del_ref (zobject=0x9ce48d4)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:169

#13 0x08367ee9 in _zval_ptr_dtor (zval_ptr=0x9ce46f8) at
/usr/src/php-5.2.13/Zend/zend_variables.h:35

#14 0x0837e245 in zend_hash_destroy (ht=0x9ce4548) at
/usr/src/php-5.2.13/Zend/zend_hash.c:526

#15 0x0836c123 in destroy_zend_class (pce=0x9d1a78c) at
/usr/src/php-5.2.13/Zend/zend_opcode.c:184

#16 0x0837de9c in zend_hash_apply_deleter (ht=0x9b136a0, p=0x9d1a780)

at /usr/src/php-5.2.13/Zend/zend_hash.c:611

#17 0x0837dfcb in zend_hash_reverse_apply (ht=0x9b136a0,
apply_func=0x83675b0 )

at /usr/src/php-5.2.13/Zend/zend_hash.c:760

#18 0x0836a8b6 in shutdown_executor () at
/usr/src/php-5.2.13/Zend/zend_execute_API.c:291

#19 0x083752e4 in zend_deactivate () at
/usr/src/php-5.2.13/Zend/zend.c:860

#20 0x083356eb in php_request_shutdown (dummy=0x0) at
/usr/src/php-5.2.13/main/main.c:1504

#21 0x083e0872 in main (argc=2, argv=0xbfc0f4f4) at
/usr/src/php-5.2.13/sapi/cli/php_cli.c:1346


[2010-05-14 15:00:16] fel...@php.net

In fact I got something on Valgring log:



Invalid write & read and:

==5285==  Address 0x65f0ba4 is 4 bytes inside a block of size 256
free'd

==5285==at 0x4024866: free (vg_replace_malloc.c:325)

==5285==by 0x83ACBD6: _efree (zend_alloc.c:2308)

==5285==by 0x83CD787: zend_ptr_stack_destroy (zend_ptr_stack.c:74)

==5285==by 0x83BE48B: shutdown_executor (zend_execute_API.c:283)

==5285==by 0x83D05D9: zend_deactivate (zend.c:860)

==5285==by 0x836D12B: php_request_shutdown (main.c:1504)

==5285==by 0x8459950: main (php_cli.c:1346)


[2010-05-14 14:58:06] fel...@php.net

Please try using this snapshot:

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

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

I cannot reproduce it on 5_2 SVN.


[2010-05-14 14:38:49] daan at react dot com

Description:

When a static class variable is assigned a nested destructable object,
it behaves differently when assigned before or after the instantiation
a

Bug #51347 [Com]: mysqli_close / connection memory leak

2010-05-14 Thread mat999 at gmail dot com 
Edit report at http://bugs.php.net/bug.php?id=51347&edit=1

 ID:   51347
 Comment by:   mat999 at gmail dot com
 Reported by:  mat999 at gmail dot com
 Summary:  mysqli_close / connection memory leak
 Status:   Feedback
 Type: Bug
 Package:  MySQLi related
 Operating System: Debian Lenny / Linux
 PHP Version:  5.3.2
 Assigned To:  mysql

 New Comment:

Working on it at the moment. Ill try to get results by the end of the
weekend.


Previous Comments:

[2010-05-11 12:10:19] and...@php.net

Yes, 5.3.2 has it, the fix I committed is in 5.3.3-dev, the future
5.3.3. I asked that you try it, if possible. Sources are available at
http://snaps.php.net


[2010-04-25 07:08:57] mat999 at gmail dot com

Ok tested it on php 5.3.2, sorry had issues getting php to build on my
server (some hacks to get other stuff compiled have screwed with libs)



Memory consumption after 0 iterations is 637088

Memory consumption after 1000 iterations is 829464

Memory consumption after 2000 iterations is 1021680

Memory consumption after 3000 iterations is 1222080

Memory consumption after 4000 iterations is 1406088

Memory consumption after 5000 iterations is 1622856

Memory consumption after 6000 iterations is 1806856

Memory consumption after 7000 iterations is 1990864

Memory consumption after 8000 iterations is 2174872

Memory consumption after 9000 iterations is 2424448

Memory consumption after 1 iterations is 2608448

Memory consumption after 11000 iterations is 2792464

Memory consumption after 12000 iterations is 2976472

Memory consumption after 13000 iterations is 3160480

Memory consumption after 14000 iterations is 3344480

Memory consumption after 15000 iterations is 3528496

Memory consumption after 16000 iterations is 3712504

Memory consumption after 17000 iterations is 4027576

Memory consumption after 18000 iterations is 4211640

Memory consumption after 19000 iterations is 4395640

Memory consumption after 2 iterations is 4579648

Memory consumption after 21000 iterations is 4763656

Memory consumption after 22000 iterations is 4947656

Memory consumption after 23000 iterations is 5131672

Memory consumption after 24000 iterations is 5315680

Memory consumption after 25000 iterations is 5499688

Memory consumption after 26000 iterations is 5683688

Memory consumption after 27000 iterations is 5867704

Memory consumption after 28000 iterations is 6051712

Memory consumption after 29000 iterations is 6235712

Memory consumption after 3 iterations is 6419720

Memory consumption after 31000 iterations is 6603736

Memory consumption after 32000 iterations is 6787736

Memory consumption after 33000 iterations is 7233888

Memory consumption after 34000 iterations is 7417896

Memory consumption after 35000 iterations is 7601912

Memory consumption after 36000 iterations is 7785912

Memory consumption after 37000 iterations is 7969920

Memory consumption after 38000 iterations is 8153928

Memory consumption after 39000 iterations is 8337928

Memory consumption after 4 iterations is 8521944

Memory consumption after 41000 iterations is 8705952

Memory consumption after 42000 iterations is 8889952

Memory consumption after 43000 iterations is 9073960

Memory consumption after 44000 iterations is 9257976

Memory consumption after 45000 iterations is 9441984

Memory consumption after 46000 iterations is 9625984

Memory consumption after 47000 iterations is 9809992

Memory consumption after 48000 iterations is 9994008

Memory consumption after 49000 iterations is 10178008

Memory consumption after 5 iterations is 10362016

Memory consumption after 51000 iterations is 10546024

Memory consumption after 52000 iterations is 10730024

Memory consumption after 53000 iterations is 10914040

Memory consumption after 54000 iterations is 11098048

Memory consumption after 55000 iterations is 11282056

Memory consumption after 56000 iterations is 11466056

Memory consumption after 57000 iterations is 11650072

Memory consumption after 58000 iterations is 11834080

Memory consumption after 59000 iterations is 12018080

Memory consumption after 6 iterations is 12202088

Memory consumption after 61000 iterations is 12386104

Memory consumption after 62000 iterations is 12570104

Memory consumption after 63000 iterations is 12754112

Memory consumption after 64000 iterations is 12938120

Memory consumption after 65000 iterations is 13122136

Memory consumption after 66000 iterations is 13830424

Memory consumption after 67000 iterations is 14014432

Memory consumption after 68000 iterations is 14198440

Memory consumption after 69000 iterations is 14382440

Memory consumption after 7 iterations is 14566456

Memory consumption after 71000 iterations is 14750464

Memory consumption after 72000 iterations is 1493

Bug #51822 [Com]: Segfault with strange __destruct() for static class variables

2010-05-14 Thread daan at react dot com 
Edit report at http://bugs.php.net/bug.php?id=51822&edit=1

 ID:   51822
 Comment by:   daan at react dot com
 Reported by:  daan at react dot com
 Summary:  Segfault with strange __destruct() for static class
   variables
 Status:   Verified
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: Debian Etch
 PHP Version:  5.2.13

 New Comment:

Hmm looks like it might be xdebug related.. 

"#1  0xb739e2f2 in xdebug_execute (op_array=0x9ce5214) at
/tmp/pear/temp/xdebug/xdebug.c:1392"



I tried it on a non-xdebug php 5.2.10, and that had no problems - the
5.3.1 I tested with did not have xdebug installed either.



Will throw the bug that way then.. apologies for the misdirected bug
report!


Previous Comments:

[2010-05-14 15:04:40] daan at react dot com

JIC you still need it - a trace:



#0  0x0837f473 in zend_hash_find (ht=0x9ce0398, arKey=0xb73babed "",
nKeyLength=5, pData=0xbfc0ea7c)

at /usr/src/php-5.2.13/Zend/zend_hash.c:880

#1  0xb739e2f2 in xdebug_execute (op_array=0x9ce5214) at
/tmp/pear/temp/xdebug/xdebug.c:1392

#2  0x08368c20 in zend_call_function (fci=0xbfc0ebec,
fci_cache=0xbfc0ec10)

at /usr/src/php-5.2.13/Zend/zend_execute_API.c:1039

#3  0x08387b2c in zend_call_method (object_pp=0xbfc0ec94,
obj_ce=0x9ce3c0c, fn_proxy=0xbfc0ec98, 

function_name=0x8638cb8 "__destruct", function_name_len=10,
retval_ptr_ptr=0x0, param_count=0, arg1=0x0, 

arg2=0x0) at /usr/src/php-5.2.13/Zend/zend_interfaces.c:88

#4  0x0838da67 in zend_objects_destroy_object (object=0x9ce4898,
handle=1)

at /usr/src/php-5.2.13/Zend/zend_objects.c:101

#5  0x08390d30 in zend_objects_store_del_ref_by_handle (handle=1)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:198

#6  0x08390d75 in zend_objects_store_del_ref (zobject=0x9ce22c4)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:169

#7  0x08367ee9 in _zval_ptr_dtor (zval_ptr=0x9ce4928) at
/usr/src/php-5.2.13/Zend/zend_variables.h:35

#8  0x0837e245 in zend_hash_destroy (ht=0x9ce48ec) at
/usr/src/php-5.2.13/Zend/zend_hash.c:526

#9  0x0838dc07 in zend_object_std_dtor (object=0x9ce3284) at
/usr/src/php-5.2.13/Zend/zend_objects.c:45

#10 0x0838dc40 in zend_objects_free_object_storage (object=0x9ce3284)

at /usr/src/php-5.2.13/Zend/zend_objects.c:122

#11 0x08390d52 in zend_objects_store_del_ref_by_handle (handle=2)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:211

#12 0x08390d75 in zend_objects_store_del_ref (zobject=0x9ce48d4)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:169

#13 0x08367ee9 in _zval_ptr_dtor (zval_ptr=0x9ce46f8) at
/usr/src/php-5.2.13/Zend/zend_variables.h:35

#14 0x0837e245 in zend_hash_destroy (ht=0x9ce4548) at
/usr/src/php-5.2.13/Zend/zend_hash.c:526

#15 0x0836c123 in destroy_zend_class (pce=0x9d1a78c) at
/usr/src/php-5.2.13/Zend/zend_opcode.c:184

#16 0x0837de9c in zend_hash_apply_deleter (ht=0x9b136a0, p=0x9d1a780)

at /usr/src/php-5.2.13/Zend/zend_hash.c:611

#17 0x0837dfcb in zend_hash_reverse_apply (ht=0x9b136a0,
apply_func=0x83675b0 )

at /usr/src/php-5.2.13/Zend/zend_hash.c:760

#18 0x0836a8b6 in shutdown_executor () at
/usr/src/php-5.2.13/Zend/zend_execute_API.c:291

#19 0x083752e4 in zend_deactivate () at
/usr/src/php-5.2.13/Zend/zend.c:860

#20 0x083356eb in php_request_shutdown (dummy=0x0) at
/usr/src/php-5.2.13/main/main.c:1504

#21 0x083e0872 in main (argc=2, argv=0xbfc0f4f4) at
/usr/src/php-5.2.13/sapi/cli/php_cli.c:1346


[2010-05-14 15:00:16] fel...@php.net

In fact I got something on Valgring log:



Invalid write & read and:

==5285==  Address 0x65f0ba4 is 4 bytes inside a block of size 256
free'd

==5285==at 0x4024866: free (vg_replace_malloc.c:325)

==5285==by 0x83ACBD6: _efree (zend_alloc.c:2308)

==5285==by 0x83CD787: zend_ptr_stack_destroy (zend_ptr_stack.c:74)

==5285==by 0x83BE48B: shutdown_executor (zend_execute_API.c:283)

==5285==by 0x83D05D9: zend_deactivate (zend.c:860)

==5285==by 0x836D12B: php_request_shutdown (main.c:1504)

==5285==by 0x8459950: main (php_cli.c:1346)


[2010-05-14 14:58:06] fel...@php.net

Please try using this snapshot:

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

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

I cannot reproduce it on 5_2 SVN.


[2010-05-14 14:38:49] daan at react dot com

Description:

When a static class variable is assigned a nested destructable object,
it behaves differently when assigned before or after the instantiation
an object of the class to which the static property belongs.



When the variable is assigned after object instantiation, the process
segfaults.



(tested: PHP 5.3.1 behaves correctly)



Test

Bug #51822 [Com]: Segfault with strange __destruct() for static class variables

2010-05-14 Thread daan at react dot com 
Edit report at http://bugs.php.net/bug.php?id=51822&edit=1

 ID:   51822
 Comment by:   daan at react dot com
 Reported by:  daan at react dot com
 Summary:  Segfault with strange __destruct() for static class
   variables
 Status:   Verified
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: Debian Etch
 PHP Version:  5.2.13

 New Comment:

JIC you still need it - a trace:



#0  0x0837f473 in zend_hash_find (ht=0x9ce0398, arKey=0xb73babed "",
nKeyLength=5, pData=0xbfc0ea7c)

at /usr/src/php-5.2.13/Zend/zend_hash.c:880

#1  0xb739e2f2 in xdebug_execute (op_array=0x9ce5214) at
/tmp/pear/temp/xdebug/xdebug.c:1392

#2  0x08368c20 in zend_call_function (fci=0xbfc0ebec,
fci_cache=0xbfc0ec10)

at /usr/src/php-5.2.13/Zend/zend_execute_API.c:1039

#3  0x08387b2c in zend_call_method (object_pp=0xbfc0ec94,
obj_ce=0x9ce3c0c, fn_proxy=0xbfc0ec98, 

function_name=0x8638cb8 "__destruct", function_name_len=10,
retval_ptr_ptr=0x0, param_count=0, arg1=0x0, 

arg2=0x0) at /usr/src/php-5.2.13/Zend/zend_interfaces.c:88

#4  0x0838da67 in zend_objects_destroy_object (object=0x9ce4898,
handle=1)

at /usr/src/php-5.2.13/Zend/zend_objects.c:101

#5  0x08390d30 in zend_objects_store_del_ref_by_handle (handle=1)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:198

#6  0x08390d75 in zend_objects_store_del_ref (zobject=0x9ce22c4)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:169

#7  0x08367ee9 in _zval_ptr_dtor (zval_ptr=0x9ce4928) at
/usr/src/php-5.2.13/Zend/zend_variables.h:35

#8  0x0837e245 in zend_hash_destroy (ht=0x9ce48ec) at
/usr/src/php-5.2.13/Zend/zend_hash.c:526

#9  0x0838dc07 in zend_object_std_dtor (object=0x9ce3284) at
/usr/src/php-5.2.13/Zend/zend_objects.c:45

#10 0x0838dc40 in zend_objects_free_object_storage (object=0x9ce3284)

at /usr/src/php-5.2.13/Zend/zend_objects.c:122

#11 0x08390d52 in zend_objects_store_del_ref_by_handle (handle=2)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:211

#12 0x08390d75 in zend_objects_store_del_ref (zobject=0x9ce48d4)

at /usr/src/php-5.2.13/Zend/zend_objects_API.c:169

#13 0x08367ee9 in _zval_ptr_dtor (zval_ptr=0x9ce46f8) at
/usr/src/php-5.2.13/Zend/zend_variables.h:35

#14 0x0837e245 in zend_hash_destroy (ht=0x9ce4548) at
/usr/src/php-5.2.13/Zend/zend_hash.c:526

#15 0x0836c123 in destroy_zend_class (pce=0x9d1a78c) at
/usr/src/php-5.2.13/Zend/zend_opcode.c:184

#16 0x0837de9c in zend_hash_apply_deleter (ht=0x9b136a0, p=0x9d1a780)

at /usr/src/php-5.2.13/Zend/zend_hash.c:611

#17 0x0837dfcb in zend_hash_reverse_apply (ht=0x9b136a0,
apply_func=0x83675b0 )

at /usr/src/php-5.2.13/Zend/zend_hash.c:760

#18 0x0836a8b6 in shutdown_executor () at
/usr/src/php-5.2.13/Zend/zend_execute_API.c:291

#19 0x083752e4 in zend_deactivate () at
/usr/src/php-5.2.13/Zend/zend.c:860

#20 0x083356eb in php_request_shutdown (dummy=0x0) at
/usr/src/php-5.2.13/main/main.c:1504

#21 0x083e0872 in main (argc=2, argv=0xbfc0f4f4) at
/usr/src/php-5.2.13/sapi/cli/php_cli.c:1346


Previous Comments:

[2010-05-14 15:00:16] fel...@php.net

In fact I got something on Valgring log:



Invalid write & read and:

==5285==  Address 0x65f0ba4 is 4 bytes inside a block of size 256
free'd

==5285==at 0x4024866: free (vg_replace_malloc.c:325)

==5285==by 0x83ACBD6: _efree (zend_alloc.c:2308)

==5285==by 0x83CD787: zend_ptr_stack_destroy (zend_ptr_stack.c:74)

==5285==by 0x83BE48B: shutdown_executor (zend_execute_API.c:283)

==5285==by 0x83D05D9: zend_deactivate (zend.c:860)

==5285==by 0x836D12B: php_request_shutdown (main.c:1504)

==5285==by 0x8459950: main (php_cli.c:1346)


[2010-05-14 14:58:06] fel...@php.net

Please try using this snapshot:

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

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

I cannot reproduce it on 5_2 SVN.


[2010-05-14 14:38:49] daan at react dot com

Description:

When a static class variable is assigned a nested destructable object,
it behaves differently when assigned before or after the instantiation
an object of the class to which the static property belongs.



When the variable is assigned after object instantiation, the process
segfaults.



(tested: PHP 5.3.1 behaves correctly)



Test script:
---
test = new DestructableObject;   

}

}



class Test

{

public static $mystatic;

}



// Uncomment this to avoid segfault

//Test::$mystatic = new DestructorCreator();



$x = new Test();



if (!isset(Test::$mystatic))

Test::$mystatic = new DestructorCreator();



echo 'bla';

Expected result:

bla

Actual result:
--
Segfault

Bug #51822 [Fbk->Ver]: Segfault with strange __destruct() for static class variables

2010-05-14 Thread felipe 
Edit report at http://bugs.php.net/bug.php?id=51822&edit=1

 ID:   51822
 Updated by:   fel...@php.net
 Reported by:  daan at react dot com
 Summary:  Segfault with strange __destruct() for static class
   variables
-Status:   Feedback
+Status:   Verified
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: Debian Etch
 PHP Version:  5.2.13

 New Comment:

In fact I got something on Valgring log:



Invalid write & read and:

==5285==  Address 0x65f0ba4 is 4 bytes inside a block of size 256
free'd

==5285==at 0x4024866: free (vg_replace_malloc.c:325)

==5285==by 0x83ACBD6: _efree (zend_alloc.c:2308)

==5285==by 0x83CD787: zend_ptr_stack_destroy (zend_ptr_stack.c:74)

==5285==by 0x83BE48B: shutdown_executor (zend_execute_API.c:283)

==5285==by 0x83D05D9: zend_deactivate (zend.c:860)

==5285==by 0x836D12B: php_request_shutdown (main.c:1504)

==5285==by 0x8459950: main (php_cli.c:1346)


Previous Comments:

[2010-05-14 14:58:06] fel...@php.net

Please try using this snapshot:

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

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

I cannot reproduce it on 5_2 SVN.


[2010-05-14 14:38:49] daan at react dot com

Description:

When a static class variable is assigned a nested destructable object,
it behaves differently when assigned before or after the instantiation
an object of the class to which the static property belongs.



When the variable is assigned after object instantiation, the process
segfaults.



(tested: PHP 5.3.1 behaves correctly)



Test script:
---
test = new DestructableObject;   

}

}



class Test

{

public static $mystatic;

}



// Uncomment this to avoid segfault

//Test::$mystatic = new DestructorCreator();



$x = new Test();



if (!isset(Test::$mystatic))

Test::$mystatic = new DestructorCreator();



echo 'bla';

Expected result:

bla

Actual result:
--
Segfault






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

Bug #51822 [Opn->Fbk]: Segfault with strange __destruct() for static class variables

2010-05-14 Thread felipe 
Edit report at http://bugs.php.net/bug.php?id=51822&edit=1

 ID:   51822
 Updated by:   fel...@php.net
 Reported by:  daan at react dot com
 Summary:  Segfault with strange __destruct() for static class
   variables
-Status:   Open
+Status:   Feedback
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: Debian Etch
 PHP Version:  5.2.13

 New Comment:

Please try using this snapshot:

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

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

I cannot reproduce it on 5_2 SVN.


Previous Comments:

[2010-05-14 14:38:49] daan at react dot com

Description:

When a static class variable is assigned a nested destructable object,
it behaves differently when assigned before or after the instantiation
an object of the class to which the static property belongs.



When the variable is assigned after object instantiation, the process
segfaults.



(tested: PHP 5.3.1 behaves correctly)



Test script:
---
test = new DestructableObject;   

}

}



class Test

{

public static $mystatic;

}



// Uncomment this to avoid segfault

//Test::$mystatic = new DestructorCreator();



$x = new Test();



if (!isset(Test::$mystatic))

Test::$mystatic = new DestructorCreator();



echo 'bla';

Expected result:

bla

Actual result:
--
Segfault






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

[PHP-BUG] Bug #51822 [NEW]: Segfault with strange __destruct() for static class variables

2010-05-14 Thread daan at react dot com 
From: 
Operating system: Debian Etch
PHP version:  5.2.13
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Segfault with strange __destruct() for static class variables

Description:

When a static class variable is assigned a nested destructable object, it
behaves differently when assigned before or after the instantiation an
object of the class to which the static property belongs.



When the variable is assigned after object instantiation, the process
segfaults.



(tested: PHP 5.3.1 behaves correctly)



Test script:
---
test = new DestructableObject;   

}

}



class Test

{

public static $mystatic;

}



// Uncomment this to avoid segfault

//Test::$mystatic = new DestructorCreator();



$x = new Test();



if (!isset(Test::$mystatic))

Test::$mystatic = new DestructorCreator();



echo 'bla';

Expected result:

bla

Actual result:
--
Segfault

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

[PHP-BUG] Bug #51821 [NEW]: configure fails to pick up a custom prefix for libevent

2010-05-14 Thread admin at saltwaterc dot net 
From: 
Operating system: Linux
PHP version:  5.3.2
Package:  FPM related
Bug Type: Bug
Bug description:configure fails to pick up a custom prefix for libevent

Description:

Using a custom prefix for the libevent installation
(/usr/local/libevent-1.4.13) doesn't get picked up by the configure script,
even though I properly used the --with-libevent-dir option. Unless the
prefix for the libevent installation is a path that ldconfig knows about,
the configure fails.



I could "fix" it with:



export LD_LIBRARY_PATH=/usr/local/libevent-$libevent_version/lib



within my build script which gives me the idea that the configure fails to
properly set its environment. Still an arcane method though.

Test script:
---
./configure [...] --enable-fpm --with-fpm-user=php-fpm
--with-fpm-group=php-fpm --with-libevent-dir=/usr/local/libevent-1.4.13

Expected result:

To run configure without errors.

Actual result:
--
./configure says:



checking for FPM build... yes

checking for libevent >= 1.4.11 install prefix...
/usr/local/libevent-1.4.13

no

configure: error: build test failed. Please check the config.log for
details.



config.log says:



configure:9409: checking for libevent >= 1.4.11 install prefix

configure:9524: gcc -o conftest -g -O2 -fvisibility=hidden 
-I/usr/local/libevent-1.4.13/include  -L/usr/local/libevent-1.4.13/lib
conftest.c  -levent 1>&5

configure:9724: gcc -o conftest -g -O2 -fvisibility=hidden   conftest.c
-L/usr/local/libevent-1.4.13/lib -levent  1>&5

configure: failed program was:

#line 9713 "configure"

#include "confdefs.h"





char event_init();

int main() {

  event_init();

  return 0;

}

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

Bug #51592 [Opn]: file_get_contents('php://input') - empty string if called more than once

2010-05-14 Thread theshop at inbox dot ru 
Edit report at http://bugs.php.net/bug.php?id=51592&edit=1

 ID:   51592
 User updated by:  theshop at inbox dot ru
 Reported by:  theshop at inbox dot ru
 Summary:  file_get_contents('php://input') - empty string if
   called more than once
 Status:   Open
 Type: Bug
 Package:  Streams related
-Operating System: Windows 7 Pro x64
+Operating System: Windows 7 Pro x64, CentOS
 PHP Version:  5.3.2

 New Comment:

Nope, I was wrong, does not work under CentOS with methods different
from GET or POST. So it is not OS specific after all.


Previous Comments:

[2010-05-14 13:55:50] theshop at inbox dot ru

Some more test results:



Windows 7 Pro x64, Apache 2.2.15, PHP 5.3.2 - not working.

CentOS (don't know exact version number), Apache 2.2.3, PHP 5.3.2 -
works correctly.



So this is probably Windows-only bug.


[2010-04-18 23:04:16] theshop at inbox dot ru

Description:

Second and consecutive calls of file_get_contents('php://input') return
empty string if client issued an HTTP command other than 'GET' or 'POST'
(see example code). If 'GET' or 'POST' HTTP command was issued
file_get_contents('php://input') works correctly.



Not sure if this is cURL related bug, maybe some other PHP package is
responsible.



I am using Apache 2.2 and IE8.

Test script:
---
#bug_curl.php

$hcurl = curl_init();

curl_setopt($hcurl, CURLOPT_URL, 'http://test/bug.php');

curl_setopt($hcurl, CURLOPT_RETURNTRANSFER, true);

curl_setopt($hcurl, CURLOPT_HTTPHEADER, array('Content-Type:
text/plain'));

curl_setopt($hcurl, CURLOPT_POSTFIELDS, 'some request text');

curl_setopt($hcurl, CURLOPT_CUSTOMREQUEST, 'DELETE');

//curl_setopt($hcurl, CURLOPT_HTTPGET, true); - this works ok

//curl_setopt($hcurl, CURLOPT_POST, true); - this works ok

$out = curl_exec($hcurl);

curl_close($hcurl);

echo ''.htmlspecialchars($out).'';



# bug.php

var_dump(file_get_contents('php://input'));

var_dump(file_get_contents('php://input')); // returns empty string if
HTTP command is not 'GET' or POST'

var_dump(apache_request_headers());



Expected result:

string(17) "some request text"

string(17) "some request text"

array(4) {

  ["Host"]=>

  string(4) "test"

  ["Accept"]=>

  string(3) "*/*"

  ["Content-Type"]=>

  string(10) "text/plain"

  ["Content-Length"]=>

  string(2) "17"

}





Actual result:
--
string(17) "some request text"

string(0) ""

array(4) {

  ["Host"]=>

  string(4) "test"

  ["Accept"]=>

  string(3) "*/*"

  ["Content-Type"]=>

  string(10) "text/plain"

  ["Content-Length"]=>

  string(2) "17"

}










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

Bug #51592 [Opn]: file_get_contents('php://input') - empty string if called more than once

2010-05-14 Thread theshop at inbox dot ru 
Edit report at http://bugs.php.net/bug.php?id=51592&edit=1

 ID:   51592
 User updated by:  theshop at inbox dot ru
 Reported by:  theshop at inbox dot ru
 Summary:  file_get_contents('php://input') - empty string if
   called more than once
 Status:   Open
 Type: Bug
-Package:  cURL related
+Package:  Streams related
 Operating System: Windows 7 Pro x64
-PHP Version:  5.2.13
+PHP Version:  5.3.2

 New Comment:

Some more test results:



Windows 7 Pro x64, Apache 2.2.15, PHP 5.3.2 - not working.

CentOS (don't know exact version number), Apache 2.2.3, PHP 5.3.2 -
works correctly.



So this is probably Windows-only bug.


Previous Comments:

[2010-04-18 23:04:16] theshop at inbox dot ru

Description:

Second and consecutive calls of file_get_contents('php://input') return
empty string if client issued an HTTP command other than 'GET' or 'POST'
(see example code). If 'GET' or 'POST' HTTP command was issued
file_get_contents('php://input') works correctly.



Not sure if this is cURL related bug, maybe some other PHP package is
responsible.



I am using Apache 2.2 and IE8.

Test script:
---
#bug_curl.php

$hcurl = curl_init();

curl_setopt($hcurl, CURLOPT_URL, 'http://test/bug.php');

curl_setopt($hcurl, CURLOPT_RETURNTRANSFER, true);

curl_setopt($hcurl, CURLOPT_HTTPHEADER, array('Content-Type:
text/plain'));

curl_setopt($hcurl, CURLOPT_POSTFIELDS, 'some request text');

curl_setopt($hcurl, CURLOPT_CUSTOMREQUEST, 'DELETE');

//curl_setopt($hcurl, CURLOPT_HTTPGET, true); - this works ok

//curl_setopt($hcurl, CURLOPT_POST, true); - this works ok

$out = curl_exec($hcurl);

curl_close($hcurl);

echo ''.htmlspecialchars($out).'';



# bug.php

var_dump(file_get_contents('php://input'));

var_dump(file_get_contents('php://input')); // returns empty string if
HTTP command is not 'GET' or POST'

var_dump(apache_request_headers());



Expected result:

string(17) "some request text"

string(17) "some request text"

array(4) {

  ["Host"]=>

  string(4) "test"

  ["Accept"]=>

  string(3) "*/*"

  ["Content-Type"]=>

  string(10) "text/plain"

  ["Content-Length"]=>

  string(2) "17"

}





Actual result:
--
string(17) "some request text"

string(0) ""

array(4) {

  ["Host"]=>

  string(4) "test"

  ["Accept"]=>

  string(3) "*/*"

  ["Content-Type"]=>

  string(10) "text/plain"

  ["Content-Length"]=>

  string(2) "17"

}










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

Bug #51810 [Fbk->Csd]: empty line added if $header is given to mail()

2010-05-14 Thread johannes 
Edit report at http://bugs.php.net/bug.php?id=51810&edit=1

 ID:   51810
 Updated by:   johan...@php.net
 Reported by:  juergen dot vollmer at informatik-vollmer dot de
 Summary:  empty line added if $header is given to mail()
-Status:   Feedback
+Status:   Closed
 Type: Bug
 Package:  Mail related
 Operating System: Linux / SuSE 11.2 and 10.2
 PHP Version:  5.3.2
-Assigned To:  
+Assigned To:  johannes



Previous Comments:

[2010-05-14 12:46:25] juergen dot vollmer at informatik-vollmer dot de

That version of php fixes the problem

Thanks

Jürgen


[2010-05-13 18:27:54] ka...@php.net

Please try using this snapshot:

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

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




[2010-05-13 16:58:13] juergen dot vollmer at informatik-vollmer dot de

Description:

If mail() is called with the $header argument, an empty line is inserted
before the $header ĺine. Therefore the content of $header is not seen
as valid mail header.





Test script:
---


Actual result:
--
If $header is given (see example above) the (shortened) mail text looks
like:

---  from here

Return-Path: <>

Received: 

To: m...@example.com

Subject: my sub

X-Mailer: PHP/5.3.1

Message-Id: <...>

From: ...

Message-Id: <...>

Date: ...

X-Length: 2014

X-UID: 252148



Message-Id: <...>

Date: 

From: 





my body -- with header1

-- to here



Now After X-UID: there is an empty line, which should n ot be there (in
my opinion).








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

Bug #51820 [Fbk->Opn]: IPTC Data truncated for 2#040 Instructions

2010-05-14 Thread pajoye 
Edit report at http://bugs.php.net/bug.php?id=51820&edit=1

 ID:   51820
 Updated by:   paj...@php.net
 Reported by:  ianphp at ian-nicholson dot co dot uk
 Summary:  IPTC Data truncated for 2#040 Instructions
-Status:   Feedback
+Status:   Open
 Type: Bug
 Package:  PHP options/info functions
 Operating System: Windows/Apache
 PHP Version:  5.2.13

 New Comment:

The image: http://pecl.php.net/~pierre/_DSC3640.jpg


Previous Comments:

[2010-05-14 13:03:40] paj...@php.net

There is an upload system in the form, or you can also send it to me per
email.


[2010-05-14 12:44:30] ianphp at ian-nicholson dot co dot uk

Can't seem to find anywhere on this form to attach image?


[2010-05-14 12:17:27] paj...@php.net

Please provide a sample image with the required fields to reproduce this
problem.


[2010-05-14 12:07:48] ianphp at ian-nicholson dot co dot uk

Description:

Hi, I'm no techie, but the IPTC Data field #040 (Instructions seems to
be truncated, is this me doing something wrong or is there a workaround
for this.

I have a flash program which sells images by using the IPTC Data field
Special Instructions which is set in Adobe Lightroom, the flash reads
the data and outputs it as sizes and costs, I have written a PHP
function that should do the same thing, but the field gets truncated.

Is there a limit to the number of characters read in the IPTC
Instructions field.



Many Thanks



Ian Nicholson







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

Bug #51820 [Opn->Fbk]: IPTC Data truncated for 2#040 Instructions

2010-05-14 Thread pajoye 
Edit report at http://bugs.php.net/bug.php?id=51820&edit=1

 ID:   51820
 Updated by:   paj...@php.net
 Reported by:  ianphp at ian-nicholson dot co dot uk
 Summary:  IPTC Data truncated for 2#040 Instructions
-Status:   Open
+Status:   Feedback
 Type: Bug
 Package:  PHP options/info functions
 Operating System: Windows/Apache
 PHP Version:  5.2.13

 New Comment:

There is an upload system in the form, or you can also send it to me per
email.


Previous Comments:

[2010-05-14 12:44:30] ianphp at ian-nicholson dot co dot uk

Can't seem to find anywhere on this form to attach image?


[2010-05-14 12:17:27] paj...@php.net

Please provide a sample image with the required fields to reproduce this
problem.


[2010-05-14 12:07:48] ianphp at ian-nicholson dot co dot uk

Description:

Hi, I'm no techie, but the IPTC Data field #040 (Instructions seems to
be truncated, is this me doing something wrong or is there a workaround
for this.

I have a flash program which sells images by using the IPTC Data field
Special Instructions which is set in Adobe Lightroom, the flash reads
the data and outputs it as sizes and costs, I have written a PHP
function that should do the same thing, but the field gets truncated.

Is there a limit to the number of characters read in the IPTC
Instructions field.



Many Thanks



Ian Nicholson







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

Bug #51810 [Com]: empty line added if $header is given to mail()

2010-05-14 Thread juergen dot vollmer at informatik-vollmer dot de 
Edit report at http://bugs.php.net/bug.php?id=51810&edit=1

 ID:   51810
 Comment by:   juergen dot vollmer at informatik-vollmer dot de
 Reported by:  juergen dot vollmer at informatik-vollmer dot de
 Summary:  empty line added if $header is given to mail()
 Status:   Feedback
 Type: Bug
 Package:  Mail related
 Operating System: Linux / SuSE 11.2 and 10.2
 PHP Version:  5.3.2

 New Comment:

That version of php fixes the problem

Thanks

Jürgen


Previous Comments:

[2010-05-13 18:27:54] ka...@php.net

Please try using this snapshot:

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

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




[2010-05-13 16:58:13] juergen dot vollmer at informatik-vollmer dot de

Description:

If mail() is called with the $header argument, an empty line is inserted
before the $header ĺine. Therefore the content of $header is not seen
as valid mail header.





Test script:
---


Actual result:
--
If $header is given (see example above) the (shortened) mail text looks
like:

---  from here

Return-Path: <>

Received: 

To: m...@example.com

Subject: my sub

X-Mailer: PHP/5.3.1

Message-Id: <...>

From: ...

Message-Id: <...>

Date: ...

X-Length: 2014

X-UID: 252148



Message-Id: <...>

Date: 

From: 





my body -- with header1

-- to here



Now After X-UID: there is an empty line, which should n ot be there (in
my opinion).








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

Bug #51820 [Fbk->Opn]: IPTC Data truncated for 2#040 Instructions

2010-05-14 Thread ianphp at ian-nicholson dot co dot uk 
Edit report at http://bugs.php.net/bug.php?id=51820&edit=1

 ID:   51820
 User updated by:  ianphp at ian-nicholson dot co dot uk
 Reported by:  ianphp at ian-nicholson dot co dot uk
 Summary:  IPTC Data truncated for 2#040 Instructions
-Status:   Feedback
+Status:   Open
 Type: Bug
 Package:  PHP options/info functions
 Operating System: Windows/Apache
 PHP Version:  5.2.13

 New Comment:

Can't seem to find anywhere on this form to attach image?


Previous Comments:

[2010-05-14 12:17:27] paj...@php.net

Please provide a sample image with the required fields to reproduce this
problem.


[2010-05-14 12:07:48] ianphp at ian-nicholson dot co dot uk

Description:

Hi, I'm no techie, but the IPTC Data field #040 (Instructions seems to
be truncated, is this me doing something wrong or is there a workaround
for this.

I have a flash program which sells images by using the IPTC Data field
Special Instructions which is set in Adobe Lightroom, the flash reads
the data and outputs it as sizes and costs, I have written a PHP
function that should do the same thing, but the field gets truncated.

Is there a limit to the number of characters read in the IPTC
Instructions field.



Many Thanks



Ian Nicholson







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

Bug #51820 [Opn->Fbk]: IPTC Data truncated for 2#040 Instructions

2010-05-14 Thread pajoye 
Edit report at http://bugs.php.net/bug.php?id=51820&edit=1

 ID:   51820
 Updated by:   paj...@php.net
 Reported by:  ianphp at ian-nicholson dot co dot uk
 Summary:  IPTC Data truncated for 2#040 Instructions
-Status:   Open
+Status:   Feedback
 Type: Bug
 Package:  PHP options/info functions
 Operating System: Windows/Apache
 PHP Version:  5.2.13

 New Comment:

Please provide a sample image with the required fields to reproduce this
problem.


Previous Comments:

[2010-05-14 12:07:48] ianphp at ian-nicholson dot co dot uk

Description:

Hi, I'm no techie, but the IPTC Data field #040 (Instructions seems to
be truncated, is this me doing something wrong or is there a workaround
for this.

I have a flash program which sells images by using the IPTC Data field
Special Instructions which is set in Adobe Lightroom, the flash reads
the data and outputs it as sizes and costs, I have written a PHP
function that should do the same thing, but the field gets truncated.

Is there a limit to the number of characters read in the IPTC
Instructions field.



Many Thanks



Ian Nicholson







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

Bug #46408 [Com]: Locale number format settings can cause pg_query_params to break with numerics

2010-05-14 Thread lewis at peppermind dot de 
Edit report at http://bugs.php.net/bug.php?id=46408&edit=1

 ID:   46408
 Comment by:   lewis at peppermind dot de
 Reported by:  alec at smecher dot bc dot ca
 Summary:  Locale number format settings can cause
   pg_query_params to break with numerics
 Status:   Open
 Type: Bug
 Package:  PostgreSQL related
 Operating System: *
 PHP Version:  5.*, 6

 New Comment:

This issue also appears with pg_execute(), when passing float values to
the bind array, with a locale that uses comma as decimal separator (such
as de_DE and most other european locales).


Previous Comments:

[2009-07-26 18:59:12] jerico dot dev at gmail dot com

@jani: When I pass in a double, I expect pg_query_params() to prepare it
in a way that can be understood by the database independent of my locale
settings. AFAIK the implementation of pg_query_params() is also
inconsistent with that of the mysql driver which correctly accepts
double typed parameters independent of locale.



I guess you were not entirely serious when you proposed that one should
switch the locale before using pg_query_params(), were you?


[2008-11-21 13:09:19] j...@php.net

I guess it's an issue always if extension does 'convert_to_string()'.

Easily avoided in code: Only do setlocale() prior to outputting stuff.

And then restore the locale right after output. :)


[2008-11-18 23:16:44] alec at smecher dot bc dot ca

Thanks, lsmith and RhodiumToad. FYI, this bug also exists in PDO (I can
post reproduce code if it's helpful).


[2008-11-18 22:59:44] lsm...@php.net

 lsmith: in a parameterized query it's always wrong to use


locale-specific delimiters



RhodiumToad is also known as Andrew Gierth and is a highly respected 

expert on #postgresql on freenode.



As such I will reopen the bug ..


[2008-10-31 18:28:57] alec at smecher dot bc dot ca

FYI, there's a discussion of the same bug, which also appeared (in a
separate implementation) in the implementation of the Pear::DB package:





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

http://bugs.php.net/bug.php?id=46408


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

[PHP-BUG] Bug #51820 [NEW]: IPTC Data truncated for 2#040 Instructions

2010-05-14 Thread ianphp at ian-nicholson dot co dot uk 
From: 
Operating system: Windows/Apache
PHP version:  5.2.13
Package:  PHP options/info functions
Bug Type: Bug
Bug description:IPTC Data truncated for 2#040 Instructions

Description:

Hi, I'm no techie, but the IPTC Data field #040 (Instructions seems to be
truncated, is this me doing something wrong or is there a workaround for
this.

I have a flash program which sells images by using the IPTC Data field
Special Instructions which is set in Adobe Lightroom, the flash reads the
data and outputs it as sizes and costs, I have written a PHP function that
should do the same thing, but the field gets truncated.

Is there a limit to the number of characters read in the IPTC Instructions
field.



Many Thanks



Ian Nicholson


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

[PHP-BUG] Bug #51819 [NEW]: Case discrepancy in timezone names cause Uncaught exception and fatal error

2010-05-14 Thread shumisha at gmail dot com 
From: 
Operating system: linux/windows
PHP version:  5.2.13
Package:  Date/time related
Bug Type: Bug
Bug description:Case discrepancy in timezone names cause Uncaught exception and 
fatal error

Description:

Hi



There seem to be a discrepency for timezones names as reported by
timezone_abbreviations_list() and the DateTime object parser. We have found
a (small) numbre of timezones for which this happens:



Been reported and reproduced with PHP 5.1.41 adn PHP 5.2.13





Test script:
---
1 - Get identifiers list:



$all = timezone_abbreviations_list();



The resulting array contains, for instance:



[54] => Array

  (

[dst] => 

[offset] => 36000

[timezone_id] => Australia/NSW

   )

2 - Use this timezone_id to create a DateTimeObject



$dateString = "2010-05-15 00:00:00 Australia/NSW";

$date = new DateTime( $dateString);





Expected result:

A DateTime object created



The above code runs without problem if timezone identifier (Australia/NSW)
is replaced by Australia/Nsw.



I have found the following timezones to have the same issue:

Australia/ACT

NZ-CHAT

America/Know_IN

Australia/LHI

Chile/EasterIsland

Europe/Isle_of_Man



In others, all timezones names that do not follow camelcase strictly. There
are probably others.

Actual result:
--
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct() [datetime.--construct]: Failed to parse time
string (2010-05-15 00:00:00 Australia/NSW) at position 20 (A): The timezone
could not be found in the database' in //test.php on line 4

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

Bug #48855 [Com]: Decimals are rounded with PDO bindValue in mysql double/float fields

2010-05-14 Thread r dot wilczek at web-appz dot de 
Edit report at http://bugs.php.net/bug.php?id=48855&edit=1

 ID:   48855
 Comment by:   r dot wilczek at web-appz dot de
 Reported by:  lorenzo-99 at libero dot it
 Summary:  Decimals are rounded with PDO bindValue in mysql
   double/float fields
 Status:   Closed
 Type: Bug
 Package:  PDO related
 Operating System: Windows XP
 PHP Version:  5.2.10

 New Comment:

This bug persists in current PHP 5.3.2 with MySQL 5.1.36 and MySQL
client API version 5.0.67 (64 bit Linux)


Previous Comments:

[2009-09-25 15:06:18] lorenzo-99 at libero dot it

Ok in this last version (5.3.2dev) the problem is really fixed.

So I consider the problem closed

thank you very much


[2009-09-25 14:13:14] u...@php.net

Please try using this snapshot:

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

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




[2009-09-25 13:58:37] lorenzo-99 at libero dot it

Sorry but The Problem in 5.3 is NOT fixed.



I tried first to install 5.2.11 and i verified that the problem is
fixed, then I update to 5.3 but the problem here still exists



I download the windows version from http://windows.php.net/download/



php-5.3.0-Win32-VC6-x86.zip thread-safe



The strange thing I see is that 5.3 is dated 2009-jun-30 while 5.2.11 is
more recent 2009-sep-17


[2009-09-23 10:32:05] u...@php.net

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

Hmm, seems to have been fixed before in SVN and in PHP 5.2.11:



if (PDO_PARAM_TYPE(param->param_type) == PDO_PARAM_STR &&
param->max_value_len <= 0 && ! ZVAL_IS_NULL(param->parameter)) {

if (Z_TYPE_P(param->parameter) == IS_DOUBLE) {

char *p;

int len = spprintf(&p, 0, "%.*H", (int)
EG(precision), Z_DVAL_P(param->parameter));

ZVAL_STRINGL(param->parameter, p, len, 0);

} else {

convert_to_string(param->parameter);

}




[2009-09-22 16:51:45] u...@php.net

That is a PDO bug not a PDO_MYSQL bug. It has been fixed in PHP 5.3+.



ext/pdo/pdo_stmt.c:330 needs something like this:



int len = spprintf(&p, 0, "%.*H", (int) EG(precision),
Z_DVAL_P(param->parameter));



I don't know what the policy is with PHP 5.2. Would be nice if someone
else could apply the patch. I am quite sure to have seen this bug before
and I am also sure the 5.3 tests cover it. Though, I can't say which
test from top of my head. 




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

http://bugs.php.net/bug.php?id=48855


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

Req #45002 [Com]: __get() and __set() don't work for static variable calls

2010-05-14 Thread vincentbab at gmail dot com 
Edit report at http://bugs.php.net/bug.php?id=45002&edit=1

 ID:   45002
 Comment by:   vincentbab at gmail dot com
 Reported by:  jb2386 at hotmail dot com
 Summary:  __get() and __set() don't work for static variable
   calls
 Status:   Open
 Type: Feature/Change Request
 Package:  Feature/Change Request
 Operating System: Any
 PHP Version:  5.2.6

 New Comment:

I would really apreciate this feature too


Previous Comments:

[2009-09-24 10:23:05] peter dot rother at gmail dot com

'Twould be seriously nice to have this feature…please let us know if 

anything can be done soon.


[2009-08-01 15:25:58] atrauzzi at gmail dot com

I'd have to say I'm waiting on this feature as well.



Is there a snapshot I could be using to test it out?


[2009-07-30 21:21:58] some at email dot com

When to expect resolving this bug


[2009-05-13 15:38:49] rcavallari at hotmail dot com

Any news about __{get,set}Static in the mainline?


[2009-01-08 08:51:30] jeremie dot bordier at gmail dot com

Could this patch be reviewed and committed ? It's been a long time now
for a such little feature...




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

http://bugs.php.net/bug.php?id=45002


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