Bug #55819 [Asn]: segfault on mbstring tests
Edit report at https://bugs.php.net/bug.php?id=55819&edit=1 ID: 55819 Updated by: larue...@php.net Reported by:larue...@php.net Summary:segfault on mbstring tests Status: Assigned Type: Bug Package:mbstring related -PHP Version:5.4.0beta1 +PHP Version:5.3SVN-2011-09-30 (SVN) Assigned To:hirokawa Block user comment: N Private report: N New Comment: this segfault only exists in svn trunk now. Previous Comments: [2011-09-30 15:16:00] larue...@php.net hirokawa, plz look at this, thanks :) [2011-09-30 15:14:54] larue...@php.net The following patch has been added/updated: Patch Name: bug55819.diff Revision: 1317395694 URL: https://bugs.php.net/patch-display.php?bug=55819&patch=bug55819.diff&revision=1317395694 [2011-09-30 08:06:43] larue...@php.net Description: there are two segfault when run test of mbstring: Test mb_ereg_replace() function : usage variations [ext/mbstring/tests/mb_ereg_replace_variation2.phpt] Test mb_ereg_replace() function : usage variations [ext/mbstring/tests/mb_ereg_replace_variation3.phpt] Expected result: pass Actual result: -- segfault: #0 0x00653edc in _php_mb_regex_ereg_replace_exec (ht=4, return_value=0x2a95de6768, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, options=0, is_callable=0) at /home/huixc/opensource/php-src/trunk/ext/mbstring/php_mbregex.c:924 924 if ((replace_len - i) >= 2 && fwd == 1 && (gdb) bt #0 0x00653edc in _php_mb_regex_ereg_replace_exec (ht=4, return_value=0x2a95de6768, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, options=0, is_callable=0) at /home/huixc/opensource/php-src/trunk/ext/mbstring/php_mbregex.c:924 #1 0x0065531f in zif_mb_ereg_replace (ht=4, return_value=0x2a95de6768, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/huixc/opensource/php-src/trunk/ext/mbstring/php_mbregex.c:1031 #2 0x008d3de6 in zend_do_fcall_common_helper_SPEC (execute_data=0x2a95dac0e8) at /home/huixc/opensource/php- src/trunk/Zend/zend_vm_execute.h:642 #3 0x008da583 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x2a95dac0e8) at /home/huixc/opensource/php- src/trunk/Zend/zend_vm_execute.h:2215 #4 0x008d2aea in execute (op_array=0x2a95de03b0) at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410 #5 0x0089b19f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1271 #6 0x0081bb23 in php_execute_script (primary_file=0x7fb400) at /home/huixc/opensource/php-src/trunk/main/main.c:2391 #7 0x009bb061 in do_cli (argc=66, argv=0x7fb6e8) at /home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983 #8 0x009bbf02 in main (argc=66, argv=0x7fb6e8) at /home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356 -- Edit this bug report at https://bugs.php.net/bug.php?id=55819&edit=1
Bug #55826 [Opn->Ana]: Multiple PDORow's
Edit report at https://bugs.php.net/bug.php?id=55826&edit=1 ID: 55826 Updated by: johan...@php.net Reported by:grinyad at mail dot ru Summary:Multiple PDORow's -Status: Open +Status: Analyzed Type: Bug Package:PDO related Operating System: Windows XP PHP Version:5.3.8 Block user comment: N Private report: N New Comment: The issue here is that PDORow contains a pointer to the actual statement instance which is used to receive the data and is then shared over the PDOStatement instance and all PDORows created from there. Changing this is a large change wa can't do for 5.4, which is in beta. Given other issues in there (see recent bug about serialization) I tend to removing it in 5.5, but am not sure if it might bring notable benefits with some database drivers ... Previous Comments: [2011-09-30 22:52:32] grinyad at mail dot ru Description: You cant use multiple PDORow's at the same time. Test script: --- fetch(PDO::FETCH_LAZY); print_r($row); $row2 = $stmt->fetch(PDO::FETCH_LAZY); print_r($row); print_r($row2); ?> `$row` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 2 [Title] => Banned ) `$row` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 3 [Title] => Member ) `$row2` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 3 [Title] => Member ) `$row` and `$row2` are the same as last fetch result `$row2`.I mean that every PDORow Object will have the last fetch values. I think this is a bug. -- Edit this bug report at https://bugs.php.net/bug.php?id=55826&edit=1
[PHP-BUG] Bug #55826 [NEW]: Multiple PDORow's
From: Operating system: Windows XP PHP version: 5.3.8 Package: PDO related Bug Type: Bug Bug description:Multiple PDORow's Description: You cant use multiple PDORow's at the same time. Test script: --- fetch(PDO::FETCH_LAZY); print_r($row); $row2 = $stmt->fetch(PDO::FETCH_LAZY); print_r($row); print_r($row2); ?> `$row` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 2 [Title] => Banned ) `$row` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 3 [Title] => Member ) `$row2` => PDORow Object ( [queryString] => select acl.* from accesscontrollevel as acl [Id] => 3 [Title] => Member ) `$row` and `$row2` are the same as last fetch result `$row2`.I mean that every PDORow Object will have the last fetch values. I think this is a bug. -- Edit bug report at https://bugs.php.net/bug.php?id=55826&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55826&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55826&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55826&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55826&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55826&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55826&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55826&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55826&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55826&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55826&r=support Expected behavior: https://bugs.php.net/fix.php?id=55826&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55826&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55826&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55826&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55826&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55826&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55826&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55826&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55826&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55826&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55826&r=mysqlcfg
[PHP-BUG] Bug #55825 [NEW]: Missing initial value of static locals in trait methods
From: Operating system: Linux PHP version: 5.4SVN-2011-09-30 (snap) Package: *General Issues Bug Type: Bug Bug description:Missing initial value of static locals in trait methods Description: The initial value of static locals inside trait methods is being lost. Test script: --- inc(); $c1->inc(); Expected result: 1 2 Actual result: -- 1 -- Edit bug report at https://bugs.php.net/bug.php?id=55825&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55825&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55825&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55825&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55825&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55825&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55825&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55825&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55825&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55825&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55825&r=support Expected behavior: https://bugs.php.net/fix.php?id=55825&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55825&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55825&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55825&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55825&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55825&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55825&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55825&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55825&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55825&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55825&r=mysqlcfg
Req #19777 [Com]: We need mysql_fetch_all($mysql_result,[TYPE])
Edit report at https://bugs.php.net/bug.php?id=19777&edit=1
ID: 19777
Comment by: risto78 at gmail dot com
Reported by:bav at graphit dot ru
Summary:We need mysql_fetch_all($mysql_result,[TYPE])
Status: Wont fix
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: All
PHP Version:4CVS-2002-10-06
Block user comment: N
Private report: N
New Comment:
see http://php.net/manual/en/mysqli-result.fetch-all.php
Previous Comments:
[2011-09-30 20:29:52] risto78 at gmail dot com
the function overhead alone of calling this function in a loop several thousand
times should be enough to make a mysql_fetch_all function
[2010-12-19 06:49:58] hafizanil at hotmail dot com
Currently on 2010.Everything data fetch in json.If the mysql result can
directly push to json data.It much speedier then looping the data and
json_encode it again.
[2002-10-10 09:03:28] bav at graphit dot ru
Sorry, but I see an advantage. Only one - speed.
Yes, I know, I can write php function for fetching :)
We are not idiots :)
[2002-10-06 14:14:04] ge...@php.net
Looks like the only reason is, that you don't want to write an addidtional line
to fetch the rows in a loop.
Do you see any other benefits?!
I only see disadvantages... if you need such functionality, why don't write a
php-function for?! Personally I don't know any Database, which supports such
kind of functionality; who ever introduced such a function in pgsql must be
drunk :)
[2002-10-06 05:05:20] bav at graphit dot ru
So, please, we need an analog of pg_fetch_all for mysql...
for speed
Assume TYPE of fetching is MYSQL_ASSOC etc...
We want to avoid manual fetching like following:
$rt = mysql_query("select from...");
while($cur = mysql_fetch_assoc($rt))
$result[]=$cur;
--
Edit this bug report at https://bugs.php.net/bug.php?id=19777&edit=1
Req #19777 [Com]: We need mysql_fetch_all($mysql_result,[TYPE])
Edit report at https://bugs.php.net/bug.php?id=19777&edit=1
ID: 19777
Comment by: risto78 at gmail dot com
Reported by:bav at graphit dot ru
Summary:We need mysql_fetch_all($mysql_result,[TYPE])
Status: Wont fix
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: All
PHP Version:4CVS-2002-10-06
Block user comment: N
Private report: N
New Comment:
the function overhead alone of calling this function in a loop several thousand
times should be enough to make a mysql_fetch_all function
Previous Comments:
[2010-12-19 06:49:58] hafizanil at hotmail dot com
Currently on 2010.Everything data fetch in json.If the mysql result can
directly push to json data.It much speedier then looping the data and
json_encode it again.
[2002-10-10 09:03:28] bav at graphit dot ru
Sorry, but I see an advantage. Only one - speed.
Yes, I know, I can write php function for fetching :)
We are not idiots :)
[2002-10-06 14:14:04] ge...@php.net
Looks like the only reason is, that you don't want to write an addidtional line
to fetch the rows in a loop.
Do you see any other benefits?!
I only see disadvantages... if you need such functionality, why don't write a
php-function for?! Personally I don't know any Database, which supports such
kind of functionality; who ever introduced such a function in pgsql must be
drunk :)
[2002-10-06 05:05:20] bav at graphit dot ru
So, please, we need an analog of pg_fetch_all for mysql...
for speed
Assume TYPE of fetching is MYSQL_ASSOC etc...
We want to avoid manual fetching like following:
$rt = mysql_query("select from...");
while($cur = mysql_fetch_assoc($rt))
$result[]=$cur;
--
Edit this bug report at https://bugs.php.net/bug.php?id=19777&edit=1
Bug #55820 [Com]: php openssl csr parser ignores SANs
Edit report at https://bugs.php.net/bug.php?id=55820&edit=1 ID: 55820 Comment by: zedwoodnoreply at gmail dot com Reported by:zedwoodnoreply at gmail dot com Summary:php openssl csr parser ignores SANs Status: Analyzed Type: Bug Package:OpenSSL related Operating System: Ubuntu Linux 10.04 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Currently, openssl_x509_parse returns the x509v3 extensions, so it would be nice if there was some way to have an openssl_csr_parse that returns both the subject and the extensions and potentially other fields/extensions in the future. Right now the only thing we can extract from a CSR with php is the public key and subject. Thanks. Previous Comments: [2011-09-30 15:57:13] paj...@php.net hi, NID_subject_alt_name is not part of the subject name, as returned by the X509_REQ_get_subject_name. As you can see in your openssl command output, we do return the correct value: Subject: C=US, ST=Utah, L=Lindon, O=Z Widgets, CN=www.example.edu However I can see a need to fetch extensions (v3 or v2) and we may need to expose X509_get_ext_d2i (or equivalent. [2011-09-30 15:46:54] zedwoodnoreply at gmail dot com openssl req -in sans.csr -noout -text #output is Certificate Request: Data: Version: 0 (0x0) Subject: C=US, ST=Utah, L=Lindon, O=Z Widgets, CN=www.example.edu Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:d4:5d:10:5d:12:29:12:33:eb:54:7a:f1:9c:b6: 52:22:97:4e:06:34:f9:01:f6:c7:df:d0:18:53:c2: 7d:5c:91:7a:cc:4b:82:01:cc:ee:37:33:a7:85:47: a0:5f:c6:bd:6d:02:2f:16:71:d3:ec:42:8c:62:17: a1:41:cf:f0:37:3b:7c:dc:27:39:0b:77:c5:99:70: 5c:59:c7:ea:88:2a:88:b5:1d:8d:39:d9:82:9c:ab: 52:a3:86:69:d4:30:37:c0:80:f5:7d:d9:2a:75:a4: 79:1d:be:e0:23:45:ab:d8:74:18:ab:fb:b0:d4:d3: 45:ff:38:b5:d6:16:71:9a:1d:dc:99:a5:21:0f:d9: 12:95:c4:70:ba:40:b4:8f:a6:e6:47:dd:4b:5a:25: d2:e1:f8:e8:28:13:20:84:7a:a2:5c:b1:00:c3:88: 9d:e0:3b:1a:ce:89:92:f0:62:80:bd:b6:57:97:f0: 88:79:17:63:03:c1:1d:93:3d:fc:bb:7f:74:2d:ac: 81:ba:28:3d:b1:4b:3e:1c:7b:52:6f:89:95:53:66: fa:43:1c:44:e7:35:b8:a9:7f:45:64:ad:46:a9:32: 04:ab:db:bb:39:bd:e1:80:e0:89:4d:32:f2:72:2e: 65:a7:f5:36:3b:ad:d4:86:62:44:fc:a1:10:06:ba: e2:7f Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:test.example.com, DNS:other.example.com, DNS:www.example.net Signature Algorithm: sha1WithRSAEncryption ce:9c:7f:b2:c3:f0:ab:67:24:f6:82:dd:86:21:34:c8:86:49: e7:50:ea:5f:6d:9b:69:62:7b:b3:7f:1d:7d:7d:49:d6:26:34: f1:bb:11:62:1b:2f:fd:c6:92:26:fd:3a:c5:65:da:45:65:5c: e6:96:24:db:de:3d:5a:bb:01:f1:21:56:70:b6:ca:dc:0d:6d: 60:7d:b2:96:b6:54:2c:f6:ad:d3:1f:78:8c:8c:11:66:a3:db: 40:ee:c5:a4:db:76:30:01:b9:7e:97:10:96:f9:3e:fa:7d:97: a5:c7:d2:99:a4:16:09:fd:4e:36:6a:13:a1:ce:9c:14:a3:a0: 2b:2b:c5:c0:a9:b4:3c:f8:ba:c3:d6:6b:1a:a3:a4:9b:a2:57: 8f:88:ab:9b:07:05:60:56:58:37:cb:e7:78:bf:a3:a5:1f:d9: 81:84:46:7a:e1:38:e3:69:40:d5:3d:b0:7a:f7:8c:f6:ac:0c: 14:d9:50:e2:59:c7:85:b5:e4:c7:8f:f6:39:6e:ca:1a:96:1e: 75:eb:b4:f5:30:71:82:8f:4b:52:ad:dc:89:c1:db:ab:03:43: b0:73:bf:f9:03:68:05:74:dc:8e:86:29:f7:fc:5b:af:94:a2: 07:c5:9a:00:ae:b3:9a:52:c2:9f:1a:8a:a0:80:0e:da:26:3f: 9d:37:1d:df [2011-09-30 15:45:56] zedwoodnoreply at gmail dot com Description: The SANs (Subject Alternative Names) field of a CSR is totally ignored by the CSR parser openssl_csr_get_subject(); Test script: --- US [ST] => Utah [L] => Lindon [O] => Z Widgets [CN] => www.example.edu [SANS] => DNS:test.example.com, DNS:other.example.com, DNS:www.example.net ) Actual result: -- Array ( [C] => US [ST] => Utah [L] => Lindon [O] => Z Widgets [CN] => www.example.edu ) -- Edit this bug report at https://bugs.php.net/bug.php?id=55820&edit=1
[PHP-BUG] Bug #55824 [NEW]: Type Check / Hint
From: Operating system: GNU/Linux 2.6.32-5-686 PHP version: 5.4.0beta1 Package: Variables related Bug Type: Bug Bug description:Type Check / Hint Description: Refs: https://wiki.php.net/rfc/typechecking https://wiki.php.net/rfc/typecheckingparseronly Test script: --- --TEST-- --FILE-- --EXPECT-- string Expected result: string Actual result: -- Catchable fatal error: Argument 1 passed to test() must be an instance of string, string given, called in /root/php-5.4.0beta1/test01.php on line 6 and defined in /root/php-5.4.0beta1/test01.php on line 2 -- Edit bug report at https://bugs.php.net/bug.php?id=55824&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55824&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55824&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55824&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55824&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55824&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55824&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55824&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55824&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55824&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55824&r=support Expected behavior: https://bugs.php.net/fix.php?id=55824&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55824&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55824&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55824&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55824&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55824&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55824&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55824&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55824&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55824&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55824&r=mysqlcfg
[PHP-BUG] Req #55821 [NEW]: Provide readonly access to the meta data for the XML stream.
From:
Operating system: Irrelevant
PHP version: Irrelevant
Package: *XML functions
Bug Type: Feature/Change Request
Bug description:Provide readonly access to the meta data for the XML stream.
Description:
My start point is the SimpleXMLIterator, but I realise the the any
extension
based upon libxml would have the same issue.
When you are reading a XML stream, file or string, there is no mechanism
available to access the position within the XML unless you implement a 2
pass
mechanism to count the nodes in the first pass and then record your
position in
the second pass.
Using the count() method is available in some of the XML classes, but this
is
still a 2 pass system.
My feature would be to have a mechanism to be able to read the start and
end
position of the element as well as knowing the total size of the file. So
the
progress through the file is still possible (and displayed as a %age rather
than
as an "n of m").
>From what I can see, this is not a minor amount of work. Especially as I
can do
something like ...
$it = new
SimpleXMLIterator('compress.zlib://http://www.site.com/file.xml.gz');
In this instance, there are 2 filelengths. The .gz file from the site as
well as
the streamed/expanded XML file.
Realistically, only the expanded XML file value would be useful in my use
case.
It may be that any/all stream/filters/etc that interact with the data would
need
to be able to report their data.
--
Edit bug report at https://bugs.php.net/bug.php?id=55821&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55821&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55821&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55821&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55821&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55821&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55821&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55821&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55821&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55821&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55821&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55821&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55821&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55821&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55821&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55821&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55821&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55821&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55821&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55821&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55821&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55821&r=mysqlcfg
Bug #55801 [Fbk]: Behavior of unserialize has changed
Edit report at https://bugs.php.net/bug.php?id=55801&edit=1
ID: 55801
Updated by: johan...@php.net
Reported by:mapi at pdepend dot org
Summary:Behavior of unserialize has changed
Status: Feedback
Type: Bug
Package:Variables related
Operating System: Linux (Fedora 15)
PHP Version:5.4.0beta1
Block user comment: N
Private report: N
New Comment:
Can you try reverting SVN revision r299770 and then run your test? - That's
mostly a guess, though.
bug #36424
http://svn.php.net/viewvc/?view=revision&revision=299770
Previous Comments:
[2011-09-28 16:29:50] mapi at pdepend dot org
It seems that this has something todo with the visibility of properties that
should be serialized. If I do the following:
~ $ rm -rf ~/.pdepend
~ $ git clone https://github.com/pdepend/pdepend.git
~ $ cd pdepend
~ $ vim src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php +86
-> Change from PROTECTED to PUBLIC
protected $parentClassReference = null; -> public $parentClassReference
=
null;
~ $ vim src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php +132
-> Change from PROTECTED to PUBLIC
protected $nodes = array(); -> public $nodes = array();
~ $ php540 src/bin/pdepend.php --summary-xml=sum.xml
src/main/php/PHP/Depend/Code/ASTArrayType.php
~ $ php540 src/bin/pdepend.php --summary-xml=sum.xml
src/main/php/PHP/Depend/Code/ASTArrayType.php
...
Executing CyclomaticComplexity-Analyzer:
Fatal error: Call to a member function findChildrenOfType() on a non-object in
/tmp/pdepend/src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php on line
268
If I now revert the visibility of both properties from PUBLIC to PROTECTED, it
works:
~ $ vim src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php +86
-> Change from PUBLIC to PROTECTED
public $parentClassReference = null; -> protected $parentClassReference
=
null;
~ $ vim src/main/php/PHP/Depend/Code/AbstractClassOrInterface.php +132
-> Change from PUBLIC to PROTECTED
public $nodes = array(); -> protected $nodes = array();
~ $ php540 src/bin/pdepend.php --summary-xml=sum.xml
src/main/php/PHP/Depend/Code/ASTArrayType.php
This means that a PUBLIC property that was serialized can be restored in a
PROTECTED property while unserializing the object structure.
[2011-09-28 15:20:33] mapi at pdepend dot org
Yes, here you can get the two serialized object structures:
http://manuel-pichler.de/stuff/5.3.ser
http://manuel-pichler.de/stuff/5.4.ser
And there is the difference:
5.3 -> *nodes";a:1:{i:0;r:18;}
5.4 -> *nodes";a:1:{i:0;r:36;}
It references something different.
[2011-09-28 13:41:54] paj...@php.net
Any chance to get something that shows us the serialized data with 5.4 and 5.4
so
we can see how they differ?
Maybe upload the small possible code somewhere?
[2011-09-28 13:30:46] mapi at pdepend dot org
Okay, I tried for several hours to create a reproducable outside of
PHP_Depend's
context, but I cannot reproduce this behavior :(
But at least I came up with a small code fragement that illustrates this
behavior:
prop[$y]++;
}
}
which was translated into the following object graph:
Statement
Expression
MemberPrimaryPrefix <--
Variable |
PropertyPostfix |
ArrayIndexExpression [Same Instance]
Identifier |
Variable |
PostfixExpression |
MemberPrimaryPrefix --
Variable
PropertyPostfix
ArrayIndexExpression
Identifier
Variable
And this second reference to MemberPrimaryPrefix is NULL after unserialization
with PHP 5.4 and it is just a second clone with PHP < 5.4
[2011-09-28 08:56:52] mapi at pdepend dot org
I will try to create a reproducable.
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=55801
--
Edit this bug report at https://bugs.php.net/bug.php?id=55801&edit=1
Req #36424 [Csd]: Keeping reference info through recursive calls to serialize()
Edit report at https://bugs.php.net/bug.php?id=36424&edit=1
ID: 36424
Updated by: johan...@php.net
Reported by:mastabog at hotmail dot com
Summary:Keeping reference info through recursive calls to
serialize()
Status: Closed
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: *
PHP Version:5.3.8
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
mastabog, no this can't go in 5.3 it changes internal structures and APIs which
we can't change in bug fix releases without breaking API compatibility which we
guarantee.
Previous Comments:
[2011-09-30 15:01:26] mastabog at hotmail dot com
Wow! More than 5 and a half years since I discovered, reproduced and submitted
this bug ...
To mike:
Why wait until 5.4? There are many web hosting providers that will delay the
update to 5.4 for years but will instantly update to the next 5.3.x release.
Most providers only just updated from 5.2 to 5.3 (i.e. this or last month) even
though 5.3 has been out since 2009.
Couldn't you apply the patch to the next 5.3.x release instead?
[2011-09-30 06:49:55] m...@php.net
The patch is contained in upcoming PHP-5.4
[2010-12-10 12:40:13] peter at desk dot nl
I've just been bitten by this bug (in php 5.3.3), cost me half a day to figure
it out... it's highly annoying because I can't go back to using __sleep and
__wakeup without much rewriting, and while working around it is feasible, it's
pretty hacky in my situation.
what has happened to the patch mentioned in may ? was it ever committed ?
[2010-05-26 09:24:41] m...@php.net
Automatic comment from SVN on behalf of mike
Revision: http://svn.php.net/viewvc/?view=revision&revision=299770
Log: Added support for object references in recursive serialize() calls. FR
#36424
[2010-05-21 13:08:07] mastabog at hotmail dot com
I still don't understand why this is not seen as a bug. My example shows that
without "implements Serializable" object references are honoured (as expected)
while with "implements Serializable" object references are broken (which is
unexpected).
Seeing you classified this as "feature request" makes me think that breaking
object references was actually intended behaviour or that there is a way to
maintain object references when implementing Serializable. Can you then please
provide the body of the serialize() and unserialize() methods in class A in the
example below that will maintain object references as expected, i.e. $new_oC->A
=== $new_oC->B->A?
class A implements Serializable
{
public function serialize ()
{
[...]
}
function unserialize($serialized)
{
[...]
}
}
class B extends A
{
public $A;
}
class C extends A
{
public $A;
public $B;
}
$oC = new C();
$oC->A = new A();
$oC->B = new B();
$oC->B->A = $oC->A;
echo $oC->A === $oC->B->A ? "yes" : "no", "\n";
$ser = serialize($oC);
$new_oC = unserialize($ser);
echo $new_oC->A === $new_oC->B->A ? "yes" : "no", "\n";
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=36424
--
Edit this bug report at https://bugs.php.net/bug.php?id=36424&edit=1
Bug #55820 [Opn->Ana]: php openssl csr parser ignores SANs
Edit report at https://bugs.php.net/bug.php?id=55820&edit=1 ID: 55820 Updated by: paj...@php.net Reported by:zedwoodnoreply at gmail dot com Summary:php openssl csr parser ignores SANs -Status: Open +Status: Analyzed Type: Bug Package:OpenSSL related Operating System: Ubuntu Linux 10.04 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: hi, NID_subject_alt_name is not part of the subject name, as returned by the X509_REQ_get_subject_name. As you can see in your openssl command output, we do return the correct value: Subject: C=US, ST=Utah, L=Lindon, O=Z Widgets, CN=www.example.edu However I can see a need to fetch extensions (v3 or v2) and we may need to expose X509_get_ext_d2i (or equivalent. Previous Comments: [2011-09-30 15:46:54] zedwoodnoreply at gmail dot com openssl req -in sans.csr -noout -text #output is Certificate Request: Data: Version: 0 (0x0) Subject: C=US, ST=Utah, L=Lindon, O=Z Widgets, CN=www.example.edu Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:d4:5d:10:5d:12:29:12:33:eb:54:7a:f1:9c:b6: 52:22:97:4e:06:34:f9:01:f6:c7:df:d0:18:53:c2: 7d:5c:91:7a:cc:4b:82:01:cc:ee:37:33:a7:85:47: a0:5f:c6:bd:6d:02:2f:16:71:d3:ec:42:8c:62:17: a1:41:cf:f0:37:3b:7c:dc:27:39:0b:77:c5:99:70: 5c:59:c7:ea:88:2a:88:b5:1d:8d:39:d9:82:9c:ab: 52:a3:86:69:d4:30:37:c0:80:f5:7d:d9:2a:75:a4: 79:1d:be:e0:23:45:ab:d8:74:18:ab:fb:b0:d4:d3: 45:ff:38:b5:d6:16:71:9a:1d:dc:99:a5:21:0f:d9: 12:95:c4:70:ba:40:b4:8f:a6:e6:47:dd:4b:5a:25: d2:e1:f8:e8:28:13:20:84:7a:a2:5c:b1:00:c3:88: 9d:e0:3b:1a:ce:89:92:f0:62:80:bd:b6:57:97:f0: 88:79:17:63:03:c1:1d:93:3d:fc:bb:7f:74:2d:ac: 81:ba:28:3d:b1:4b:3e:1c:7b:52:6f:89:95:53:66: fa:43:1c:44:e7:35:b8:a9:7f:45:64:ad:46:a9:32: 04:ab:db:bb:39:bd:e1:80:e0:89:4d:32:f2:72:2e: 65:a7:f5:36:3b:ad:d4:86:62:44:fc:a1:10:06:ba: e2:7f Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:test.example.com, DNS:other.example.com, DNS:www.example.net Signature Algorithm: sha1WithRSAEncryption ce:9c:7f:b2:c3:f0:ab:67:24:f6:82:dd:86:21:34:c8:86:49: e7:50:ea:5f:6d:9b:69:62:7b:b3:7f:1d:7d:7d:49:d6:26:34: f1:bb:11:62:1b:2f:fd:c6:92:26:fd:3a:c5:65:da:45:65:5c: e6:96:24:db:de:3d:5a:bb:01:f1:21:56:70:b6:ca:dc:0d:6d: 60:7d:b2:96:b6:54:2c:f6:ad:d3:1f:78:8c:8c:11:66:a3:db: 40:ee:c5:a4:db:76:30:01:b9:7e:97:10:96:f9:3e:fa:7d:97: a5:c7:d2:99:a4:16:09:fd:4e:36:6a:13:a1:ce:9c:14:a3:a0: 2b:2b:c5:c0:a9:b4:3c:f8:ba:c3:d6:6b:1a:a3:a4:9b:a2:57: 8f:88:ab:9b:07:05:60:56:58:37:cb:e7:78:bf:a3:a5:1f:d9: 81:84:46:7a:e1:38:e3:69:40:d5:3d:b0:7a:f7:8c:f6:ac:0c: 14:d9:50:e2:59:c7:85:b5:e4:c7:8f:f6:39:6e:ca:1a:96:1e: 75:eb:b4:f5:30:71:82:8f:4b:52:ad:dc:89:c1:db:ab:03:43: b0:73:bf:f9:03:68:05:74:dc:8e:86:29:f7:fc:5b:af:94:a2: 07:c5:9a:00:ae:b3:9a:52:c2:9f:1a:8a:a0:80:0e:da:26:3f: 9d:37:1d:df [2011-09-30 15:45:56] zedwoodnoreply at gmail dot com Description: The SANs (Subject Alternative Names) field of a CSR is totally ignored by the CSR parser openssl_csr_get_subject(); Test script: --- US [ST] => Utah [L] => Lindon [O] => Z Widgets [CN] => www.example.edu [SANS] => DNS:test.example.com, DNS:other.example.com, DNS:www.example.net ) Actual result: -- Array ( [C] => US [ST] => Utah [L] => Lindon [O] => Z Widgets [CN] => www.example.edu ) -- Edit this bug report at https://bugs.php.net/bug.php?id=55820&edit=1
Bug #55820 [Com]: php openssl csr parser ignores SANs
Edit report at https://bugs.php.net/bug.php?id=55820&edit=1 ID: 55820 Comment by: zedwoodnoreply at gmail dot com Reported by:zedwoodnoreply at gmail dot com Summary:php openssl csr parser ignores SANs Status: Open Type: Bug Package:OpenSSL related Operating System: Ubuntu Linux 10.04 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: openssl req -in sans.csr -noout -text #output is Certificate Request: Data: Version: 0 (0x0) Subject: C=US, ST=Utah, L=Lindon, O=Z Widgets, CN=www.example.edu Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:d4:5d:10:5d:12:29:12:33:eb:54:7a:f1:9c:b6: 52:22:97:4e:06:34:f9:01:f6:c7:df:d0:18:53:c2: 7d:5c:91:7a:cc:4b:82:01:cc:ee:37:33:a7:85:47: a0:5f:c6:bd:6d:02:2f:16:71:d3:ec:42:8c:62:17: a1:41:cf:f0:37:3b:7c:dc:27:39:0b:77:c5:99:70: 5c:59:c7:ea:88:2a:88:b5:1d:8d:39:d9:82:9c:ab: 52:a3:86:69:d4:30:37:c0:80:f5:7d:d9:2a:75:a4: 79:1d:be:e0:23:45:ab:d8:74:18:ab:fb:b0:d4:d3: 45:ff:38:b5:d6:16:71:9a:1d:dc:99:a5:21:0f:d9: 12:95:c4:70:ba:40:b4:8f:a6:e6:47:dd:4b:5a:25: d2:e1:f8:e8:28:13:20:84:7a:a2:5c:b1:00:c3:88: 9d:e0:3b:1a:ce:89:92:f0:62:80:bd:b6:57:97:f0: 88:79:17:63:03:c1:1d:93:3d:fc:bb:7f:74:2d:ac: 81:ba:28:3d:b1:4b:3e:1c:7b:52:6f:89:95:53:66: fa:43:1c:44:e7:35:b8:a9:7f:45:64:ad:46:a9:32: 04:ab:db:bb:39:bd:e1:80:e0:89:4d:32:f2:72:2e: 65:a7:f5:36:3b:ad:d4:86:62:44:fc:a1:10:06:ba: e2:7f Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:test.example.com, DNS:other.example.com, DNS:www.example.net Signature Algorithm: sha1WithRSAEncryption ce:9c:7f:b2:c3:f0:ab:67:24:f6:82:dd:86:21:34:c8:86:49: e7:50:ea:5f:6d:9b:69:62:7b:b3:7f:1d:7d:7d:49:d6:26:34: f1:bb:11:62:1b:2f:fd:c6:92:26:fd:3a:c5:65:da:45:65:5c: e6:96:24:db:de:3d:5a:bb:01:f1:21:56:70:b6:ca:dc:0d:6d: 60:7d:b2:96:b6:54:2c:f6:ad:d3:1f:78:8c:8c:11:66:a3:db: 40:ee:c5:a4:db:76:30:01:b9:7e:97:10:96:f9:3e:fa:7d:97: a5:c7:d2:99:a4:16:09:fd:4e:36:6a:13:a1:ce:9c:14:a3:a0: 2b:2b:c5:c0:a9:b4:3c:f8:ba:c3:d6:6b:1a:a3:a4:9b:a2:57: 8f:88:ab:9b:07:05:60:56:58:37:cb:e7:78:bf:a3:a5:1f:d9: 81:84:46:7a:e1:38:e3:69:40:d5:3d:b0:7a:f7:8c:f6:ac:0c: 14:d9:50:e2:59:c7:85:b5:e4:c7:8f:f6:39:6e:ca:1a:96:1e: 75:eb:b4:f5:30:71:82:8f:4b:52:ad:dc:89:c1:db:ab:03:43: b0:73:bf:f9:03:68:05:74:dc:8e:86:29:f7:fc:5b:af:94:a2: 07:c5:9a:00:ae:b3:9a:52:c2:9f:1a:8a:a0:80:0e:da:26:3f: 9d:37:1d:df Previous Comments: [2011-09-30 15:45:56] zedwoodnoreply at gmail dot com Description: The SANs (Subject Alternative Names) field of a CSR is totally ignored by the CSR parser openssl_csr_get_subject(); Test script: --- US [ST] => Utah [L] => Lindon [O] => Z Widgets [CN] => www.example.edu [SANS] => DNS:test.example.com, DNS:other.example.com, DNS:www.example.net ) Actual result: -- Array ( [C] => US [ST] => Utah [L] => Lindon [O] => Z Widgets [CN] => www.example.edu ) -- Edit this bug report at https://bugs.php.net/bug.php?id=55820&edit=1
[PHP-BUG] Bug #55820 [NEW]: php openssl csr parser ignores SANs
From: Operating system: Ubuntu Linux 10.04 PHP version: 5.3.8 Package: OpenSSL related Bug Type: Bug Bug description:php openssl csr parser ignores SANs Description: The SANs (Subject Alternative Names) field of a CSR is totally ignored by the CSR parser openssl_csr_get_subject(); Test script: --- US [ST] => Utah [L] => Lindon [O] => Z Widgets [CN] => www.example.edu [SANS] => DNS:test.example.com, DNS:other.example.com, DNS:www.example.net ) Actual result: -- Array ( [C] => US [ST] => Utah [L] => Lindon [O] => Z Widgets [CN] => www.example.edu ) -- Edit bug report at https://bugs.php.net/bug.php?id=55820&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55820&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55820&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55820&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55820&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55820&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55820&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55820&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55820&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55820&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55820&r=support Expected behavior: https://bugs.php.net/fix.php?id=55820&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55820&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55820&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55820&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55820&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55820&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55820&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55820&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55820&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55820&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55820&r=mysqlcfg
Req #36424 [Csd]: Keeping reference info through recursive calls to serialize()
Edit report at https://bugs.php.net/bug.php?id=36424&edit=1
ID: 36424
User updated by:mastabog at hotmail dot com
Reported by:mastabog at hotmail dot com
Summary:Keeping reference info through recursive calls to
serialize()
Status: Closed
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: *
-PHP Version:5.2.14-dev
+PHP Version:5.3.8
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
Wow! More than 5 and a half years since I discovered, reproduced and submitted
this bug ...
To mike:
Why wait until 5.4? There are many web hosting providers that will delay the
update to 5.4 for years but will instantly update to the next 5.3.x release.
Most providers only just updated from 5.2 to 5.3 (i.e. this or last month) even
though 5.3 has been out since 2009.
Couldn't you apply the patch to the next 5.3.x release instead?
Previous Comments:
[2011-09-30 06:49:55] m...@php.net
The patch is contained in upcoming PHP-5.4
[2010-12-10 12:40:13] peter at desk dot nl
I've just been bitten by this bug (in php 5.3.3), cost me half a day to figure
it out... it's highly annoying because I can't go back to using __sleep and
__wakeup without much rewriting, and while working around it is feasible, it's
pretty hacky in my situation.
what has happened to the patch mentioned in may ? was it ever committed ?
[2010-05-26 09:24:41] m...@php.net
Automatic comment from SVN on behalf of mike
Revision: http://svn.php.net/viewvc/?view=revision&revision=299770
Log: Added support for object references in recursive serialize() calls. FR
#36424
[2010-05-21 13:08:07] mastabog at hotmail dot com
I still don't understand why this is not seen as a bug. My example shows that
without "implements Serializable" object references are honoured (as expected)
while with "implements Serializable" object references are broken (which is
unexpected).
Seeing you classified this as "feature request" makes me think that breaking
object references was actually intended behaviour or that there is a way to
maintain object references when implementing Serializable. Can you then please
provide the body of the serialize() and unserialize() methods in class A in the
example below that will maintain object references as expected, i.e. $new_oC->A
=== $new_oC->B->A?
class A implements Serializable
{
public function serialize ()
{
[...]
}
function unserialize($serialized)
{
[...]
}
}
class B extends A
{
public $A;
}
class C extends A
{
public $A;
public $B;
}
$oC = new C();
$oC->A = new A();
$oC->B = new B();
$oC->B->A = $oC->A;
echo $oC->A === $oC->B->A ? "yes" : "no", "\n";
$ser = serialize($oC);
$new_oC = unserialize($ser);
echo $new_oC->A === $new_oC->B->A ? "yes" : "no", "\n";
[2010-05-21 11:19:54] m...@php.net
Reclassified as Change Request.
JFYI: http://news.php.net/php.internals/48369
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=36424
--
Edit this bug report at https://bugs.php.net/bug.php?id=36424&edit=1
Bug #55819 [PATCH]: segfault on mbstring tests
Edit report at https://bugs.php.net/bug.php?id=55819&edit=1 ID: 55819 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:segfault on mbstring tests Status: Open Type: Bug Package:mbstring related PHP Version:5.3.8 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug55819.diff Revision: 1317395694 URL: https://bugs.php.net/patch-display.php?bug=55819&patch=bug55819.diff&revision=1317395694 Previous Comments: [2011-09-30 08:06:43] larue...@php.net Description: there are two segfault when run test of mbstring: Test mb_ereg_replace() function : usage variations [ext/mbstring/tests/mb_ereg_replace_variation2.phpt] Test mb_ereg_replace() function : usage variations [ext/mbstring/tests/mb_ereg_replace_variation3.phpt] Expected result: pass Actual result: -- segfault: #0 0x00653edc in _php_mb_regex_ereg_replace_exec (ht=4, return_value=0x2a95de6768, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, options=0, is_callable=0) at /home/huixc/opensource/php-src/trunk/ext/mbstring/php_mbregex.c:924 924 if ((replace_len - i) >= 2 && fwd == 1 && (gdb) bt #0 0x00653edc in _php_mb_regex_ereg_replace_exec (ht=4, return_value=0x2a95de6768, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, options=0, is_callable=0) at /home/huixc/opensource/php-src/trunk/ext/mbstring/php_mbregex.c:924 #1 0x0065531f in zif_mb_ereg_replace (ht=4, return_value=0x2a95de6768, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/huixc/opensource/php-src/trunk/ext/mbstring/php_mbregex.c:1031 #2 0x008d3de6 in zend_do_fcall_common_helper_SPEC (execute_data=0x2a95dac0e8) at /home/huixc/opensource/php- src/trunk/Zend/zend_vm_execute.h:642 #3 0x008da583 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x2a95dac0e8) at /home/huixc/opensource/php- src/trunk/Zend/zend_vm_execute.h:2215 #4 0x008d2aea in execute (op_array=0x2a95de03b0) at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410 #5 0x0089b19f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1271 #6 0x0081bb23 in php_execute_script (primary_file=0x7fb400) at /home/huixc/opensource/php-src/trunk/main/main.c:2391 #7 0x009bb061 in do_cli (argc=66, argv=0x7fb6e8) at /home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983 #8 0x009bbf02 in main (argc=66, argv=0x7fb6e8) at /home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356 -- Edit this bug report at https://bugs.php.net/bug.php?id=55819&edit=1
Bug #55819 [Opn]: segfault on mbstring tests
Edit report at https://bugs.php.net/bug.php?id=55819&edit=1 ID: 55819 Updated by: larue...@php.net Reported by:larue...@php.net Summary:segfault on mbstring tests Status: Open Type: Bug Package:mbstring related -PHP Version:5.3.8 +PHP Version:5.4.0beta1 -Assigned To: +Assigned To:hirokawa Block user comment: N Private report: N New Comment: hirokawa, plz look at this, thanks :) Previous Comments: [2011-09-30 15:14:54] larue...@php.net The following patch has been added/updated: Patch Name: bug55819.diff Revision: 1317395694 URL: https://bugs.php.net/patch-display.php?bug=55819&patch=bug55819.diff&revision=1317395694 [2011-09-30 08:06:43] larue...@php.net Description: there are two segfault when run test of mbstring: Test mb_ereg_replace() function : usage variations [ext/mbstring/tests/mb_ereg_replace_variation2.phpt] Test mb_ereg_replace() function : usage variations [ext/mbstring/tests/mb_ereg_replace_variation3.phpt] Expected result: pass Actual result: -- segfault: #0 0x00653edc in _php_mb_regex_ereg_replace_exec (ht=4, return_value=0x2a95de6768, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, options=0, is_callable=0) at /home/huixc/opensource/php-src/trunk/ext/mbstring/php_mbregex.c:924 924 if ((replace_len - i) >= 2 && fwd == 1 && (gdb) bt #0 0x00653edc in _php_mb_regex_ereg_replace_exec (ht=4, return_value=0x2a95de6768, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1, options=0, is_callable=0) at /home/huixc/opensource/php-src/trunk/ext/mbstring/php_mbregex.c:924 #1 0x0065531f in zif_mb_ereg_replace (ht=4, return_value=0x2a95de6768, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/huixc/opensource/php-src/trunk/ext/mbstring/php_mbregex.c:1031 #2 0x008d3de6 in zend_do_fcall_common_helper_SPEC (execute_data=0x2a95dac0e8) at /home/huixc/opensource/php- src/trunk/Zend/zend_vm_execute.h:642 #3 0x008da583 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x2a95dac0e8) at /home/huixc/opensource/php- src/trunk/Zend/zend_vm_execute.h:2215 #4 0x008d2aea in execute (op_array=0x2a95de03b0) at /home/huixc/opensource/php-src/trunk/Zend/zend_vm_execute.h:410 #5 0x0089b19f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/huixc/opensource/php-src/trunk/Zend/zend.c:1271 #6 0x0081bb23 in php_execute_script (primary_file=0x7fb400) at /home/huixc/opensource/php-src/trunk/main/main.c:2391 #7 0x009bb061 in do_cli (argc=66, argv=0x7fb6e8) at /home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:983 #8 0x009bbf02 in main (argc=66, argv=0x7fb6e8) at /home/huixc/opensource/php-src/trunk/sapi/cli/php_cli.c:1356 -- Edit this bug report at https://bugs.php.net/bug.php?id=55819&edit=1
Bug #16263 [Com]: session.start() create new empty session file and not resume existing session
Edit report at https://bugs.php.net/bug.php?id=16263&edit=1
ID: 16263
Comment by: webmaster33 at gmail dot com
Reported by:kur at natur dot cuni dot cz
Summary:session.start() create new empty session file and
not resume existing session
Status: No Feedback
Type: Bug
Package:Session related
Operating System: ANY
PHP Version:4.3.0-dev
Block user comment: N
Private report: N
New Comment:
I have the same problem.
System:
Linux 2.6.26-2-686 #1 SMP Sat Jun 11 14:54:10 UTC 2011 i686
PHP 5.3.3-7+squeeze1 with Suhosin-Patch (cli) (built: Mar 18 2011 17:22:52)
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
Problem:
One PHP script creates a session (474 bytes), which I want to read with another
PHP script.
The second script starts like this:
\n" );
var_dump($_SESSION, "\n");
...
The problem is, that when I start second script, the 474 bytes of the session
is emptied to 0 bytes.
The the domain of first and second script are different, but they are on the
same virtual hosted server, and they use the same session path: /var/lib/php5
/etc/php5/apache2/php.ini session settings are:
[Session]
session.save_handler = files
session.save_path = /var/lib/php5
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.serialize_handler = php
session.gc_divisor = 100
session.gc_maxlifetime = 1440
session.bug_compat_42 = 1
session.bug_compat_warn = 1
session.referer_check =
session.entropy_length = 0
session.entropy_file =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.hash_function = 0
session.hash_bits_per_character = 4
Any ideas?
Previous Comments:
[2011-08-16 13:02:02] phpbugs at aron dot ws
If you run out of space you get the same effect :D
[2010-09-23 22:21:55] sartorato at gmail dot com
Hi there,
I was having the same problem with PHP creating session files with 0Kb.
I solved putting the on the first line of the php file.
After this it works like a charm.
Hope it helps somebody.
Ricardo Sartorato
[2009-12-16 20:07:04] sven dot holcombe at gmail dot com
Running on default XAMPP installation, with the
session.save_path = "C:\xampplite\tmp"
When I set the apache document root to be:
And then run a file with contents:
There is a session file created. Ie, normal operation.
When I set the apache document root to be:
And then run THE SAME file with contents:
A 0KB session file is created. Ie, it is empty, and I cannot access session
variables.
Please help.
[2009-12-02 18:57:14] john at 5070 dot info
The same issue.
# php-cgi -v
PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cgi-fcgi) (built: Apr 26 2009
22:11:16)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by
eAccelerator
with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend
Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies
System call trace (in fact, this is processed by mod_php of the same version):
open(".../sess_a6549.", O_RDWR|O_CREAT|O_LARGEFILE, 0600) = 1035
fstat64(1035, {st_mode=S_IFREG|0600, st_size=96, ...}) = 0
flock(1035, LOCK_EX)= 0
fcntl64(1035, F_SETFD, FD_CLOEXEC) = 0
fstat64(1035, {st_mode=S_IFREG|0600, st_size=96, ...}) = 0
_llseek(1035, 0, [0], SEEK_SET) = 0
read(1035, "Acess|s:1:\"1\";id|s:3:\"108\";login|"..., 96) = 96
...
ftruncate64(1035, 0)= 0
_llseek(1035, 0, [0], SEEK_SET) = 0
write(1035, ""..., 0) = 0
close(1035) = 0
Session files are shared via NFSv4, if it is important.
[2009-08-26 18:00:41] chris dot kerrison at farrendale dot co dot uk
Hello, I have theis session problem, tried everything on this page not still
wont work. Is anyone else having the problem still??
I have 2 servers, one it works fine on and the other it fails, they use the
same settings, and have tried differant versions, yet it still fails on the 2nd
server.
Ho many people here are running it on a server with a " _ " in the computer
name? that to me seems the only thing differant between the computers with my
setup
Req #55807 [Asn->Csd]: Wrong value for splFileObject::SKIP_EMPTY
Edit report at https://bugs.php.net/bug.php?id=55807&edit=1
ID: 55807
Updated by: bj...@php.net
Reported by:jgotti at modedemploi dot fr
Summary:Wrong value for splFileObject::SKIP_EMPTY
-Status: Assigned
+Status: Closed
Type: Feature/Change Request
Package:SPL related
Operating System: linux
PHP Version:5.3.8
Assigned To:colder
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-09-30 14:17:20] bj...@php.net
Heh. Excellent point :)
[2011-09-30 14:17:02] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=317501
Log: Fixed bug #55807 (Wrong value for splFileObject::SKIP_EMPTY)
[2011-09-28 15:21:05] jgotti at modedemploi dot fr
Description:
isn't this weird that splFileObject::SKIP_EMPTY=6.
I think this should be 4 and not 6 as setting splFileObject flag to SKIP_EMPTY
will report flag splFileObject::READ_AHEAD to be set even if not intended to be
set
Test script:
---
$fileObj = new SplFileObject('/tmp/test.txt');
$fileObj->setFlags(SplFileObject::SKIP_EMPTY);
if( $fileObj->getFlags() & SplFileObject::READ_AHEAD ){//<-- should not pass
here we didn't set READ_AHEAD flag
echo "READ_AHEAD on";
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=55807&edit=1
Req #55807 [Asn]: Wrong value for splFileObject::SKIP_EMPTY
Edit report at https://bugs.php.net/bug.php?id=55807&edit=1
ID: 55807
Updated by: bj...@php.net
Reported by:jgotti at modedemploi dot fr
Summary:Wrong value for splFileObject::SKIP_EMPTY
Status: Assigned
Type: Feature/Change Request
Package:SPL related
Operating System: linux
PHP Version:5.3.8
Assigned To:colder
Block user comment: N
Private report: N
New Comment:
Heh. Excellent point :)
Previous Comments:
[2011-09-30 14:17:02] bj...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revision&revision=317501
Log: Fixed bug #55807 (Wrong value for splFileObject::SKIP_EMPTY)
[2011-09-28 15:21:05] jgotti at modedemploi dot fr
Description:
isn't this weird that splFileObject::SKIP_EMPTY=6.
I think this should be 4 and not 6 as setting splFileObject flag to SKIP_EMPTY
will report flag splFileObject::READ_AHEAD to be set even if not intended to be
set
Test script:
---
$fileObj = new SplFileObject('/tmp/test.txt');
$fileObj->setFlags(SplFileObject::SKIP_EMPTY);
if( $fileObj->getFlags() & SplFileObject::READ_AHEAD ){//<-- should not pass
here we didn't set READ_AHEAD flag
echo "READ_AHEAD on";
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=55807&edit=1
Bug #55818 [Opn->Bgs]: Memcached::getByKey returns false when cas requested
Edit report at https://bugs.php.net/bug.php?id=55818&edit=1
ID: 55818
Updated by: paj...@php.net
Reported by:nikrush at gmail dot com
Summary:Memcached::getByKey returns false when cas requested
-Status: Open
+Status: Bogus
Type: Bug
Package:Unknown/Other Function
Operating System: Debian 6
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Please report it at http://pecl.php.net/memcached
Previous Comments:
[2011-09-30 07:45:23] nikrush at gmail dot com
Description:
---
>From manual page: http://www.php.net/memcached.getbykey#refsect1-
memcached.getbykey-returnvalues
---
Memcached::getByKey returns false when cas requested.
Test script:
---
$mc = new Memcached('MEMCACHED_SERVER_ID');
$mc->addServer('localhost', 11211);
var_dump(
$mc->setByKey('server', 'key', 'set_value'),
$mc->getResultMessage(),
$mc->getResultCode(),
'---',
$mc->getByKey('server', 'key', null, $cas),
$mc->getResultMessage(),
$mc->getResultCode(),
$cas,
'---',
$mc->getByKey('server', 'key'),
$mc->getResultMessage(),
$mc->getResultCode()
);
Expected result:
bool(true)
string(7) "SUCCESS"
int(0)
string(35) "---"
string(9) "set_value"
string(7) "SUCCESS"
int(0)
float(17086)
string(35) "---"
string(9) "set_value"
string(7) "SUCCESS"
int(0)
Actual result:
--
bool(true)
string(7) "SUCCESS"
int(0)
string(35) "---"
bool(false)
string(7) "SUCCESS"
int(0)
float(17086)
string(35) "---"
string(9) "set_value"
string(7) "SUCCESS"
int(0)
--
Edit this bug report at https://bugs.php.net/bug.php?id=55818&edit=1
[PHP-BUG] Bug #55818 [NEW]: Memcached::getByKey returns false when cas requested
From:
Operating system: Debian 6
PHP version: 5.3.8
Package: Unknown/Other Function
Bug Type: Bug
Bug description:Memcached::getByKey returns false when cas requested
Description:
---
>From manual page: http://www.php.net/memcached.getbykey#refsect1-
memcached.getbykey-returnvalues
---
Memcached::getByKey returns false when cas requested.
Test script:
---
$mc = new Memcached('MEMCACHED_SERVER_ID');
$mc->addServer('localhost', 11211);
var_dump(
$mc->setByKey('server', 'key', 'set_value'),
$mc->getResultMessage(),
$mc->getResultCode(),
'---',
$mc->getByKey('server', 'key', null, $cas),
$mc->getResultMessage(),
$mc->getResultCode(),
$cas,
'---',
$mc->getByKey('server', 'key'),
$mc->getResultMessage(),
$mc->getResultCode()
);
Expected result:
bool(true)
string(7) "SUCCESS"
int(0)
string(35) "---"
string(9) "set_value"
string(7) "SUCCESS"
int(0)
float(17086)
string(35) "---"
string(9) "set_value"
string(7) "SUCCESS"
int(0)
Actual result:
--
bool(true)
string(7) "SUCCESS"
int(0)
string(35) "---"
bool(false)
string(7) "SUCCESS"
int(0)
float(17086)
string(35) "---"
string(9) "set_value"
string(7) "SUCCESS"
int(0)
--
Edit bug report at https://bugs.php.net/bug.php?id=55818&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55818&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55818&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55818&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55818&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55818&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55818&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55818&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55818&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55818&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55818&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55818&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55818&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55818&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55818&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55818&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55818&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55818&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55818&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55818&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55818&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55818&r=mysqlcfg
[PHP-BUG] Bug #55817 [NEW]: Wrong codes of mb_detect_encoding
From: laruence
Operating system:
PHP version: 5.3.8
Package: mbstring related
Bug Type: Bug
Bug description:Wrong codes of mb_detect_encoding
Description:
using Z_STRVAL_P before make sure it is IS_STRING:
see http://lxr.php.net/opengrok/xref/PHP_5_4/ext/mbstring/mbstring.c#3186
if (ZEND_NUM_ARGS() >= 2 && Z_STRVAL_P(encoding_list)) {
switch (Z_TYPE_P(encoding_list)) {
case IS_ARRAY:
if (FAILURE ==
php_mb_parse_encoding_array(encoding_list, &list, &size, 0 TSRMLS_CC)) {
if (list) {
efree(list);
list = NULL;
size = 0;
}
}
break;
default:
convert_to_string(encoding_list);
if (FAILURE ==
php_mb_parse_encoding_list(Z_STRVAL_P(encoding_list),
Z_STRLEN_P(encoding_list),
&list, &size, 0 TSRMLS_CC)) {
if (list) {
efree(list);
list = NULL;
size = 0;
}
}
break;
}
if (size <= 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Illegal
argument");
}
}
Test script:
---
none
Expected result:
none
Actual result:
--
none
--
Edit bug report at https://bugs.php.net/bug.php?id=55817&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55817&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55817&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55817&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55817&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55817&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55817&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55817&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55817&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55817&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55817&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55817&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55817&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55817&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55817&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55817&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55817&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55817&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55817&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55817&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55817&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55817&r=mysqlcfg
Req #34392 [Com]: Similiar to __isset, we need an __ismethod for __call overload
Edit report at https://bugs.php.net/bug.php?id=34392&edit=1 ID: 34392 Comment by: wclssdn at yeah dot net Reported by:php dot net at sharpdreams dot com Summary:Similiar to __isset, we need an __ismethod for __call overload Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Win32 PHP Version:5CVS-2005-09-06 (snap) Block user comment: N Private report: N New Comment: method_exists() Previous Comments: [2005-09-06 16:27:10] php dot net at sharpdreams dot com Description: I cannot expect this to come any time soon, maybe for 6CVS. For isset() and unset() we now have __isset and __unset overload methods. We need another magic method for method_exists, e.g., __ismethod (or a similiar name, __iscallable, etc). Reproduce code: --- -- Edit this bug report at https://bugs.php.net/bug.php?id=34392&edit=1
