Bug #60277 [Opn]: User Defined Types handling
Edit report at https://bugs.php.net/bug.php?id=60277edit=1
ID: 60277
User updated by:ash at inode dot me
Reported by:ash at inode dot me
Summary:User Defined Types handling
Status: Open
Type: Bug
Package:PDO_IBM
Operating System: Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This was a false alarm. The queries don't work properly but it likely has
nothing
to do with the driver. Look here for the solution:
http://www.dbforums.com/db2/1671711-udt.html#post6525422
Previous Comments:
[2011-11-12 08:32:03] ash at inode dot me
Description:
PHP - 5.3.2 latest Ubuntu package, PDO_IBM-1.3.2
Using a PDO object to insert even the simplest UDT produced error. This occurs
in cases when using PrepareStatements or calling query() directly. Using the
following tutorial as an example:
http://www.ibm.com/developerworks/data/library/techarticle/dm-0506melnyk/
Executing the following produces - SQLSTATE[07001]: Unknown error: -9
[IBM][CLI Driver] CLI0100E Wrong number of parameters. SQLSTATE=07001
(SQLExecute[-9] at /usr/share/php/PDO_IBM-1.3.2/ibm_statement.c:986)
$a = 'Some'; $b = 'Person'; $c = '21 Street'; $d = 'Some City'; $e = 'MyState';
$f = '10101';
$stmt = $db-prepare(insert into clients (client_lname, client_fname) values
(:1, :2, address_t() ..street(:3) ..city(:4) ..province(:5)
..postal_code(:6)));
$stmt-bindParam(':1',$e);
$stmt-bindParam(':2',$f);
$stmt-bindParam(':3',$a);
$stmt-bindParam(':4',$b);
$stmt-bindParam(':5',$c);
$stmt-bindParam(':6',$d);
The following produces - SQLSTATE[42601]: Syntax error: -104 [IBM][CLI Driver]
[DB2/LINUX] SQL0104N
$db-query(insert into clients (client_lname, client_fname, address) values
('Some', 'Person', address_t() ..street($c) ..city($d) ..province($e)
..postal_code($f)));
This works - but if you want to insert LOBs you really have no options:
$db-query(insert into clients (client_lname, client_fname, address) values
('Some', 'Person', address_t() ..street('. $a .') ..city(' .$b .')
..province('. $c . ') ..postal_code('. $d .')));
Test script:
---
Create $db PDO connection and rung
try {
$a = 'Some'; $b = 'Person'; $c = '21 Street'; $d = 'Some City'; $e = 'MyState';
$f = '10101';
/*
$stmt = $db-prepare(insert into clients (client_lname, client_fname) values
(:1, :2, address_t() ..street(:3) ..city(:4) ..province(:5)
..postal_code(:6)));
$stmt-bindParam(':1',$a);
$stmt-bindParam(':2',$b);
$stmt-bindParam(':3',$c);
$stmt-bindParam(':4',$d);
$stmt-bindParam(':5',$e);
$stmt-bindParam(':6',$f);
$stmt-execute();*/
$db-query(insert into clients (client_lname, client_fname, address) values
('Some', 'Person', address_t() ..street($c) ..city($d) ..province($e)
..postal_code($f)));
#$db-query(insert into clients (client_lname, client_fname, address) values
('Some', 'Person', address_t() ..street('. $a .') ..city(' .$b .')
..province('. $c . ') ..postal_code('. $d .')));
} catch (PDOException $e) {
print $e-getMessage() . \n;
}
Expected result:
Named or unnamed placeholders should be bound properly and inserted.
Actual result:
--
See errors above
--
Edit this bug report at https://bugs.php.net/bug.php?id=60277edit=1
Bug #60326 [Com]: ob_gzhander() removed
Edit report at https://bugs.php.net/bug.php?id=60326edit=1 ID: 60326 Comment by: nicolas dot grekas+php at gmail dot com Reported by:s...@php.net Summary:ob_gzhander() removed Status: Assigned Type: Bug Package:Output Control Operating System: * PHP Version:5.4.0RC1 Assigned To:mike Block user comment: N Private report: N New Comment: The attached patch is by mike. Previous Comments: [2011-11-18 07:17:48] s...@php.net Description: ob_gzhandler() function was removed by new output buffering code, but some scripts still use it. It would be nice to restore it back if possible. -- Edit this bug report at https://bugs.php.net/bug.php?id=60326edit=1
Req #60319 [Com]: PHP shorthand syntax
Edit report at https://bugs.php.net/bug.php?id=60319edit=1 ID: 60319 Comment by: anon at anon dot anon Reported by:deepakbalanimail at gmail dot com Summary:PHP shorthand syntax Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.8 Block user comment: N Private report: N New Comment: It's a very poor example then isn't it. Previous Comments: [2011-11-19 05:38:24] deepakbalanimail at gmail dot com @anon This is just an example, not the actual problem. [2011-11-18 15:39:57] anon at anon dot anon Yuck. Why would you code like that? Keep it in a single tag. ?php echo true ? 'True' : 'False'; ? [2011-11-17 13:27:16] deepakbalanimail at gmail dot com Description: This is feature request:- PHP needs a more efficient shorthand syntax. PHP already has the shorthand syntax for ?php echo $expr ? = ?= $expr ?. But this thing will become nightmare when we want to use some flow control. ?php if(true): ? ?= 'True' ? ?php else: ? ?= 'False' ? ?php endif; ? In this example we have to mix both type of syntax. So we need to make ?= ? capable to process decision instructions. -- Edit this bug report at https://bugs.php.net/bug.php?id=60319edit=1
[PHP-BUG] Bug #60337 [NEW]: bcscale related problem on 64bits platforms
From: shm
Operating system:
PHP version: trunk-SVN-2011-11-19 (SVN)
Package: BC math related
Bug Type: Bug
Bug description:bcscale related problem on 64bits platforms
Description:
bcscale uses long typed variable to store scale passed further to bclib
calls. Unfortunately bclib uses int type for scale parameter, thus large
long numbers (which uses 8 bytes on 64 bits platforms) could be casted to
negative number and cause memory corruption as a result of pointer
arithmetic with scale param.
Test script:
---
?php
$var48 = bcscale(634314234334311);
$var67 = bcsqrt(false);
$var414 = bcadd(false,null,10);
die('ALIVE');
?
Expected result:
ALIVE
Actual result:
--
$ php
?php
$var48 = bcscale(634314234334311);
$var67 = bcsqrt(false);
$var414 = bcadd(false,null,10);
die('ALIVE');
?^D
Segmentation fault: 11 (core dumped)
--
Edit bug report at https://bugs.php.net/bug.php?id=60337edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60337r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60337r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60337r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60337r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60337r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60337r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60337r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60337r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60337r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60337r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60337r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60337r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60337r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60337r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60337r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60337r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60337r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60337r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60337r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60337r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60337r=mysqlcfg
Bug #60337 [Asn-Csd]: bcscale related problem on 64bits platforms
Edit report at https://bugs.php.net/bug.php?id=60337edit=1
ID: 60337
Updated by: s...@php.net
Reported by:s...@php.net
Summary:bcscale related problem on 64bits platforms
-Status: Assigned
+Status: Closed
Type: Bug
Package:BC math related
PHP Version:trunk-SVN-2011-11-19 (SVN)
Assigned To:shm
Block user comment: N
Private report: N
New Comment:
fixed in svn
Previous Comments:
[2011-11-19 12:46:32] s...@php.net
Automatic comment from SVN on behalf of shm
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=319546
Log: - Fixed bug #60337 bcscale related crashed on 64bits platforms
[2011-11-19 12:35:54] s...@php.net
Description:
bcscale uses long typed variable to store scale passed further to bclib calls.
Unfortunately bclib uses int type for scale parameter, thus large long numbers
(which uses 8 bytes on 64 bits platforms) could be casted to negative number
and cause memory corruption as a result of pointer arithmetic with scale param.
Test script:
---
?php
$var48 = bcscale(634314234334311);
$var67 = bcsqrt(false);
$var414 = bcadd(false,null,10);
die('ALIVE');
?
Expected result:
ALIVE
Actual result:
--
$ php
?php
$var48 = bcscale(634314234334311);
$var67 = bcsqrt(false);
$var414 = bcadd(false,null,10);
die('ALIVE');
?^D
Segmentation fault: 11 (core dumped)
--
Edit this bug report at https://bugs.php.net/bug.php?id=60337edit=1
[PHP-BUG] Bug #60338 [NEW]: SplFixedArray::key returns index for invalid keys
From: gooh Operating system: PHP version: 5.4SVN-2011-11-19 (SVN) Package: SPL related Bug Type: Bug Bug description:SplFixedArray::key returns index for invalid keys Description: SplFixedArray::key() will return a value even when the key does not exist in the SplFixedArray. This does not conform to the behavior we have in regular arrays, ArrayObject and ArrayIterator. SplFixedArray::key() should return NULL when the current key does not exist to conform. Test script: --- http://codepad.viper-7.com/4hWmUn Expected result: NULL NULL NULL NULL Actual result: -- int(3) NULL NULL NULL -- Edit bug report at https://bugs.php.net/bug.php?id=60338edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60338r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60338r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60338r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60338r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60338r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60338r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60338r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60338r=needscript Try newer version: https://bugs.php.net/fix.php?id=60338r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60338r=support Expected behavior: https://bugs.php.net/fix.php?id=60338r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60338r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60338r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60338r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60338r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60338r=dst IIS Stability: https://bugs.php.net/fix.php?id=60338r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60338r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60338r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60338r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60338r=mysqlcfg
Bug #43200 [Opn-Csd]: Interface implementation / inheritence not possible in abstract classes
Edit report at https://bugs.php.net/bug.php?id=43200edit=1
ID: 43200
Updated by: fel...@php.net
Reported by:smith at pooteeweet dot org
Summary:Interface implementation / inheritence not possible
in abstract classes
-Status: Open
+Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3CVS-2007-11-05 (CVS)
-Assigned To:
+Assigned To:felipe
Block user comment: N
Private report: N
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-11-18 23:26:15] lsm...@php.net
I should also clarify that the issue also exist when simply dealing with
interfaces only aka when an interface extends another interface. I am aware
that
we do not support polymorphism, but again when dealing with legacy interfaces
there will be overlaps with signatures that are identical.
[2011-10-02 21:16:11] ahar...@php.net
Revert the various field changes that crept in. I'll let one of the engine
developers figure out if this should be left open or re-bogused.
[2011-10-01 07:55:33] lsm...@php.net
This is not bogus and it should be fixed. In many cases I in the end managed to
work around this, but its not always possible, like when dealing with legacy
interfaces that one cannot change etc, but that are being superseded by newer
ones (f.e. https://github.com/symfony/symfony/pull/2244).
[2010-12-16 00:38:40] kucho86 at gmail dot com
Are you planning to cover this bug??
It's pretty simple to fix and since interfaces define behaviours and classes
implements them, this should be possible.
It goes against Object Oriented Programming concepts.
[2007-11-05 16:34:21] cel...@php.net
?php
interface A {
function foo();
}
abstract class B implements A {
}
class C extends B {
public function foo() {
echo 'works';
}
}
$o = new C();
$o-foo();
?
If you don't want to implement a method from an interface, don't
redeclare it, and the code will work as intended.
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=43200
--
Edit this bug report at https://bugs.php.net/bug.php?id=43200edit=1
Bug #60338 [Com]: SplFixedArray::key returns index for invalid keys
Edit report at https://bugs.php.net/bug.php?id=60338edit=1 ID: 60338 Comment by: g...@php.net Reported by:g...@php.net Summary:SplFixedArray::key returns index for invalid keys Status: Open Type: Bug Package:SPL related PHP Version:5.4SVN-2011-11-19 (SVN) Block user comment: N Private report: N New Comment: Apparently the Expected Output is achieved when using key() instead of SplFixedArray::key(). See http://codepad.viper-7.com/I3REjD. Thanks to NikiC for pointing it out. Previous Comments: [2011-11-19 13:32:44] g...@php.net Description: SplFixedArray::key() will return a value even when the key does not exist in the SplFixedArray. This does not conform to the behavior we have in regular arrays, ArrayObject and ArrayIterator. SplFixedArray::key() should return NULL when the current key does not exist to conform. Test script: --- http://codepad.viper-7.com/4hWmUn Expected result: NULL NULL NULL NULL Actual result: -- int(3) NULL NULL NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=60338edit=1
[PHP-BUG] Bug #60339 [NEW]: valgrind reports LEAK --with-mm
From: Operating system: Linux PHP version: 5.4.0RC1 Package: Session related Bug Type: Bug Bug description:valgrind reports LEAK --with-mm Description: Valgrind reports LEAKs --with-mm (php-src HEAD is affected, too. I noticed this while I'm making strict session patch.) = LEAKED TEST SUMMARY - session rfc1867 [ext/session/tests/rfc1867.phpt] session rfc1867 [ext/session/tests/rfc1867_cleanup.phpt] session rfc1867 disabled [ext/session/tests/rfc1867_disabled.phpt] session rfc1867 disabled 2 [ext/session/tests/rfc1867_disabled_2.phpt] session rfc1867 [ext/session/tests/rfc1867_inter.phpt] session rfc1867 no name [ext/session/tests/rfc1867_no_name.phpt] session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_cookie.phpt] session rfc1867 sid get [ext/session/tests/rfc1867_sid_get.phpt] session rfc1867 sid get 2 [ext/session/tests/rfc1867_sid_get_2.phpt] session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_invalid.phpt] session rfc1867 sid only cookie [ext/session/tests/rfc1867_sid_only_cookie.phpt] session rfc1867 sid only cookie 2 [ext/session/tests/rfc1867_sid_only_cookie_2.phpt] session rfc1867 sid post [ext/session/tests/rfc1867_sid_post.phpt] Test session_module_name() function : variation [ext/session/tests/session_module_name_variation3.phpt] Test session_name() function : error functionality [ext/session/tests/session_name_basic.phpt] Test session_name() function : error functionality [ext/session/tests/session_name_error.phpt] Test session_name() function : variation [ext/session/tests/session_name_variation1.phpt] Test session_save_path() function : basic functionality [ext/session/tests/session_save_path_basic.phpt] Test session_save_path() function : error functionality [ext/session/tests/session_save_path_error.phpt] Test session_save_path() function : variation [ext/session/tests/session_save_path_variation1.phpt] Test session_save_path() function : variation [ext/session/tests/session_save_path_variation4.phpt] Test session_save_path() function : variation [ext/session/tests/session_save_path_variation5.phpt] Test session_set_save_handler() function : basic functionality [ext/session/tests/session_set_save_handler_basic.phpt] Test session_set_save_handler() function : using closures as callbacks [ext/session/tests/session_set_save_handler_closures.phpt] Test session_set_save_handler() function : error functionality [ext/session/tests/session_set_save_handler_error3.phpt] Test session_set_save_handler() function : variation [ext/session/tests/session_set_save_handler_variation4.phpt] = All LEAK reports are the same. *** ext/session/tests/rfc1867.mem ==29422== Invalid read of size 1 ==29422==at 0x57D8D3: zm_startup_ps_mm (mod_mm.c:281) ==29422==by 0x578A94: zm_startup_session (session.c:2178) ==29422==by 0x6784D4: zend_startup_module_ex (zend_API.c:1653) ==29422==by 0x681304: zend_hash_apply (zend_hash.c:716) ==29422==by 0x67BB15: zend_startup_modules (zend_API.c:1780) ==29422==by 0x61C27B: php_module_startup (main.c:2132) ==29422==by 0x718F02: php_cgi_startup (cgi_main.c:931) ==29422==by 0x7195D2: main (cgi_main.c:1873) ==29422== Address 0x4fa31af is 1 bytes before a block of size 1 alloc'd ==29422==at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==29422==by 0x6516AD: zend_strndup (zend_alloc.c:2617) ==29422==by 0x62361B: php_ini_parser_cb (php_ini.c:274) ==29422==by 0x64B84E: ini_parse (zend_ini_parser.c:1669) ==29422==by 0x64BAED: zend_parse_ini_string (zend_ini_parser.c:348) ==29422==by 0x622B44: php_init_config (php_ini.c:722) ==29422==by 0x61C1C9: php_module_startup (main.c:2078) ==29422==by 0x718F02: php_cgi_startup (cgi_main.c:931) ==29422==by 0x7195D2: main (cgi_main.c:1873) ==29422== Test script: --- N/A Expected result: No LEAKs Actual result: -- LEAKs are reported -- Edit bug report at https://bugs.php.net/bug.php?id=60339edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60339r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60339r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60339r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60339r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60339r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60339r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60339r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60339r=needscript Try newer version:
Bug #60339 [Com]: valgrind reports LEAK --with-mm
Edit report at https://bugs.php.net/bug.php?id=60339edit=1 ID: 60339 Comment by: yohgaki at ohgaki dot net Reported by:yohgaki at ohgaki dot net Summary:valgrind reports LEAK --with-mm Status: Open Type: Bug Package:Session related Operating System: Linux PHP Version:5.4.0RC1 Block user comment: N Private report: N New Comment: Adding extra byte to OnUpdateSaveDir() in session.c removes LEAKs @@ -607,7 +613,7 @@ } } - OnUpdateString(entry, new_value, new_value_length, mh_arg1, mh_arg2, mh_arg3, stage TSRMLS_CC); + OnUpdateString(entry, new_value, new_value_length+1, mh_arg1, mh_arg2, mh_arg3, stage TSRMLS_CC); return SUCCESS; } /* }}} */ but it does not seem to be a correct fix for this. Previous Comments: [2011-11-19 17:30:32] yohgaki at ohgaki dot net Description: Valgrind reports LEAKs --with-mm (php-src HEAD is affected, too. I noticed this while I'm making strict session patch.) = LEAKED TEST SUMMARY - session rfc1867 [ext/session/tests/rfc1867.phpt] session rfc1867 [ext/session/tests/rfc1867_cleanup.phpt] session rfc1867 disabled [ext/session/tests/rfc1867_disabled.phpt] session rfc1867 disabled 2 [ext/session/tests/rfc1867_disabled_2.phpt] session rfc1867 [ext/session/tests/rfc1867_inter.phpt] session rfc1867 no name [ext/session/tests/rfc1867_no_name.phpt] session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_cookie.phpt] session rfc1867 sid get [ext/session/tests/rfc1867_sid_get.phpt] session rfc1867 sid get 2 [ext/session/tests/rfc1867_sid_get_2.phpt] session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_invalid.phpt] session rfc1867 sid only cookie [ext/session/tests/rfc1867_sid_only_cookie.phpt] session rfc1867 sid only cookie 2 [ext/session/tests/rfc1867_sid_only_cookie_2.phpt] session rfc1867 sid post [ext/session/tests/rfc1867_sid_post.phpt] Test session_module_name() function : variation [ext/session/tests/session_module_name_variation3.phpt] Test session_name() function : error functionality [ext/session/tests/session_name_basic.phpt] Test session_name() function : error functionality [ext/session/tests/session_name_error.phpt] Test session_name() function : variation [ext/session/tests/session_name_variation1.phpt] Test session_save_path() function : basic functionality [ext/session/tests/session_save_path_basic.phpt] Test session_save_path() function : error functionality [ext/session/tests/session_save_path_error.phpt] Test session_save_path() function : variation [ext/session/tests/session_save_path_variation1.phpt] Test session_save_path() function : variation [ext/session/tests/session_save_path_variation4.phpt] Test session_save_path() function : variation [ext/session/tests/session_save_path_variation5.phpt] Test session_set_save_handler() function : basic functionality [ext/session/tests/session_set_save_handler_basic.phpt] Test session_set_save_handler() function : using closures as callbacks [ext/session/tests/session_set_save_handler_closures.phpt] Test session_set_save_handler() function : error functionality [ext/session/tests/session_set_save_handler_error3.phpt] Test session_set_save_handler() function : variation [ext/session/tests/session_set_save_handler_variation4.phpt] = All LEAK reports are the same. *** ext/session/tests/rfc1867.mem ==29422== Invalid read of size 1 ==29422==at 0x57D8D3: zm_startup_ps_mm (mod_mm.c:281) ==29422==by 0x578A94: zm_startup_session (session.c:2178) ==29422==by 0x6784D4: zend_startup_module_ex (zend_API.c:1653) ==29422==by 0x681304: zend_hash_apply (zend_hash.c:716) ==29422==by 0x67BB15: zend_startup_modules (zend_API.c:1780) ==29422==by 0x61C27B: php_module_startup (main.c:2132) ==29422==by 0x718F02: php_cgi_startup (cgi_main.c:931) ==29422==by 0x7195D2: main (cgi_main.c:1873) ==29422== Address 0x4fa31af is 1 bytes before a block of size 1 alloc'd ==29422==at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==29422==by 0x6516AD: zend_strndup (zend_alloc.c:2617) ==29422==by 0x62361B: php_ini_parser_cb (php_ini.c:274) ==29422==by 0x64B84E: ini_parse (zend_ini_parser.c:1669) ==29422==by 0x64BAED: zend_parse_ini_string (zend_ini_parser.c:348) ==29422==by 0x622B44: php_init_config (php_ini.c:722) ==29422==by 0x61C1C9: php_module_startup (main.c:2078) ==29422==by 0x718F02: php_cgi_startup (cgi_main.c:931) ==29422==by 0x7195D2: main (cgi_main.c:1873) ==29422== Test script: --- N/A Expected result: No LEAKs Actual result: -- LEAKs are reported
Bug #60339 [Com]: valgrind reports LEAK --with-mm
Edit report at https://bugs.php.net/bug.php?id=60339edit=1
ID: 60339
Comment by: yohgaki at ohgaki dot net
Reported by:yohgaki at ohgaki dot net
Summary:valgrind reports LEAK --with-mm
Status: Open
Type: Bug
Package:Session related
Operating System: Linux
PHP Version:5.4.0RC1
Block user comment: N
Private report: N
New Comment:
I figured out the cause. This is simple underflow. The correct patch is this.
--- mod_mm.c(ãªãã¸ã§ã³ 319529)
+++ mod_mm.c(ä½æ¥ã³ãã¼)
@@ -278,7 +278,7 @@
ps_mm_path = emalloc(save_path_len + 1 + (sizeof(PS_MM_FILE) - 1) +
mod_name_len + euid_len + 1);
memcpy(ps_mm_path, PS(save_path), save_path_len);
- if (PS(save_path)[save_path_len - 1] != DEFAULT_SLASH) {
+ if (save_path_len PS(save_path)[save_path_len - 1] != DEFAULT_SLASH)
{
ps_mm_path[save_path_len] = DEFAULT_SLASH;
save_path_len++;
}
Previous Comments:
[2011-11-19 17:53:07] yohgaki at ohgaki dot net
Adding extra byte to OnUpdateSaveDir() in session.c removes LEAKs
@@ -607,7 +613,7 @@
}
}
- OnUpdateString(entry, new_value, new_value_length, mh_arg1, mh_arg2,
mh_arg3, stage TSRMLS_CC);
+ OnUpdateString(entry, new_value, new_value_length+1, mh_arg1, mh_arg2,
mh_arg3, stage TSRMLS_CC);
return SUCCESS;
}
/* }}} */
but it does not seem to be a correct fix for this.
[2011-11-19 17:30:32] yohgaki at ohgaki dot net
Description:
Valgrind reports LEAKs --with-mm
(php-src HEAD is affected, too. I noticed this while I'm making strict session
patch.)
=
LEAKED TEST SUMMARY
-
session rfc1867 [ext/session/tests/rfc1867.phpt]
session rfc1867 [ext/session/tests/rfc1867_cleanup.phpt]
session rfc1867 disabled [ext/session/tests/rfc1867_disabled.phpt]
session rfc1867 disabled 2 [ext/session/tests/rfc1867_disabled_2.phpt]
session rfc1867 [ext/session/tests/rfc1867_inter.phpt]
session rfc1867 no name [ext/session/tests/rfc1867_no_name.phpt]
session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_cookie.phpt]
session rfc1867 sid get [ext/session/tests/rfc1867_sid_get.phpt]
session rfc1867 sid get 2 [ext/session/tests/rfc1867_sid_get_2.phpt]
session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_invalid.phpt]
session rfc1867 sid only cookie [ext/session/tests/rfc1867_sid_only_cookie.phpt]
session rfc1867 sid only cookie 2
[ext/session/tests/rfc1867_sid_only_cookie_2.phpt]
session rfc1867 sid post [ext/session/tests/rfc1867_sid_post.phpt]
Test session_module_name() function : variation
[ext/session/tests/session_module_name_variation3.phpt]
Test session_name() function : error functionality
[ext/session/tests/session_name_basic.phpt]
Test session_name() function : error functionality
[ext/session/tests/session_name_error.phpt]
Test session_name() function : variation
[ext/session/tests/session_name_variation1.phpt]
Test session_save_path() function : basic functionality
[ext/session/tests/session_save_path_basic.phpt]
Test session_save_path() function : error functionality
[ext/session/tests/session_save_path_error.phpt]
Test session_save_path() function : variation
[ext/session/tests/session_save_path_variation1.phpt]
Test session_save_path() function : variation
[ext/session/tests/session_save_path_variation4.phpt]
Test session_save_path() function : variation
[ext/session/tests/session_save_path_variation5.phpt]
Test session_set_save_handler() function : basic functionality
[ext/session/tests/session_set_save_handler_basic.phpt]
Test session_set_save_handler() function : using closures as callbacks
[ext/session/tests/session_set_save_handler_closures.phpt]
Test session_set_save_handler() function : error functionality
[ext/session/tests/session_set_save_handler_error3.phpt]
Test session_set_save_handler() function : variation
[ext/session/tests/session_set_save_handler_variation4.phpt]
=
All LEAK reports are the same.
*** ext/session/tests/rfc1867.mem
==29422== Invalid read of size 1
==29422==at 0x57D8D3: zm_startup_ps_mm (mod_mm.c:281)
==29422==by 0x578A94: zm_startup_session (session.c:2178)
==29422==by 0x6784D4: zend_startup_module_ex (zend_API.c:1653)
==29422==by 0x681304: zend_hash_apply (zend_hash.c:716)
==29422==by 0x67BB15: zend_startup_modules (zend_API.c:1780)
==29422==by 0x61C27B: php_module_startup (main.c:2132)
==29422==by 0x718F02: php_cgi_startup (cgi_main.c:931)
==29422==by 0x7195D2: main (cgi_main.c:1873)
==29422== Address 0x4fa31af is 1 bytes
Bug #60339 [Opn]: valgrind reports LEAK --with-mm
Edit report at https://bugs.php.net/bug.php?id=60339edit=1
ID: 60339
Updated by: fel...@php.net
Reported by:yohgaki at ohgaki dot net
Summary:valgrind reports LEAK --with-mm
Status: Open
Type: Bug
Package:Session related
Operating System: Linux
PHP Version:5.4.0RC1
Block user comment: N
Private report: N
New Comment:
I can't reproduce it, are you using any .INI?
=
PHP : sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 5.4.0RC2-dev
ZEND_VERSION: 2.4.0
PHP_OS : Linux - Linux sig11 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC
2011 x86_64
INI actual : /home/felipe/dev/php5_4
More .INIs :
CWD : /home/felipe/dev/php5_4
Extra dirs :
VALGRIND: valgrind-3.6.0.SVN-Debian
=
Previous Comments:
[2011-11-19 17:59:23] yohgaki at ohgaki dot net
I figured out the cause. This is simple underflow. The correct patch is this.
--- mod_mm.c(ãªãã¸ã§ã³ 319529)
+++ mod_mm.c(ä½æ¥ã³ãã¼)
@@ -278,7 +278,7 @@
ps_mm_path = emalloc(save_path_len + 1 + (sizeof(PS_MM_FILE) - 1) +
mod_name_len + euid_len + 1);
memcpy(ps_mm_path, PS(save_path), save_path_len);
- if (PS(save_path)[save_path_len - 1] != DEFAULT_SLASH) {
+ if (save_path_len PS(save_path)[save_path_len - 1] != DEFAULT_SLASH)
{
ps_mm_path[save_path_len] = DEFAULT_SLASH;
save_path_len++;
}
[2011-11-19 17:53:07] yohgaki at ohgaki dot net
Adding extra byte to OnUpdateSaveDir() in session.c removes LEAKs
@@ -607,7 +613,7 @@
}
}
- OnUpdateString(entry, new_value, new_value_length, mh_arg1, mh_arg2,
mh_arg3, stage TSRMLS_CC);
+ OnUpdateString(entry, new_value, new_value_length+1, mh_arg1, mh_arg2,
mh_arg3, stage TSRMLS_CC);
return SUCCESS;
}
/* }}} */
but it does not seem to be a correct fix for this.
[2011-11-19 17:30:32] yohgaki at ohgaki dot net
Description:
Valgrind reports LEAKs --with-mm
(php-src HEAD is affected, too. I noticed this while I'm making strict session
patch.)
=
LEAKED TEST SUMMARY
-
session rfc1867 [ext/session/tests/rfc1867.phpt]
session rfc1867 [ext/session/tests/rfc1867_cleanup.phpt]
session rfc1867 disabled [ext/session/tests/rfc1867_disabled.phpt]
session rfc1867 disabled 2 [ext/session/tests/rfc1867_disabled_2.phpt]
session rfc1867 [ext/session/tests/rfc1867_inter.phpt]
session rfc1867 no name [ext/session/tests/rfc1867_no_name.phpt]
session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_cookie.phpt]
session rfc1867 sid get [ext/session/tests/rfc1867_sid_get.phpt]
session rfc1867 sid get 2 [ext/session/tests/rfc1867_sid_get_2.phpt]
session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_invalid.phpt]
session rfc1867 sid only cookie [ext/session/tests/rfc1867_sid_only_cookie.phpt]
session rfc1867 sid only cookie 2
[ext/session/tests/rfc1867_sid_only_cookie_2.phpt]
session rfc1867 sid post [ext/session/tests/rfc1867_sid_post.phpt]
Test session_module_name() function : variation
[ext/session/tests/session_module_name_variation3.phpt]
Test session_name() function : error functionality
[ext/session/tests/session_name_basic.phpt]
Test session_name() function : error functionality
[ext/session/tests/session_name_error.phpt]
Test session_name() function : variation
[ext/session/tests/session_name_variation1.phpt]
Test session_save_path() function : basic functionality
[ext/session/tests/session_save_path_basic.phpt]
Test session_save_path() function : error functionality
[ext/session/tests/session_save_path_error.phpt]
Test session_save_path() function : variation
[ext/session/tests/session_save_path_variation1.phpt]
Test session_save_path() function : variation
[ext/session/tests/session_save_path_variation4.phpt]
Test session_save_path() function : variation
[ext/session/tests/session_save_path_variation5.phpt]
Test session_set_save_handler() function : basic functionality
[ext/session/tests/session_set_save_handler_basic.phpt]
Test session_set_save_handler() function : using closures as callbacks
[ext/session/tests/session_set_save_handler_closures.phpt]
Test session_set_save_handler() function : error functionality
[ext/session/tests/session_set_save_handler_error3.phpt]
Test session_set_save_handler() function : variation
[ext/session/tests/session_set_save_handler_variation4.phpt]
=
All
Bug #60339 [Com]: valgrind reports LEAK --with-mm
Edit report at https://bugs.php.net/bug.php?id=60339edit=1
ID: 60339
Comment by: yohgaki at ohgaki dot net
Reported by:yohgaki at ohgaki dot net
Summary:valgrind reports LEAK --with-mm
Status: Open
Type: Bug
Package:Session related
Operating System: Linux
PHP Version:5.4.0RC1
Block user comment: N
Private report: N
New Comment:
Since my tree is full of changes for strict session patch.
Could anyone commit patch for this bug?
Patch should be applied to php-src, php-src-5.4 and php-src-5.3.
I'm not sure if this bug is exploitable with current memory manager. Since
DEFAULT_SLASH would be ascii 47 or 97, it would be difficult.
Previous Comments:
[2011-11-19 18:10:06] fel...@php.net
I can't reproduce it, are you using any .INI?
=
PHP : sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 5.4.0RC2-dev
ZEND_VERSION: 2.4.0
PHP_OS : Linux - Linux sig11 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC
2011 x86_64
INI actual : /home/felipe/dev/php5_4
More .INIs :
CWD : /home/felipe/dev/php5_4
Extra dirs :
VALGRIND: valgrind-3.6.0.SVN-Debian
=
[2011-11-19 17:59:23] yohgaki at ohgaki dot net
I figured out the cause. This is simple underflow. The correct patch is this.
--- mod_mm.c(ãªãã¸ã§ã³ 319529)
+++ mod_mm.c(ä½æ¥ã³ãã¼)
@@ -278,7 +278,7 @@
ps_mm_path = emalloc(save_path_len + 1 + (sizeof(PS_MM_FILE) - 1) +
mod_name_len + euid_len + 1);
memcpy(ps_mm_path, PS(save_path), save_path_len);
- if (PS(save_path)[save_path_len - 1] != DEFAULT_SLASH) {
+ if (save_path_len PS(save_path)[save_path_len - 1] != DEFAULT_SLASH)
{
ps_mm_path[save_path_len] = DEFAULT_SLASH;
save_path_len++;
}
[2011-11-19 17:53:07] yohgaki at ohgaki dot net
Adding extra byte to OnUpdateSaveDir() in session.c removes LEAKs
@@ -607,7 +613,7 @@
}
}
- OnUpdateString(entry, new_value, new_value_length, mh_arg1, mh_arg2,
mh_arg3, stage TSRMLS_CC);
+ OnUpdateString(entry, new_value, new_value_length+1, mh_arg1, mh_arg2,
mh_arg3, stage TSRMLS_CC);
return SUCCESS;
}
/* }}} */
but it does not seem to be a correct fix for this.
[2011-11-19 17:30:32] yohgaki at ohgaki dot net
Description:
Valgrind reports LEAKs --with-mm
(php-src HEAD is affected, too. I noticed this while I'm making strict session
patch.)
=
LEAKED TEST SUMMARY
-
session rfc1867 [ext/session/tests/rfc1867.phpt]
session rfc1867 [ext/session/tests/rfc1867_cleanup.phpt]
session rfc1867 disabled [ext/session/tests/rfc1867_disabled.phpt]
session rfc1867 disabled 2 [ext/session/tests/rfc1867_disabled_2.phpt]
session rfc1867 [ext/session/tests/rfc1867_inter.phpt]
session rfc1867 no name [ext/session/tests/rfc1867_no_name.phpt]
session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_cookie.phpt]
session rfc1867 sid get [ext/session/tests/rfc1867_sid_get.phpt]
session rfc1867 sid get 2 [ext/session/tests/rfc1867_sid_get_2.phpt]
session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_invalid.phpt]
session rfc1867 sid only cookie [ext/session/tests/rfc1867_sid_only_cookie.phpt]
session rfc1867 sid only cookie 2
[ext/session/tests/rfc1867_sid_only_cookie_2.phpt]
session rfc1867 sid post [ext/session/tests/rfc1867_sid_post.phpt]
Test session_module_name() function : variation
[ext/session/tests/session_module_name_variation3.phpt]
Test session_name() function : error functionality
[ext/session/tests/session_name_basic.phpt]
Test session_name() function : error functionality
[ext/session/tests/session_name_error.phpt]
Test session_name() function : variation
[ext/session/tests/session_name_variation1.phpt]
Test session_save_path() function : basic functionality
[ext/session/tests/session_save_path_basic.phpt]
Test session_save_path() function : error functionality
[ext/session/tests/session_save_path_error.phpt]
Test session_save_path() function : variation
[ext/session/tests/session_save_path_variation1.phpt]
Test session_save_path() function : variation
[ext/session/tests/session_save_path_variation4.phpt]
Test session_save_path() function : variation
[ext/session/tests/session_save_path_variation5.phpt]
Test session_set_save_handler() function : basic functionality
[ext/session/tests/session_set_save_handler_basic.phpt]
Test
Bug #60339 [Com]: valgrind reports LEAK --with-mm
Edit report at https://bugs.php.net/bug.php?id=60339edit=1
ID: 60339
Comment by: yohgaki at ohgaki dot net
Reported by:yohgaki at ohgaki dot net
Summary:valgrind reports LEAK --with-mm
Status: Open
Type: Bug
Package:Session related
Operating System: Linux
PHP Version:5.4.0RC1
Block user comment: N
Private report: N
New Comment:
I've tested as follows.
(from my bash history)
1004 tar zxvf ../Download/php-5.4.0RC1.tar.bz2
1005 cd php-5.4.0RC1/
1006 ./configure --with-mm make -j 8
1007 TEST_PHP_EXECUTABLE=./sapi/cli/php ./run-tests.php -m ext/session/
Felipe, if you could commit the patch, I appreciated it.
If you take a look at PHP_MINIT_FUNCTION(ps_mm) in ext/session/mod_mm.c, you'll
see it will underflow by 1 byte when strlen(PS(save_path)) equals 0.
Previous Comments:
[2011-11-19 18:20:44] yohgaki at ohgaki dot net
Since my tree is full of changes for strict session patch.
Could anyone commit patch for this bug?
Patch should be applied to php-src, php-src-5.4 and php-src-5.3.
I'm not sure if this bug is exploitable with current memory manager. Since
DEFAULT_SLASH would be ascii 47 or 97, it would be difficult.
[2011-11-19 18:10:06] fel...@php.net
I can't reproduce it, are you using any .INI?
=
PHP : sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 5.4.0RC2-dev
ZEND_VERSION: 2.4.0
PHP_OS : Linux - Linux sig11 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC
2011 x86_64
INI actual : /home/felipe/dev/php5_4
More .INIs :
CWD : /home/felipe/dev/php5_4
Extra dirs :
VALGRIND: valgrind-3.6.0.SVN-Debian
=
[2011-11-19 17:59:23] yohgaki at ohgaki dot net
I figured out the cause. This is simple underflow. The correct patch is this.
--- mod_mm.c(ãªãã¸ã§ã³ 319529)
+++ mod_mm.c(ä½æ¥ã³ãã¼)
@@ -278,7 +278,7 @@
ps_mm_path = emalloc(save_path_len + 1 + (sizeof(PS_MM_FILE) - 1) +
mod_name_len + euid_len + 1);
memcpy(ps_mm_path, PS(save_path), save_path_len);
- if (PS(save_path)[save_path_len - 1] != DEFAULT_SLASH) {
+ if (save_path_len PS(save_path)[save_path_len - 1] != DEFAULT_SLASH)
{
ps_mm_path[save_path_len] = DEFAULT_SLASH;
save_path_len++;
}
[2011-11-19 17:53:07] yohgaki at ohgaki dot net
Adding extra byte to OnUpdateSaveDir() in session.c removes LEAKs
@@ -607,7 +613,7 @@
}
}
- OnUpdateString(entry, new_value, new_value_length, mh_arg1, mh_arg2,
mh_arg3, stage TSRMLS_CC);
+ OnUpdateString(entry, new_value, new_value_length+1, mh_arg1, mh_arg2,
mh_arg3, stage TSRMLS_CC);
return SUCCESS;
}
/* }}} */
but it does not seem to be a correct fix for this.
[2011-11-19 17:30:32] yohgaki at ohgaki dot net
Description:
Valgrind reports LEAKs --with-mm
(php-src HEAD is affected, too. I noticed this while I'm making strict session
patch.)
=
LEAKED TEST SUMMARY
-
session rfc1867 [ext/session/tests/rfc1867.phpt]
session rfc1867 [ext/session/tests/rfc1867_cleanup.phpt]
session rfc1867 disabled [ext/session/tests/rfc1867_disabled.phpt]
session rfc1867 disabled 2 [ext/session/tests/rfc1867_disabled_2.phpt]
session rfc1867 [ext/session/tests/rfc1867_inter.phpt]
session rfc1867 no name [ext/session/tests/rfc1867_no_name.phpt]
session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_cookie.phpt]
session rfc1867 sid get [ext/session/tests/rfc1867_sid_get.phpt]
session rfc1867 sid get 2 [ext/session/tests/rfc1867_sid_get_2.phpt]
session rfc1867 sid cookie [ext/session/tests/rfc1867_sid_invalid.phpt]
session rfc1867 sid only cookie [ext/session/tests/rfc1867_sid_only_cookie.phpt]
session rfc1867 sid only cookie 2
[ext/session/tests/rfc1867_sid_only_cookie_2.phpt]
session rfc1867 sid post [ext/session/tests/rfc1867_sid_post.phpt]
Test session_module_name() function : variation
[ext/session/tests/session_module_name_variation3.phpt]
Test session_name() function : error functionality
[ext/session/tests/session_name_basic.phpt]
Test session_name() function : error functionality
[ext/session/tests/session_name_error.phpt]
Test session_name() function : variation
[ext/session/tests/session_name_variation1.phpt]
Test session_save_path() function : basic functionality
Bug #60339 [Opn-Csd]: valgrind reports LEAK --with-mm
Edit report at https://bugs.php.net/bug.php?id=60339edit=1
ID: 60339
Updated by: fel...@php.net
Reported by:yohgaki at ohgaki dot net
Summary:valgrind reports LEAK --with-mm
-Status: Open
+Status: Closed
Type: Bug
Package:Session related
Operating System: Linux
PHP Version:5.4.0RC1
-Assigned To:
+Assigned To:felipe
Block user comment: N
Private report: N
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
I can reproduce it. :P Patch committed, thanks!
Previous Comments:
[2011-11-19 18:50:37] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=319553
Log: - Fixed bug #60339 (valgrind reports LEAK --with-mm)
patch by: yohgaki at ohgaki dot net
[2011-11-19 18:30:23] yohgaki at ohgaki dot net
I've tested as follows.
(from my bash history)
1004 tar zxvf ../Download/php-5.4.0RC1.tar.bz2
1005 cd php-5.4.0RC1/
1006 ./configure --with-mm make -j 8
1007 TEST_PHP_EXECUTABLE=./sapi/cli/php ./run-tests.php -m ext/session/
Felipe, if you could commit the patch, I appreciated it.
If you take a look at PHP_MINIT_FUNCTION(ps_mm) in ext/session/mod_mm.c, you'll
see it will underflow by 1 byte when strlen(PS(save_path)) equals 0.
[2011-11-19 18:20:44] yohgaki at ohgaki dot net
Since my tree is full of changes for strict session patch.
Could anyone commit patch for this bug?
Patch should be applied to php-src, php-src-5.4 and php-src-5.3.
I'm not sure if this bug is exploitable with current memory manager. Since
DEFAULT_SLASH would be ascii 47 or 97, it would be difficult.
[2011-11-19 18:10:06] fel...@php.net
I can't reproduce it, are you using any .INI?
=
PHP : sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 5.4.0RC2-dev
ZEND_VERSION: 2.4.0
PHP_OS : Linux - Linux sig11 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC
2011 x86_64
INI actual : /home/felipe/dev/php5_4
More .INIs :
CWD : /home/felipe/dev/php5_4
Extra dirs :
VALGRIND: valgrind-3.6.0.SVN-Debian
=
[2011-11-19 17:59:23] yohgaki at ohgaki dot net
I figured out the cause. This is simple underflow. The correct patch is this.
--- mod_mm.c(ãªãã¸ã§ã³ 319529)
+++ mod_mm.c(ä½æ¥ã³ãã¼)
@@ -278,7 +278,7 @@
ps_mm_path = emalloc(save_path_len + 1 + (sizeof(PS_MM_FILE) - 1) +
mod_name_len + euid_len + 1);
memcpy(ps_mm_path, PS(save_path), save_path_len);
- if (PS(save_path)[save_path_len - 1] != DEFAULT_SLASH) {
+ if (save_path_len PS(save_path)[save_path_len - 1] != DEFAULT_SLASH)
{
ps_mm_path[save_path_len] = DEFAULT_SLASH;
save_path_len++;
}
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=60339
--
Edit this bug report at https://bugs.php.net/bug.php?id=60339edit=1
[PHP-BUG] Bug #60340 [NEW]: DateTime. The problem of determining the relative dates, by the command last
From:
Operating system: Windows
PHP version: 5.3.8
Package: Date/time related
Bug Type: Bug
Bug description:DateTime. The problem of determining the relative dates, by the
command last
Description:
Incorrect data is generated by function DateTime::__construct in case of
using the
relative definition of time.
If you use the command last day of month the previous month will be
returned.
If you use the command first day of month the correct month will be
returned and
second day in the month will be returned.
Test script:
---
$datea = new DateTime('last day October 2011');
echo $datea-format('Y-F-d');
$dateb = new DateTime('last monday October 2011');
echo $dateb-format('Y-F-d');
$datec = new DateTime('first day October 2011');
echo $datec-format('Y-F-d');
$datec = new DateTime('first day November 2011');
echo $datec-format('Y-F-d');
Expected result:
2011-October-30
2011-October-30
2011-October-01
2011-November-01
Actual result:
--
2011-September-30
2011-September-26
2011-October-02
2011-November-02
--
Edit bug report at https://bugs.php.net/bug.php?id=60340edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60340r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60340r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60340r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60340r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60340r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60340r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60340r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60340r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60340r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60340r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60340r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60340r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60340r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60340r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60340r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60340r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60340r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60340r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60340r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60340r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60340r=mysqlcfg
[PHP-BUG] Req #60341 [NEW]: SplFixedArray throws generic exceptions.
From: Operating system: irrelevant PHP version: Irrelevant Package: SPL related Bug Type: Feature/Change Request Bug description:SplFixedArray throws generic exceptions. Description: SplFixedArray thankfully throws exceptions when you try to do incorrect things with indices. However, the types of exceptions are just too generic. If I give the wrong type of index, that's a logic error (I'd expect InvalidArgument or at least something that inherits from LogicError to be thrown). If I give an index that's that's a valid type but doesn't exist, I'd expect an OutOfBoundsException to be thrown. Instead I get a generic RuntimeException. I should expect because they are very different problems that I would at least get a distinguishing message between the two. However, I get the same descriptions: 'Index invalid or out of range'. The very message suggests they should be different exceptions. The first fix would sort-of break backwards compatibility: throw an InvalidArgumentException for things of the wrong type. The second fix, throw OutOfBoundsException on incorrect index, could be implemented and keep backwards compatibility. Test script: --- $fa = new SplFixedArray(1); $fa[new StdClass()]; //expect InvalidArgumentException or perhaps OutOfRangeException $fa[2] = 'james'; // expect OutOfBoundsException Expected result: I expect $fa[new StdClass] to throw an InvalidArgumentException, not a RuntimeException I expect $fa['2'] to throw OutOfBoundsException not a RuntimeException. Actual result: -- Both throw RuntimeExceptions. -- Edit bug report at https://bugs.php.net/bug.php?id=60341edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60341r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60341r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60341r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60341r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60341r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60341r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60341r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60341r=needscript Try newer version: https://bugs.php.net/fix.php?id=60341r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60341r=support Expected behavior: https://bugs.php.net/fix.php?id=60341r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60341r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60341r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60341r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60341r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60341r=dst IIS Stability: https://bugs.php.net/fix.php?id=60341r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60341r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60341r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60341r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60341r=mysqlcfg
Bug #60340 [Opn-Bgs]: DateTime. The problem of determining the relative dates, by the command last
Edit report at https://bugs.php.net/bug.php?id=60340edit=1
ID: 60340
Updated by: sala...@php.net
Reported by:marcingronowski at gmail dot com
Summary:DateTime. The problem of determining the relative
dates, by the command last
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Windows
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
You aren't testing first/last day of, you're testing first/last day which
simply moves the date defined by the absolute parts forward/backward by one
day.
The same applies to your last monday test, which should be last monday of.
All of these behaviours are documented.
Previous Comments:
[2011-11-19 18:58:22] marcingronowski at gmail dot com
Description:
Incorrect data is generated by function DateTime::__construct in case of using
the
relative definition of time.
If you use the command last day of month the previous month will be returned.
If you use the command first day of month the correct month will be returned
and
second day in the month will be returned.
Test script:
---
$datea = new DateTime('last day October 2011');
echo $datea-format('Y-F-d');
$dateb = new DateTime('last monday October 2011');
echo $dateb-format('Y-F-d');
$datec = new DateTime('first day October 2011');
echo $datec-format('Y-F-d');
$datec = new DateTime('first day November 2011');
echo $datec-format('Y-F-d');
Expected result:
2011-October-30
2011-October-30
2011-October-01
2011-November-01
Actual result:
--
2011-September-30
2011-September-26
2011-October-02
2011-November-02
--
Edit this bug report at https://bugs.php.net/bug.php?id=60340edit=1
Req #43650 [Com]: Objects implementing ArrayAccess don't work with array_* functions
Edit report at https://bugs.php.net/bug.php?id=43650edit=1 ID: 43650 Comment by: morrison dot levi at gmail dot com Reported by:cwei...@php.net Summary:Objects implementing ArrayAccess don't work with array_* functions Status: Open Type: Feature/Change Request Package:SPL related PHP Version:5.2.5 Block user comment: N Private report: N New Comment: Agree on this, even though you can make this work in other ways. You can have a method that takes a function as a parameter and will call it with a reference (if applicable) to your data. It still feels hackish when they can already access all my data. Previous Comments: [2007-12-21 09:20:02] cwei...@php.net (Feature request from http://bugs.php.net/bug.php?id=34849) [2007-12-21 09:18:07] cwei...@php.net Description: Objects of classes implementing ArrayAccess (e.g. ArrayObject) cannot be used with array_* functions like array_multisort. It would be cool if PHP would allow this. -- Edit this bug report at https://bugs.php.net/bug.php?id=43650edit=1
Bug #60317 [Asn-Csd]: Incorrect mailinglist used
Edit report at https://bugs.php.net/bug.php?id=60317edit=1 ID: 60317 Updated by: tyr...@php.net Reported by:bj...@php.net Summary:Incorrect mailinglist used -Status: Assigned +Status: Closed Type: Bug Package:Website problem Operating System: * PHP Version:Irrelevant Assigned To:tyrael Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Since the websites are not directly updated from the SVN server, the fix might need some time to spread across the globe to all mirror sites, including PHP.net itself. Thank you for the report, and for helping us make PHP.net better. Previous Comments: [2011-11-19 23:50:51] tyr...@php.net Automatic comment from SVN on behalf of tyrael Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=319567 Log: list() won't work for associate array, so the default fetchmode (MDB2_FETCHMODE_ORDERED) should be used. fixing #60317 [2011-11-17 09:26:19] tyr...@php.net checked the db, the pseudo package settings seems to be fine: id: 6 parent: 1 name: Website problem long_name: PHP.net Website problem project: php list_email: php-webmas...@lists.php.net disabled: 0 from a quick glance over get_package_mail() I don't see any reason why wouldn't it behave correctly. I will test this further at the afternoon. [2011-11-17 07:54:21] bj...@php.net Description: Website problem bugs are suddenly being sent to php-bugs@, rather then php- webmaster@ Test script: --- http://news.php.net/php.bugs/165243 http://news.php.net/php.bugs/165270 -- Edit this bug report at https://bugs.php.net/bug.php?id=60317edit=1
Bug #60340 [Com]: DateTime. The problem of determining the relative dates, by the command last
Edit report at https://bugs.php.net/bug.php?id=60340edit=1
ID: 60340
Comment by: marcingronowski at gmail dot com
Reported by:marcingronowski at gmail dot com
Summary:DateTime. The problem of determining the relative
dates, by the command last
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Windows
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
@ sala...@php.net
You're right. I'm sorry. It's my fault.
Previous Comments:
[2011-11-19 21:33:39] sala...@php.net
You aren't testing first/last day of, you're testing first/last day which
simply moves the date defined by the absolute parts forward/backward by one
day.
The same applies to your last monday test, which should be last monday of.
All of these behaviours are documented.
[2011-11-19 18:58:22] marcingronowski at gmail dot com
Description:
Incorrect data is generated by function DateTime::__construct in case of using
the
relative definition of time.
If you use the command last day of month the previous month will be returned.
If you use the command first day of month the correct month will be returned
and
second day in the month will be returned.
Test script:
---
$datea = new DateTime('last day October 2011');
echo $datea-format('Y-F-d');
$dateb = new DateTime('last monday October 2011');
echo $dateb-format('Y-F-d');
$datec = new DateTime('first day October 2011');
echo $datec-format('Y-F-d');
$datec = new DateTime('first day November 2011');
echo $datec-format('Y-F-d');
Expected result:
2011-October-30
2011-October-30
2011-October-01
2011-November-01
Actual result:
--
2011-September-30
2011-September-26
2011-October-02
2011-November-02
--
Edit this bug report at https://bugs.php.net/bug.php?id=60340edit=1
[PHP-BUG] Bug #60342 [NEW]: reentrancy.c error: too few arguments to function
From: Operating system: OpenIndiana 151a PHP version: 5.3SVN-2011-11-19 (snap) Package: Compile Failure Bug Type: Bug Bug description:reentrancy.c error: too few arguments to function Description: reentrancy.c error: too few arguments to function 'ctime_r' and 'asctime_r' This error affected on both PHP 5.3.8 stable version and PHP 5.3 snapshot version. Test script: --- # ./configure --prefix=/usr/php --enable-fastcgi --enable-fmp --with-mcrypt --with-zlib --enable-mbstring --disable-pdo --with-curl-disable-debug --enable-pic disable-rpatch --enable-inline-optimization --with-bz2 --with-xml --enable-sockets --enable-mbregex --with-mhash --enable-xslt --enable-memcache --enable-zip --with-pcre Expected result: successful Actual result: -- # make ... /bin/sh /tmp/php5.3-20191730/libtool --silent --preserve-dup-deps --mode=compile gcc -Imain/ -I/tmp/php5.3-20191730/main/ -DPHP_ATOM_INC -I/tmp/php5.3-20191730/include -I/tmp/php5.3-20191730/main -I/tmp/php5.3-20191730 -I/tmp/php5.3-20191730/ext/date/lib -I/tmp/php5.3-20191730/ext/ereg/regex -I/usr/include/libxml2 -I/tmp/php5.3-20191730/ext/mbstring/oniguruma -I/tmp/php5.3-20191730/ext/mbstring/libmbfl -I/tmp/php5.3-20191730/ext/mbstring/libmbfl/mbfl -I/tmp/php5.3-20191730/TSRM -I/tmp/php5.3-20191730/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /tmp/php5.3-20191730/main/strlcat.c -o main/strlcat.lo /bin/sh /tmp/php5.3-20191730/libtool --silent --preserve-dup-deps --mode=compile gcc -Imain/ -I/tmp/php5.3-20191730/main/ -DPHP_ATOM_INC -I/tmp/php5.3-20191730/include -I/tmp/php5.3-20191730/main -I/tmp/php5.3-20191730 -I/tmp/php5.3-20191730/ext/date/lib -I/tmp/php5.3-20191730/ext/ereg/regex -I/usr/include/libxml2 -I/tmp/php5.3-20191730/ext/mbstring/oniguruma -I/tmp/php5.3-20191730/ext/mbstring/libmbfl -I/tmp/php5.3-20191730/ext/mbstring/libmbfl/mbfl -I/tmp/php5.3-20191730/TSRM -I/tmp/php5.3-20191730/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /tmp/php5.3-20191730/main/mergesort.c -o main/mergesort.lo /bin/sh /tmp/php5.3-20191730/libtool --silent --preserve-dup-deps --mode=compile gcc -Imain/ -I/tmp/php5.3-20191730/main/ -DPHP_ATOM_INC -I/tmp/php5.3-20191730/include -I/tmp/php5.3-20191730/main -I/tmp/php5.3-20191730 -I/tmp/php5.3-20191730/ext/date/lib -I/tmp/php5.3-20191730/ext/ereg/regex -I/usr/include/libxml2 -I/tmp/php5.3-20191730/ext/mbstring/oniguruma -I/tmp/php5.3-20191730/ext/mbstring/libmbfl -I/tmp/php5.3-20191730/ext/mbstring/libmbfl/mbfl -I/tmp/php5.3-20191730/TSRM -I/tmp/php5.3-20191730/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /tmp/php5.3-20191730/main/reentrancy.c -o main/reentrancy.lo /tmp/php5.3-20191730/main/reentrancy.c: In function 'php_ctime_r': /tmp/php5.3-20191730/main/reentrancy.c:63:2: error: too few arguments to function 'ctime_r' /usr/include/time.h:320:14: note: declared here /tmp/php5.3-20191730/main/reentrancy.c: In function 'php_asctime_r': /tmp/php5.3-20191730/main/reentrancy.c:70:2: error: too few arguments to function 'asctime_r' /usr/include/time.h:319:14: note: declared here *** Error code 1 make: Fatal error: Command failed for target `main/reentrancy.lo' -- Edit bug report at https://bugs.php.net/bug.php?id=60342edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60342r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60342r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60342r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60342r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60342r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60342r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60342r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60342r=needscript Try newer version: https://bugs.php.net/fix.php?id=60342r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60342r=support Expected behavior: https://bugs.php.net/fix.php?id=60342r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60342r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60342r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60342r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60342r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60342r=dst IIS Stability: https://bugs.php.net/fix.php?id=60342r=isapi Install GNU Sed:
Bug #52769 [Com]: realpath not working inside phar
Edit report at https://bugs.php.net/bug.php?id=52769edit=1
ID: 52769
Comment by: maks dot slesarenko at gmail dot com
Reported by:miha dot vrhovnik at domenca dot com
Summary:realpath not working inside phar
Status: Open
Type: Bug
Package:PHAR related
Operating System: any
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Hi, I'm not PHP Core developer, just developer using php :)
I think this is not a bug, functions like chmod, chown and realpath, glob are
working only with file:// stream. And this is correct! realpath() always
should provide real path on filesytem (file://), not in phar, zip, http or
myOwnStream.
I can not even imagine what how it will be in other case for ex.
realpath('myRegisteredStream://somepath')
or chmod('http://google.com', 777) - funny isn't it?!
Previous Comments:
[2011-11-15 16:01:05] fel...@php.net
Probably related to bug #51806
[2010-09-03 12:45:51] miha dot vrhovnik at domenca dot com
Description:
When you run a realpath returns false when run on phar paths.
Test script:
---
put a test script inside \foo\bar\test.php
and create a phar where \bar\test.php is inisde it
run created phar..
?php
echo (realpath(dirname(__FILE__) . '/../'));
Expected result:
see the full path
Actual result:
--
nothing
--
Edit this bug report at https://bugs.php.net/bug.php?id=52769edit=1
Bug #31455 [Com]: multiple session_start() creates multiple session cookies in HTTP-Response
Edit report at https://bugs.php.net/bug.php?id=31455edit=1
ID: 31455
Comment by: danielc at analysisandsolutions dot com
Reported by:rene dot bangemann at web dot de
Summary:multiple session_start() creates multiple session
cookies in HTTP-Response
Status: Wont fix
Type: Bug
Package:Session related
Operating System: Win32
PHP Version:4CVS, 5CVS
Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
See also: https://bugs.php.net/bug.php?id=31455
Previous Comments:
[2010-10-15 23:26:30] WarrenGaebel at FriendlyNeighbourGuide dot ca
I am experiencing a similar, but not identical problem.
I reload my page multiple times, using session_start() every time it loads.
JavaScript sets cookies that I use in php. When using Internet Explorer,
$_ENV[HTTP_COOKIE] contains multiple entries for each cookie. This does not
happen with Firefox.
As near as I can figure so far, when executing code at a domain named x.y.z,
Internet Explorer sends the cookies for x.y.z followed by the cookies for y.z.
Php then puts both sets of cookies into $_ENV[HTTP_COOKIE].
Perhaps this may be considered a PHP bug, perhaps not. IMHO, this is an
Internet Explorer bug. I post it here in the hope that it may help you resolve
your problem.
... Warren Gaebel, B.A., B.C.S.
[2005-02-14 00:18:30] rene dot bangemann at web dot de
Ok, you are right that someone could start several sessions within one request.
But thats not my use case:
I'm using a PHP script to perform some actions which can take up to some hours.
E.G. for displaying progress information about the running process a second php
script needs to access the session vars. This forces to close the session file
via session_write_close() in the first script. After this function call, the
second PHP script can do a session_start() and access the current values of the
session vars.
After finishing the second request the session file will be closed again.
If the first script has to store new values of session related vars in the
session file, it uses a combination of session_start() and
session_write_close() to update the content within the session file.
Unfortunatly in my case this can happen very often (because of the long
execution time).
Under normal circumstances I could live with this feature :-). But I'm afraid
that in combination with HTML frames this behaviour of PHP can force deadlocks
in different browsers like Internet Explorer or Mozilla. Unfortunately I can't
present a 100% working example for reproducable deadlocks.
I would suggest to create a flag containing true or false, if the Cookie for
the current session id already was sent or not.
If the cookie wasn't already sent, or the used session id changes, of course
another Cookie has to be sent.
[2005-02-13 18:03:51] tony2...@php.net
Okay, no more dirty hacks =)
Marking it as won't fix and considering as a feature.
[2005-02-13 09:44:30] sni...@php.net
Then how would you handle this (very unlikely :) code:
?php
session_name('foo1');
session_id('foobar1');
session_start();
session_write_close();
session_name('foo2');
session_id('foobar2');
session_start();
session_write_close();
session_name('foo3');
session_id('foobar3');
session_start();
session_write_close();
?
Yes, someone MIGHT rely on that kind of code too.
And as it IS possible to start as many _different_ sessions in single
request, why should we not allow it?
(this is actually for Tony, FYI when he figures out how to fix this bug :)
[2005-01-09 15:49:13] rene dot bangemann at web dot de
Description:
I'm using a combination of session_start() and session_write_close() to access
and update session variables.
In some scripts this function calls will be executed up to 50 times.
For each call of session_start() a HTTP-Header with the PHP session id will be
created in the same HTTP response.
I would expect, that in the HTTP response will be only one HTTP-Header with the
session id.
Reproduce code:
---
?php
session_start();
session_write_close();
session_start();
session_write_close();
session_start();
session_write_close();
?
Expected result:
HTTP-Header Set-Cookie with PHP session id created only once in HTTP response
Actual result:
--
The code above will create a HTTP response with three identical HTTP Set-Cookie
headers
--
Edit this bug report at
Bug #31455 [Com]: multiple session_start() creates multiple session cookies in HTTP-Response
Edit report at https://bugs.php.net/bug.php?id=31455edit=1
ID: 31455
Comment by: danielc at analysisandsolutions dot com
Reported by:rene dot bangemann at web dot de
Summary:multiple session_start() creates multiple session
cookies in HTTP-Response
Status: Wont fix
Type: Bug
Package:Session related
Operating System: Win32
PHP Version:4CVS, 5CVS
Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
I mean to say, see also: https://bugs.php.net/bug.php?id=38104
Previous Comments:
[2011-11-20 05:21:02] danielc at analysisandsolutions dot com
See also: https://bugs.php.net/bug.php?id=31455
[2010-10-15 23:26:30] WarrenGaebel at FriendlyNeighbourGuide dot ca
I am experiencing a similar, but not identical problem.
I reload my page multiple times, using session_start() every time it loads.
JavaScript sets cookies that I use in php. When using Internet Explorer,
$_ENV[HTTP_COOKIE] contains multiple entries for each cookie. This does not
happen with Firefox.
As near as I can figure so far, when executing code at a domain named x.y.z,
Internet Explorer sends the cookies for x.y.z followed by the cookies for y.z.
Php then puts both sets of cookies into $_ENV[HTTP_COOKIE].
Perhaps this may be considered a PHP bug, perhaps not. IMHO, this is an
Internet Explorer bug. I post it here in the hope that it may help you resolve
your problem.
... Warren Gaebel, B.A., B.C.S.
[2005-02-14 00:18:30] rene dot bangemann at web dot de
Ok, you are right that someone could start several sessions within one request.
But thats not my use case:
I'm using a PHP script to perform some actions which can take up to some hours.
E.G. for displaying progress information about the running process a second php
script needs to access the session vars. This forces to close the session file
via session_write_close() in the first script. After this function call, the
second PHP script can do a session_start() and access the current values of the
session vars.
After finishing the second request the session file will be closed again.
If the first script has to store new values of session related vars in the
session file, it uses a combination of session_start() and
session_write_close() to update the content within the session file.
Unfortunatly in my case this can happen very often (because of the long
execution time).
Under normal circumstances I could live with this feature :-). But I'm afraid
that in combination with HTML frames this behaviour of PHP can force deadlocks
in different browsers like Internet Explorer or Mozilla. Unfortunately I can't
present a 100% working example for reproducable deadlocks.
I would suggest to create a flag containing true or false, if the Cookie for
the current session id already was sent or not.
If the cookie wasn't already sent, or the used session id changes, of course
another Cookie has to be sent.
[2005-02-13 18:03:51] tony2...@php.net
Okay, no more dirty hacks =)
Marking it as won't fix and considering as a feature.
[2005-02-13 09:44:30] sni...@php.net
Then how would you handle this (very unlikely :) code:
?php
session_name('foo1');
session_id('foobar1');
session_start();
session_write_close();
session_name('foo2');
session_id('foobar2');
session_start();
session_write_close();
session_name('foo3');
session_id('foobar3');
session_start();
session_write_close();
?
Yes, someone MIGHT rely on that kind of code too.
And as it IS possible to start as many _different_ sessions in single
request, why should we not allow it?
(this is actually for Tony, FYI when he figures out how to fix this 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=31455
--
Edit this bug report at https://bugs.php.net/bug.php?id=31455edit=1
Bug #38104 [Com]: session_start()/session_write_close() creates multiple session cookies headers
Edit report at https://bugs.php.net/bug.php?id=38104edit=1
ID: 38104
Comment by: danielc at analysisandsolutions dot com
Reported by:m dot v dot veluw dot smscity at gmail dot com
Summary:session_start()/session_write_close() creates
multiple session cookies headers
Status: Bogus
Type: Bug
Package:Session related
Operating System: any
PHP Version:5.1.4
Block user comment: N
Private report: N
New Comment:
See also https://bugs.php.net/bug.php?id=31455
Previous Comments:
[2011-11-09 18:34:52] rfunk at funknet dot net
I just ran into this bug in PHP 5.3.5 when working with a script that does lots
of
session_start()/session_write_close() in a long-running task, so that separate
requests can still access the
session during that long task. (Specifically those separate requests are
checking the progress of the long
task.)
The resulting absurdly redundant Set-Cookie header caused Firefox 7 to lock up
for a few seconds, and caused IE8
to give its infamously useless Internet Explorer cannot display the webpage
page. So this bug is not Bogus s
it claims.
I do have a workaround, however. I'm already doing an ob_start() at the top of
the script, and now before the
ending ob_end_flush() I replace the Set-Cookie header with a new one:
if (SID) header('Set-Cookie: '.SID.'; path=/', true);
After adding this, I no longer have the above problems in Firefox and IE.
[2011-02-04 17:00:58] vdklah at hotmail dot com
I can not tell how much I disagree on this. Calling session_start() followed by
session_write_close() is a very valid way to avoid blocking multiple processes.
(See also here http://konrness.com/php5/how-to-prevent-blocking-php-requests/.)
This problem is huge since we are facing fatal crashing clients due to zillions
of duplicate PHPSESSID entries in one cookie. Our server is big and complicated
and so we are not willing to change anything in this area while all is already
taken in production. Totally stuck on this and I'm not happy. This is a very
obvious PHP bug that can be proven in 4 lines of code without any client
intervention.
[2006-07-14 20:46:11] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Session is created every time you call session_start(). If you
want to avoid multiple cookie, write better code. Multiple
session_start() especially for the same names in the same
script seems like a really bad idea.
[2006-07-14 10:23:58] m dot v dot veluw dot smscity at gmail dot com
Description:
When using session_start() and session_write_close() with the same session
id/name will add multiple session cookies with the exact same contents
everytime session_start is used.
This is useless overhead if it is the same.
Reproduce code:
---
session_name('uniqueName1');
session_start();
$_SESSION['Foo1'] = 'Bar1';
session_write_close();
session_name('uniqueName2');
session_start();
$_SESSION['Foo2'] = 'Bar2';
session_write_close();
session_name('uniqueName1');
session_start();
$sessionValue = $_SESSION['Foo1'];
print $sessionValue;
session_write_close();
session_name('uniqueName2');
session_start();
$sessionValue = $_SESSION['Foo2'];
print $sessionValue;
session_write_close();
Expected result:
just 1 session cookie header for uniqueName1.
just 1 session cookie header for uniqueName2.
Actual result:
--
2 session cookie headers for uniqueName1, where both are exactly the same
2 session cookie headers for uniqueName2, where both are exactly the same
--
Edit this bug report at https://bugs.php.net/bug.php?id=38104edit=1
Bug #60342 [Com]: reentrancy.c error: too few arguments to function
Edit report at https://bugs.php.net/bug.php?id=60342edit=1 ID: 60342 Comment by: nam dot nh at nd24 dot net Reported by:nam dot nh at nd24 dot net Summary:reentrancy.c error: too few arguments to function Status: Open Type: Bug Package:Compile Failure Operating System: OpenIndiana 151a PHP Version:5.3SVN-2011-11-19 (snap) Block user comment: N Private report: N New Comment: PHP 5.4 snap doesn't affect, runs smoothly. Previous Comments: [2011-11-20 00:59:28] nam dot nh at nd24 dot net Description: reentrancy.c error: too few arguments to function 'ctime_r' and 'asctime_r' This error affected on both PHP 5.3.8 stable version and PHP 5.3 snapshot version. Test script: --- # ./configure --prefix=/usr/php --enable-fastcgi --enable-fmp --with-mcrypt --with-zlib --enable-mbstring --disable-pdo --with-curl-disable-debug --enable-pic disable-rpatch --enable-inline-optimization --with-bz2 --with-xml --enable-sockets --enable-mbregex --with-mhash --enable-xslt --enable-memcache --enable-zip --with-pcre Expected result: successful Actual result: -- # make ... /bin/sh /tmp/php5.3-20191730/libtool --silent --preserve-dup-deps --mode=compile gcc -Imain/ -I/tmp/php5.3-20191730/main/ -DPHP_ATOM_INC -I/tmp/php5.3-20191730/include -I/tmp/php5.3-20191730/main -I/tmp/php5.3-20191730 -I/tmp/php5.3-20191730/ext/date/lib -I/tmp/php5.3-20191730/ext/ereg/regex -I/usr/include/libxml2 -I/tmp/php5.3-20191730/ext/mbstring/oniguruma -I/tmp/php5.3-20191730/ext/mbstring/libmbfl -I/tmp/php5.3-20191730/ext/mbstring/libmbfl/mbfl -I/tmp/php5.3-20191730/TSRM -I/tmp/php5.3-20191730/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /tmp/php5.3-20191730/main/strlcat.c -o main/strlcat.lo /bin/sh /tmp/php5.3-20191730/libtool --silent --preserve-dup-deps --mode=compile gcc -Imain/ -I/tmp/php5.3-20191730/main/ -DPHP_ATOM_INC -I/tmp/php5.3-20191730/include -I/tmp/php5.3-20191730/main -I/tmp/php5.3-20191730 -I/tmp/php5.3-20191730/ext/date/lib -I/tmp/php5.3-20191730/ext/ereg/regex -I/usr/include/libxml2 -I/tmp/php5.3-20191730/ext/mbstring/oniguruma -I/tmp/php5.3-20191730/ext/mbstring/libmbfl -I/tmp/php5.3-20191730/ext/mbstring/libmbfl/mbfl -I/tmp/php5.3-20191730/TSRM -I/tmp/php5.3-20191730/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /tmp/php5.3-20191730/main/mergesort.c -o main/mergesort.lo /bin/sh /tmp/php5.3-20191730/libtool --silent --preserve-dup-deps --mode=compile gcc -Imain/ -I/tmp/php5.3-20191730/main/ -DPHP_ATOM_INC -I/tmp/php5.3-20191730/include -I/tmp/php5.3-20191730/main -I/tmp/php5.3-20191730 -I/tmp/php5.3-20191730/ext/date/lib -I/tmp/php5.3-20191730/ext/ereg/regex -I/usr/include/libxml2 -I/tmp/php5.3-20191730/ext/mbstring/oniguruma -I/tmp/php5.3-20191730/ext/mbstring/libmbfl -I/tmp/php5.3-20191730/ext/mbstring/libmbfl/mbfl -I/tmp/php5.3-20191730/TSRM -I/tmp/php5.3-20191730/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /tmp/php5.3-20191730/main/reentrancy.c -o main/reentrancy.lo /tmp/php5.3-20191730/main/reentrancy.c: In function 'php_ctime_r': /tmp/php5.3-20191730/main/reentrancy.c:63:2: error: too few arguments to function 'ctime_r' /usr/include/time.h:320:14: note: declared here /tmp/php5.3-20191730/main/reentrancy.c: In function 'php_asctime_r': /tmp/php5.3-20191730/main/reentrancy.c:70:2: error: too few arguments to function 'asctime_r' /usr/include/time.h:319:14: note: declared here *** Error code 1 make: Fatal error: Command failed for target `main/reentrancy.lo' -- Edit this bug report at https://bugs.php.net/bug.php?id=60342edit=1
