#46730 [NEW]: json_decode and 32Bit Maschines
From: info at marcel-schlesinger dot de Operating system: ALL PHP version: 5.2.6 PHP Bug Type: Unknown/Other Function Bug description: json_decode and 32Bit Maschines Description: Using json_decode with numbers higher then 2147483647 on a 32Bit maschine is still wrong! E.g. 5095334700020 has to be converted into a float (a string would be also okay), but not into an integer! Reproduce code: --- ?php $json = '{number:5095334700020}'; var_dump(json_decode($json)); ? Expected result: object(stdClass)#1 (1) { [number]= float(5095334700020) } it could also be: object(stdClass)#1 (1) { [number]= string(13) 5095334700020 } Actual result: -- object(stdClass)#1 (1) { [number]= int(2147483647) } -- Edit bug report at http://bugs.php.net/?id=46730edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46730r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46730r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46730r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46730r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46730r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46730r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46730r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46730r=needscript Try newer version: http://bugs.php.net/fix.php?id=46730r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46730r=support Expected behavior: http://bugs.php.net/fix.php?id=46730r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46730r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46730r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46730r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46730r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46730r=dst IIS Stability: http://bugs.php.net/fix.php?id=46730r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46730r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46730r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46730r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46730r=mysqlcfg
#46730 [Opn]: json_decode and 32Bit Maschines
ID: 46730 User updated by: info at marcel-schlesinger dot de Reported By: info at marcel-schlesinger dot de Status: Open -Bug Type: Unknown/Other Function +Bug Type: JSON related Operating System: ALL PHP Version: 5.2.6 New Comment: Updated category Previous Comments: [2008-12-02 12:53:32] info at marcel-schlesinger dot de Description: Using json_decode with numbers higher then 2147483647 on a 32Bit maschine is still wrong! E.g. 5095334700020 has to be converted into a float (a string would be also okay), but not into an integer! Reproduce code: --- ?php $json = '{number:5095334700020}'; var_dump(json_decode($json)); ? Expected result: object(stdClass)#1 (1) { [number]= float(5095334700020) } it could also be: object(stdClass)#1 (1) { [number]= string(13) 5095334700020 } Actual result: -- object(stdClass)#1 (1) { [number]= int(2147483647) } -- Edit this bug report at http://bugs.php.net/?id=46730edit=1
#46729 [NEW]: xslt_base_dir parameter doesn't work
From: gpl at ircf dot fr Operating system: Linux Ubuntu 8.10 PHP version: 5.2.6 PHP Bug Type: XSLT related Bug description: xslt_base_dir parameter doesn't work Description: Base path cannot be changed by setting the parameter xslt_base_dir in the xslt processor. This bug was also reported here : http://bugs.php.net/bug.php?id=43454edit=3 Reproduce code: --- ?php // First, load a XSL stylesheet $xslDom = DomDocument::loadXML('xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;xsl:include href=foo//xsl:stylesheet'); // Then initialize the XSLTProcessor $xsltProcessor = new xsltprocessor(); // Set the xslt_base_dir $xsltProcessor-setParameter('','xslt_base_dir','base'); // Import the stylesheet in the processor $xsltProcessor-importStylesheet($xslDom); ? Expected result: This program should raise the following warning : Failed to load external entity .../base/foo Actual result: -- The program raises the warning : Failed to load external entity .../foo -- Edit bug report at http://bugs.php.net/?id=46729edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46729r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46729r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46729r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46729r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46729r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46729r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46729r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46729r=needscript Try newer version: http://bugs.php.net/fix.php?id=46729r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46729r=support Expected behavior: http://bugs.php.net/fix.php?id=46729r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46729r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46729r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46729r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46729r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46729r=dst IIS Stability: http://bugs.php.net/fix.php?id=46729r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46729r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46729r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46729r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46729r=mysqlcfg
#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994 Comment by: brem at martinbreton dot com Reported By: dbarrett at vistaprint dot com Status: Assigned Bug Type: Program Execution Operating System: win32 only - 2003 Server, 64-bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: If that's any help, I'm using a COM object as a workaround for this bug, and while it makes this bug appear less frequently, it still happens, randomly, from time to time. Here's what i did as a workaround using the exec() function call: $WshShell = new COM(WScript.Shell); $OutputFile = C:\\Temp\\output.txt; $Command = cmd /C MyApp.exe $OutputFile; $WshShell-Run( $Command, 0, true ); file_get_contents( $OutputFile ) ); unlink( $OutputFile ); Previous Comments: [2008-11-18 08:46:34] bernd dot ebert at gmx dot net Same Problem here with an commandline-script calling other php-commandline-scripts. It seems to happen more frequently if you have a lot of exec-calls. [2008-08-19 02:58:37] jkflash at gmail dot com Sorry, I take that last comment back, it still hangs annoyingly intermittently with shell_exec as well. It's a killer :( [2008-08-13 01:08:19] jkflash at gmail dot com PS: shell_exec() DOES seem to work without hanging on my setup, but none of the others. [2008-08-12 23:50:58] jkflash at gmail dot com I am experiencing this same problem with PHP 5.2.1 running on IIS as an ISAPI module on Windows Server 2003 R2 SP2. Intermitently (a handful of times in a hundred) a process started with exec() will appear to complete ok but remain running in a zombie state. The IIS worker process that created the process will not respond to any further requests. I need to either open a new client browser or kill the worker process. I get the same result with system, passthru, p_open and proc_open. [2008-07-29 15:03:40] nobody at dontsendmespam dot com i can reproduce this problem on a debian server with apache2 and php5.2.6 running as fcgi The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/44994 -- Edit this bug report at http://bugs.php.net/?id=44994edit=1
#46730 [Opn-Bgs]: json_decode and 32Bit Maschines
ID: 46730 Updated by: [EMAIL PROTECTED] Reported By: info at marcel-schlesinger dot de -Status: Open +Status: Bogus Bug Type: JSON related Operating System: ALL PHP Version: 5.2.6 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. Can't reproduce -- should be fixed since 5.2.4... Feel free to reopen if you're actually using 5.2.6 and seeing this. :-) Previous Comments: [2008-12-02 13:01:36] info at marcel-schlesinger dot de Updated category [2008-12-02 12:53:32] info at marcel-schlesinger dot de Description: Using json_decode with numbers higher then 2147483647 on a 32Bit maschine is still wrong! E.g. 5095334700020 has to be converted into a float (a string would be also okay), but not into an integer! Reproduce code: --- ?php $json = '{number:5095334700020}'; var_dump(json_decode($json)); ? Expected result: object(stdClass)#1 (1) { [number]= float(5095334700020) } it could also be: object(stdClass)#1 (1) { [number]= string(13) 5095334700020 } Actual result: -- object(stdClass)#1 (1) { [number]= int(2147483647) } -- Edit this bug report at http://bugs.php.net/?id=46730edit=1
#46728 [NEW]: PDO(OCI)::fetchAll with stream (CLOB) : resource contains always same value
From: berlioz at nicematin dot fr Operating system: Linux (All ?) PHP version: 5.2.6 PHP Bug Type: PDO related Bug description: PDO(OCI)::fetchAll with stream (CLOB) : resource contains always same value Description: in PDO_OCI when you retrieve records from a table with a CLOB field using fetchAll(), fetchAll() returns different resource ids but they all contain the same datas from the last record of the set. Other fields are ok. if you loop with fetch it works fine. Reproduce code: --- $conn = new PDO(oci:dbname=.$tns,$db_username,$db_password); $stmt=$conn-query('select * from my_table_with_clob'); $records=$stmt-fetchAll(PDO::FETCH_ASSOC); print_r($records); foreach($records as $record) { echo my_clob=.stream_get_contents($record['MY_CLOB']).\n; } Expected result: my_clob=Data from record 0 my_clob=Data from record 1 my_clob=Data from record 2 my_clob=Data from record 3 my_clob=Data from record 4 Actual result: -- my_clob=Data from record 4 my_clob=Data from record 4 my_clob=Data from record 4 my_clob=Data from record 4 my_clob=Data from record 4 -- Edit bug report at http://bugs.php.net/?id=46728edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46728r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46728r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46728r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46728r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46728r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46728r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46728r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46728r=needscript Try newer version: http://bugs.php.net/fix.php?id=46728r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46728r=support Expected behavior: http://bugs.php.net/fix.php?id=46728r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46728r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46728r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46728r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46728r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46728r=dst IIS Stability: http://bugs.php.net/fix.php?id=46728r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46728r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46728r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46728r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46728r=mysqlcfg
#46731 [NEW]: Imap FT_UID handling problem
From: zoe dot slattery at googlemail dot com Operating system: Linux PHP version: 5.3CVS-2008-12-02 (snap) PHP Bug Type: Scripting Engine problem Bug description: Imap FT_UID handling problem Description: In imap_fetch_overview() the FT_UID parameter is treated as a bitmap. This means that giving it completely invalid parameters for FT_UID does not cause an error. Suggested fix to imap_fetch_overview() is here: http://pastebin.com/m750e3ed2 Reproduce code: --- To run this you would need the imap_include.inc file that is in ~ext/imap/tests. http://pastebin.com/m4da53733 Expected result: From this code I'd expect two successful fetches followed by two failures. Actual result: -- Four successful fetches, PHP_INT_MAX and PHP_INT_MAX-1 are interpreted as 1 and 0 respectively. -- Edit bug report at http://bugs.php.net/?id=46731edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46731r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46731r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46731r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46731r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46731r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46731r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46731r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46731r=needscript Try newer version: http://bugs.php.net/fix.php?id=46731r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46731r=support Expected behavior: http://bugs.php.net/fix.php?id=46731r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46731r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46731r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46731r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46731r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46731r=dst IIS Stability: http://bugs.php.net/fix.php?id=46731r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46731r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46731r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46731r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46731r=mysqlcfg
#46732 [Opn-Asn]: mktime.year description is wrong
ID: 46732 Updated by: [EMAIL PROTECTED] Reported By: dynkin at gmail dot com -Status: Open +Status: Assigned -Bug Type: Documentation problem +Bug Type: Date/time related Operating System: linux -PHP Version: Irrelevant +PHP Version: PHP 5 -Assigned To: +Assigned To: derick New Comment: This is a bug in the code though Previous Comments: [2008-12-02 16:27:08] dynkin at gmail dot com Description: Documentation of mktime's year parameter states that The number of the year, may be a two or four digit value, with values between 0-69 mapping to 2000-2069 and 70-100 to 1970-2000. But this part, `70-100 to 1970-2000`, is not precise. As in the implementation in ext/date/php_date.c::php_mktime, the doc should read: 70-110 to 1970-2010, instead of, 70-100 to 1970-2000. Reproduce code: --- echo date(Y-m-d, mktime(0,0,0,1,1,110)); Actual result: -- 2010-01-01 -- Edit this bug report at http://bugs.php.net/?id=46732edit=1
#46732 [Asn-Csd]: mktime.year description is wrong
ID: 46732 Updated by: [EMAIL PROTECTED] Reported By: dynkin at gmail dot com -Status: Assigned +Status: Closed Bug Type: Date/time related Operating System: linux PHP Version: PHP 5 Assigned To: derick New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-12-02 17:06:24] [EMAIL PROTECTED] This is a bug in the code though [2008-12-02 16:27:08] dynkin at gmail dot com Description: Documentation of mktime's year parameter states that The number of the year, may be a two or four digit value, with values between 0-69 mapping to 2000-2069 and 70-100 to 1970-2000. But this part, `70-100 to 1970-2000`, is not precise. As in the implementation in ext/date/php_date.c::php_mktime, the doc should read: 70-110 to 1970-2010, instead of, 70-100 to 1970-2000. Reproduce code: --- echo date(Y-m-d, mktime(0,0,0,1,1,110)); Actual result: -- 2010-01-01 -- Edit this bug report at http://bugs.php.net/?id=46732edit=1
#45989 [Opn]: json_decode() passes through certain invalid JSON strings
ID: 45989 User updated by: steven at acko dot net Reported By: steven at acko dot net Status: Open Bug Type: JSON related Operating System: Mac OS X PHP Version: 5.2.6 New Comment: till said: but it's supposed to return the string as is -- in case it's a literal type, but why does it in some cases return null then? What argument is there for having (some) unparseable sequences returned as is? If json_decode() returns a string, then that should mean that the input was a valid JSON encoding of that string, no? The only literal types JSON allows are numbers and the pre-defined constants 'true' 'false' and 'null'. Strings must be quote-delimited. The fact that you can switch between 'return NULL' and 'return the argument as-is' just by adding/removing a leading space is a pretty big sign that something is wrong here. To be honest, it seems a bit silly that this is even an argument. Previous Comments: [2008-12-01 17:16:06] [EMAIL PROTECTED] Just to add to this: I know that the function is not supposed to be a JSON validator, but it's supposed to return the string as is -- in case it's a literal type, but why does it in some cases return null then? For example: $bad_json = { 'bar': 'baz' }; json_decode($bad_json); // null I know this is probably an edge-case but $bad_json could be my own /valid/ string -- not valid JSON. Because a string could look like anything. Point well taken, I'm passing in a pretty /funky/ looking string. But instead of NULL, json_decode should return the string as-is. That is, according to the documentation, a bug. ;-) Lots of people also seemed to rely on json_decode as a json validator. Which is -- once you understand the subtle differences -- not the case. The case should be made for either one though. [2008-11-17 15:23:35] [EMAIL PROTECTED] @Iliaa: Could this bug be re-evaluated or a more detailed explaination as of why the docs sometimes note that NULL is returned on invalid json, and why sometimes json_decode() returns the string instead? If the function returns whatever then the docs should be updated to tell the user to not rely on what is returned by json_decode at all. ;-) I double-checked some of Steve's examples on jsonlint.com (which is in most docs cited as the reference validator for json data) and they all show up as invalid. I also build the most recent 5.2.7 snapshot: ./configure --disable-all --enable-json [EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php test-45989.php string(14) 'invalid json' string(12) invalid json string(2) { string(2) [ [EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php --ini Configuration File (php.ini) Path: /usr/local/lib Loaded Configuration File: (none) Scan for additional .ini files in: (none) Additional .ini files parsed: (none) [EMAIL PROTECTED]:~/php5.2-200811171330$ ./sapi/cli/php -m [PHP Modules] date json Reflection standard [Zend Modules] I'm gonna write a test and send it to QA too. [2008-09-10 01:14:23] steven at acko dot net Please clarify the bogus classification. The following each returns NULL, as expected: var_dump(json_decode('[')); // unmatched bracket var_dump(json_decode('{')); // unmatched brace var_dump(json_decode('{}}')); // unmatched brace var_dump(json_decode('{error error}')); // invalid object key/value notation var_dump(json_decode('[\]')); // unclosed string var_dump(json_decode('[ \x ]')); // invalid escape code Yet the following each returns the literal argument as a string: var_dump(json_decode(' [')); var_dump(json_decode(' {')); var_dump(json_decode(' {}}')); var_dump(json_decode(' {error error}')); var_dump(json_decode('\')); var_dump(json_decode(' \x ')); Please examine the examples closely: they are all meaningless, invalid JSON. Even under the most widely stretched definition of JSON, the above is not JSON encoded data. Yet json_decode() arbitarily returns /some of it/ as a string... and in a way that looks suspiciously like a bad parser implementation. If this was merely a case of json_decode() returning /all/ invalid json as is, then it could be classified as an implementation quirk. But because of how inconsistent it is now, you can't say that it is by design or following any kind of spec. E.g. how would you currently see if json_decode() succeeded or not? [2008-09-10 00:38:09] [EMAIL PROTECTED] 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 .
#41631 [Com]: default_socket_timeout does not work with SSL
ID: 41631 Comment by: nvora at yahoo-inc dot com Reported By: david at acz dot org Status: No Feedback Bug Type: OpenSSL related Operating System: * PHP Version: 5.2.6 Assigned To: pajoye New Comment: we are running into the same issue. where can i take a look at the patch? is the fix already checked in to cvs? Previous Comments: [2008-11-10 01:00:03] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-11-02 12:46:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-10-03 13:37:01] jose dot rodriguez at exec dot cl reproduced on PHP 5.2.6 @ Windows XP [2008-10-02 08:07:58] cunami at gmail dot com Bug also reproducible on PHP 5.2.4 (2ubuntu5.3). [2008-02-25 21:03:17] konstantin dot ryabitsev at mcgill dot ca This is still happening on 5.2.5, and is really annoying when a soap server you are connecting to accepts the connection and then hangs. Effectively, this quickly results in a denial of service for the entire site, as the end-result is hung HTTP processes. Please consider this for a high-priority fix. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/41631 -- Edit this bug report at http://bugs.php.net/?id=41631edit=1
#46731 [Opn-Csd]: Imap FT_UID handling problem
ID: 46731 Updated by: [EMAIL PROTECTED] Reported By: zoe dot slattery at googlemail dot com -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.3CVS-2008-12-02 (snap) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-12-02 16:04:17] zoe dot slattery at googlemail dot com Description: In imap_fetch_overview() the FT_UID parameter is treated as a bitmap. This means that giving it completely invalid parameters for FT_UID does not cause an error. Suggested fix to imap_fetch_overview() is here: http://pastebin.com/m750e3ed2 Reproduce code: --- To run this you would need the imap_include.inc file that is in ~ext/imap/tests. http://pastebin.com/m4da53733 Expected result: From this code I'd expect two successful fetches followed by two failures. Actual result: -- Four successful fetches, PHP_INT_MAX and PHP_INT_MAX-1 are interpreted as 1 and 0 respectively. -- Edit this bug report at http://bugs.php.net/?id=46731edit=1
#40479 [Com]: zend_mm_heap corrupted
ID: 40479 Comment by: yell at yllow1 dot pl Reported By: rrossi at maggioli dot it Status: No Feedback Bug Type: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: After my debugging - it seems script runs to the end (trigger_error even in last line works). Adding one print(null); in random place of script did help me! But I had this problem for 3 places, it help only for one. And now is the best :) Huge block of print(null);print(null). is enough in my case :) I only have hope - my customer will not look into source ;) yellow1pl Previous Comments: [2008-11-20 09:06:01] john dot glazebrook at guava dot com The more comments the more this sounds like a race condition. Looks like it would be almost impossible to bug hunt. Have you tried the 6 version? Maybe this has been fixed? John [2008-11-19 16:46:12] rpeters at icomproductions dot ca We are experiencing multiple zend_mm_heap corrupted errors daily on our production server during peak load. During off-peak periods, all scripts work as expected. PHP 5.2.2 RedHat Linux 2.6.9-78.0.5.ELsmp Why is this set to No Feedback when there's a debug dump provided? [2008-10-20 08:07:39] moo at moo dot com hello? [2008-10-13 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-10-06 15:52:07] john dot glazebrook at guava dot co dot uk Re: My last post: I disabled as much stuff as I could before running the bad page. John The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/40479 -- Edit this bug report at http://bugs.php.net/?id=40479edit=1
#40479 [Com]: zend_mm_heap corrupted
ID: 40479 Comment by: yell at yellow1 dot pl Reported By: rrossi at maggioli dot it Status: No Feedback Bug Type: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: On the other hand now i had a lot of [notice] child pid 29716 exit signal Segmentation fault (11) in log, but at least it sends output befor exit,so I can live with it ;) Previous Comments: [2008-12-03 01:52:51] yell at yllow1 dot pl After my debugging - it seems script runs to the end (trigger_error even in last line works). Adding one print(null); in random place of script did help me! But I had this problem for 3 places, it help only for one. And now is the best :) Huge block of print(null);print(null). is enough in my case :) I only have hope - my customer will not look into source ;) yellow1pl [2008-11-20 09:06:01] john dot glazebrook at guava dot com The more comments the more this sounds like a race condition. Looks like it would be almost impossible to bug hunt. Have you tried the 6 version? Maybe this has been fixed? John [2008-11-19 16:46:12] rpeters at icomproductions dot ca We are experiencing multiple zend_mm_heap corrupted errors daily on our production server during peak load. During off-peak periods, all scripts work as expected. PHP 5.2.2 RedHat Linux 2.6.9-78.0.5.ELsmp Why is this set to No Feedback when there's a debug dump provided? [2008-10-20 08:07:39] moo at moo dot com hello? [2008-10-13 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/40479 -- Edit this bug report at http://bugs.php.net/?id=40479edit=1
#43901 [Com]: PHP needs new function to expand strings
ID: 43901 Comment by: cvolny at gmail dot com Reported By: t03 at springtimesoftware dot com Status: Open Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5.2.5 New Comment: I wrote two functions to display ways of accomplishing this already (although a built-in function would be nice). This function is very restrictive and requires you to pass a hash (name=value) as $vars. I prefer and use this function to build page layout with predefined variables to be placed in a template file (I put stuff like div id=content$content/div where a page's specific content should go). I consider this a safer way to string expand as you are explicitly limiting what can be expanded. Some improvements can be done to it to handle arrays, but I haven't had a need for it yet. function stringExpand($subject, array $vars) { // loop over $vars map foreach ($vars as $name = $value) { // use preg_replace to match ${`$name`} or $`$name` $subject = preg_replace(sprintf('/\$\{?%s\}?/', $name), $value, $subject); } // return variable expanded string return $subject; } This second function accomplishes the same task only using eval() and variables in the current symbol table (with the help of extract()). I opted to use heredoc with optionally a randomly generated delimiter. This allows access to all variables available to the function (static members, globals, $vars, etc) so it could potentially allow access to preferably private data. I won't even go into the security implications of using eval() to accomplish this, it's probably better to use something like the above. here it is: function stringExpandDangerous($subject, array $vars = array(), $random = true) { // extract $vars into current symbol table extract($vars); $delim; // if requested to be random (default), generate delim, otherwise use predefined (trivially faster) if ($random) $delim = '___' . chr(mt_rand(65,90)) . chr(mt_rand(65,90)) . chr(mt_rand(65,90)) . chr(mt_rand(65,90)) . chr(mt_rand(65,90)) . '___'; else $delim = '__ASDFZXCV1324ZXCV__'; // button mashing... // built the eval code $statement = return $delim\n\n . $subject . \n$delim;\n; // execute statement, saving output to $result variable $result = eval($statement); // if eval() returned FALSE, throw a custom exception if ($result === false) throw new EvalException($statement); // return variable expanded string return $result; } As you can see you can easily (and dangerously) accomplish this task using eval() or you can cautiously accomplish it using a variant of regex. I would recommend limiting the access of your string expansion script as well as avoiding eval(), you can capture variable names values easily using compact(). I wouldnt allow your script access to $GLOBALS like the above comment, you might not want that data as accessible as youre making it. Previous Comments: [2008-01-24 20:02:40] t03 at springtimesoftware dot com In case anyone else reads this and needs a workaround, here is function to expand any embedded variables of the form $name found inside a given string. Note: this uses the global scope, even if called from inside a function. // Expand global variables if found in a string // ExpandVars ver=1/24/08 function ReplaceVarCallback($M) { if (!isset($GLOBALS[$M[1]])) die(Variable [EMAIL PROTECTED] is undefined.); return $GLOBALS[$M[1]]; } // ReplaceVarCallback function ExpandVars($Str) { for (;;) { $Res=preg_replace_callback('#\$([A-Za-z_][A-Za-z0-9_]*)#', ReplaceVarCallback,$Str); if ($Res==$Str) break; $Str=$Res; } return $Str; } // ExpandVars [2008-01-21 01:56:50] t03 at springtimesoftware dot com Description: (Note: This feature request is similar to some existing ones, but provides much clearer explanation, motivation, and details. I hope it will be considered on its own and that this proposal gets elevated to the PHP design team for serious consideration.) In PHP, string literals that are specified using quotation marks () or HEREDOC syntax are implicitly expanded in several ways, including translation of backslash-escaped characters and substitution of the actual values of variables, as indicated by leading left brace or dollar signs. There are many common programming situations