Bug #64633 [Com]: microtime regression - resolution reduced to 64 ticks per second
Edit report at https://bugs.php.net/bug.php?id=64633edit=1
ID: 64633
Comment by: martin dot hason at gmail dot com
Reported by:phpbugs at musiclogistics dot net
Summary:microtime regression - resolution reduced to 64
ticks per second
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Windows 7
PHP Version:5.4.14
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
The same problem occurs in PHP 5.5.1 too! Please fix this bug.
Previous Comments:
[2013-06-16 04:02:52] yaro at opti dot su
The same problem occurs in PHP 5.4.15 too!
Why developers ignore such an important issue?
[2013-04-12 14:22:32] phpbugs at musiclogistics dot net
@a...@php.net: You are right: While usleep() only works in 1/64 second
increments on my machine (640 loops of usleep(1) take about 10 seconds), this
is not related to PHP 5.4.14. It's the same on 5.4.13 and probably a limitation
of Windows' multitasking.
[2013-04-12 11:29:36] paj...@php.net
We should use performance counters instead, which brings a much higher
precision
at less cost.
[2013-04-12 11:25:47] a...@php.net
This is a tradeoff one has to make, precision vs. accuracy. That's very
depending on the hardware. While on one system using the performance timer it
would work as expected, on another it's still more accurate time with a very
variable precision. That's where you could see in your snippet currentTimeMs()
- $startTimeMs 0. That is much more weird than possibly having a worse
resolution, say currentTimeMs() - $startTimeMs == 0.
Heres' an interesting reading about this
http://blogs.msdn.com/b/oldnewthing/archive/2005/09/02/459952.aspx . The goal
of the latest fix is to remove the random results. Also this will work in most
cases as normally a script doesn't consist on just two subsequent microtime
calls. Starting with win8 there is a much better API, but it of course doesn't
help here. I'm not sure it should be touched, will look how to improve it
without getting to the old erroneous behaviour. Maybe reimplement the
performance timer part and make an ini option to let user decide if the
performance timer should be used. As we really cannot foresee every hardware
bugs.
Btw. usleep() isn't affected by that, it uses the waitable timer which has a
better resolution.
[2013-04-11 16:52:09] phpbugs at musiclogistics dot net
Description:
Probably caused by recent patch for bug #64370:
Since v 5.4.14 microtime() only moves forward in 15,6 ms (1/64 sec) increments
on Win7. Same for CLI and Apache 2.2 SAPI.
Build: VC9 x86 Thread Safe (2013-Apr-10 22:55:28) from windows.php.net.
Behaviour normal after downgrade to 5.4.13.
This also breaks usleep() (only sleeping for multiples of 15,6 ms now) and
uniqid() (returning the same value for 15,6 ms with $more_entropy = false).
Test script:
---
for ($startTimeMs = currentTimeMs(), $i = 0; $i 1; $i++) {
//usleep(1);
echo (currentTimeMs() - $startTimeMs) . ' ';
}
function currentTimeMs() {
return round(microtime(true) * 100);
}
Expected result:
[what PHP 5.4.13 prints on the same machine:]
13 28 35 41 48 54 61 67 74 80 86 92 99 105 112 118 124 131 137 143 149 155 162
168 174 181 187 193 200 206 212 218 224 [...and so on]
Actual result:
--
0 0 0 0 0 0 0 0 0 [many more zeroes] 15600 15600 15600 15600 [...] 31200 31200
31200 31200 31200 [...] 46800 46800 46800 46800 46800 [...and so on]
--
Edit this bug report at https://bugs.php.net/bug.php?id=64633edit=1
[PHP-BUG] Bug #64931 [NEW]: phar_add_file is too restrive on filename
From: william dot martin at power-lan dot com Operating system: Linux PHP version: 5.4.15 Package: PHAR related Bug Type: Bug Bug description:phar_add_file is too restrive on filename Description: The function phar_add_file start by test if we try to write something in the .phar magic directory, but the test is in really : Does a filepath start by .phar ? So if you try to pack files likes .pharignore, php throw an exception: Error: Cannot create any files in magic .phar directory. Test script: --- ?php touch(.pharignore); $phar = new \Phar(foo.phar, 0, foo.phar); $phar-addFile(.pharignore, .pharignore); -- Edit bug report at https://bugs.php.net/bug.php?id=64931edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64931r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64931r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64931r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64931r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64931r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64931r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64931r=needscript Try newer version: https://bugs.php.net/fix.php?id=64931r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64931r=support Expected behavior: https://bugs.php.net/fix.php?id=64931r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64931r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64931r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64931r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64931r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64931r=dst IIS Stability: https://bugs.php.net/fix.php?id=64931r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64931r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64931r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64931r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64931r=mysqlcfg
Bug #64868 [Fbk-Opn]: segfault in zval_mark_grey(), Zend/zend_gc.c:421
Edit report at https://bugs.php.net/bug.php?id=64868edit=1 ID: 64868 User updated by:martin dot schuette at icans-gmbh dot com Reported by:martin dot schuette at icans-gmbh dot com Summary:segfault in zval_mark_grey(), Zend/zend_gc.c:421 -Status: Feedback +Status: Open Type: Bug Package:Reproducible crash Operating System: Debian Linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: So far I was unable to reproduce the crash with a smaller code sample (i.e. without requiring our complete application and test suite). Previous Comments: [2013-05-17 10:57:43] larue...@php.net could you please provide a reproduce test script? thanks [2013-05-17 10:47:30] martin dot schuette at icans-gmbh dot com Description: As part of a PHPUnit test suite I get this segfault. Interestingly it depends on phpunit's command line options. Segfault with phpunit -c app/phpunit.xml.dist --log-junit /dev/null No problem with phpunit -c app/phpunit.xml.dist and phpunit -c app/phpunit.xml.dist --log-junit /dev/null --debug Without GC it works as well: php -dzend.enable_gc=0 /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null Expected result: complete PHPUnit run Actual result: -- deploy@jenkins:/tmp/gitphp -v PHP 5.4.4-14 (cli) (built: Mar 4 2013 14:08:43) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies deploy@jenkins:/tmp/gitgdb --args php /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/php...Reading symbols from /usr/lib/debug/usr/bin/php5...done. done. (gdb) run Starting program: /usr/bin/php /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/mysql.so does not match /usr/lib/php5/20100525/mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/mysql.so does not match /usr/lib/php5/20100525/mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/mysqli.so does not match /usr/lib/php5/20100525/mysqli.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/mysqli.so does not match /usr/lib/php5/20100525/mysqli.so (CRC mismatch). warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/pdo_mysql.so does not match /usr/lib/php5/20100525/pdo_mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/pdo_mysql.so does not match /usr/lib/php5/20100525/pdo_mysql.so (CRC mismatch). [New Thread 0x7fffe80d8700 (LWP 27679)] [Thread 0x7fffe80d8700 (LWP 27679) exited] PHPUnit 3.7.10 by Sebastian Bergmann. Configuration read from /tmp/git/app/phpunit.xml.dist . 61 / 3421 ( 1%) ...S. 122 / 3421 ( 3%) . 183 / 3421 ( 5%) . 244 / 3421 ( 7%) . 305 / 3421 ( 8%) . 366 / 3421 ( 10%) . 427 / 3421 ( 12%) . 488 / 3421 ( 14%) . 549 / 3421 ( 16%) . 610 / 3421 ( 17%) . 671 / 3421 ( 19%) . 732 / 3421 ( 21%) . 793 / 3421 ( 23%) . 854 / 3421 ( 24%) . 915 / 3421 ( 26%) . 976 / 3421 ( 28
[PHP-BUG] Bug #64868 [NEW]: segfault in zval_mark_grey(), Zend/zend_gc.c:421
From: martin dot schuette at icans-gmbh dot com Operating system: Debian Linux PHP version: 5.4.15 Package: Reproducible crash Bug Type: Bug Bug description:segfault in zval_mark_grey(), Zend/zend_gc.c:421 Description: As part of a PHPUnit test suite I get this segfault. Interestingly it depends on phpunit's command line options. Segfault with phpunit -c app/phpunit.xml.dist --log-junit /dev/null No problem with phpunit -c app/phpunit.xml.dist and phpunit -c app/phpunit.xml.dist --log-junit /dev/null --debug Without GC it works as well: php -dzend.enable_gc=0 /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null Expected result: complete PHPUnit run Actual result: -- deploy@jenkins:/tmp/gitphp -v PHP 5.4.4-14 (cli) (built: Mar 4 2013 14:08:43) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies deploy@jenkins:/tmp/gitgdb --args php /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/php...Reading symbols from /usr/lib/debug/usr/bin/php5...done. done. (gdb) run Starting program: /usr/bin/php /usr/bin/phpunit -c app/phpunit.xml.dist --log-junit /dev/null [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/mysql.so does not match /usr/lib/php5/20100525/mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/mysql.so does not match /usr/lib/php5/20100525/mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/mysqli.so does not match /usr/lib/php5/20100525/mysqli.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/mysqli.so does not match /usr/lib/php5/20100525/mysqli.so (CRC mismatch). warning: the debug information found in /usr/lib/debug//usr/lib/php5/20100525/pdo_mysql.so does not match /usr/lib/php5/20100525/pdo_mysql.so (CRC mismatch). warning: the debug information found in /usr/lib/debug/usr/lib/php5/20100525/pdo_mysql.so does not match /usr/lib/php5/20100525/pdo_mysql.so (CRC mismatch). [New Thread 0x7fffe80d8700 (LWP 27679)] [Thread 0x7fffe80d8700 (LWP 27679) exited] PHPUnit 3.7.10 by Sebastian Bergmann. Configuration read from /tmp/git/app/phpunit.xml.dist . 61 / 3421 ( 1%) ...S. 122 / 3421 ( 3%) . 183 / 3421 ( 5%) . 244 / 3421 ( 7%) . 305 / 3421 ( 8%) . 366 / 3421 ( 10%) . 427 / 3421 ( 12%) . 488 / 3421 ( 14%) . 549 / 3421 ( 16%) . 610 / 3421 ( 17%) . 671 / 3421 ( 19%) . 732 / 3421 ( 21%) . 793 / 3421 ( 23%) . 854 / 3421 ( 24%) . 915 / 3421 ( 26%) . 976 / 3421 ( 28%) . 1037 / 3421 ( 30%) . 1098 / 3421 ( 32%) . 1159 / 3421 ( 33%) . 1220 / 3421 ( 35%) . 1281 / 3421 ( 37%) . 1342 / 3421 ( 39%) . 1403 / 3421 ( 41%) . 1464 / 3421 ( 42%) . Program received signal SIGSEGV, Segmentation fault. zval_mark_grey (pz=0xcf1fa60) at /tmp/buildd/php5-5.4.4
Bug #60723 [Com]: error_log error time has changed to UTC ignoring default timezo
Edit report at https://bugs.php.net/bug.php?id=60723edit=1 ID: 60723 Comment by: martin dot marques at gmail dot com Reported by:olemarkus at gentoo dot org Summary:error_log error time has changed to UTC ignoring default timezo Status: Closed Type: Bug Package:Date/time related Operating System: Gentoo Linux PHP Version:5.3.9 Assigned To:derick Block user comment: N Private report: N New Comment: Don't see the fix in Debians testing packages (specifically 5.4.4), still seeing the UTC time instead of the local time: # apt-cache policy php5 php5: Instalados: 5.4.4-13 Candidato: 5.4.4-13 Tabla de versión: 5.5.0~alpha4-1 0 40 http://ftp.de.debian.org/debian/ experimental/main i386 Packages *** 5.4.4-13 0 500 http://ftp.de.debian.org/debian/ testing/main i386 Packages 50 http://ftp.de.debian.org/debian/ unstable/main i386 Packages 100 /var/lib/dpkg/status 5.3.3-7+squeeze14 0 500 http://security.debian.org/ squeeze/updates/main i386 Packages 500 http://ftp.de.debian.org/debian/ stable/main i386 Packages From the log file: [25-Feb-2013 11:05:46 UTC] PHP Deprecated: Assigning the return value of new by reference is deprecated in /usr/share/php/MDB2.php on line 390 Previous Comments: [2013-01-28 15:24:11] spam2 at rhsoft dot net i do not see anything fixed errorlog still contains the timezone PHP 5.3.21 as also 5.4.11 [28-Jan-2013 16:22:38 Europe/Vienna] PHP Parse error: syntax error, unexpected end of file in Command line code on line 1 the sysadmin knows his timezone well enough... [2012-10-10 21:19:40] pixelchutes at gmail dot com Should hopefully be released in 5.3.18, since 5.3.17 was released just a few days before the patch was committed (13-Sep-2012 vs 23-Sep-2012). Glad to hear this has been resolved, thanks! [2012-09-24 03:04:55] larue...@php.net hey, committed to 5.3 5.4 branches, will fixed in next release, thanks [2012-09-24 03:01:30] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=923511d364ad84500bb097aca15385129ce6e336 Log: Fixed bug #60723 (error_log error time has changed to UTC ignoring default timezo) [2012-09-24 03:01:10] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=923511d364ad84500bb097aca15385129ce6e336 Log: Fixed bug #60723 (error_log error time has changed to UTC ignoring default timezo) 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=60723 -- Edit this bug report at https://bugs.php.net/bug.php?id=60723edit=1
[PHP-BUG] Bug #64167 [NEW]: Recursive function using mt_rand sometimes returns NULL
From: martin at psinas dot com
Operating system: linux mint
PHP version: 5.4.11
Package: Variables related
Bug Type: Bug
Bug description:Recursive function using mt_rand sometimes returns NULL
Description:
Variable is properly set but returns as NULL value
Test script:
---
?php
function mtrand_except($min, $max, $except) {
$random_number = mt_rand($min, $max);
if(!in_array($random_number, $except)) {
echo $random_number.'br /';
return $random_number;
}
mtrand_except($min, $max, $except);
}
$random_arr = array();
for($i=1; $i=90; $i++) {
$rand = mtrand_except(1, 90, $random_arr);
echo $i.'br /'.$rand.'hr /';
$random_arr[] = $rand;
}
Expected result:
60
1
60
--
19
2
19
--
57
3
57
--
etc...
Actual result:
--
60
1
60
--
19
2
NULL
--
57
3
57
--
etc...
--
Edit bug report at https://bugs.php.net/bug.php?id=64167edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64167r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64167r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64167r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64167r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64167r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64167r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64167r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64167r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64167r=support
Expected behavior: https://bugs.php.net/fix.php?id=64167r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64167r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64167r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64167r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64167r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64167r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64167r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64167r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64167r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64167r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64167r=mysqlcfg
Bug #52424 [Com]: Function naming inconsistency: htmlentities() x html_entity_decode()
Edit report at https://bugs.php.net/bug.php?id=52424edit=1 ID: 52424 Comment by: martin dot keckeis1 at gmail dot com Reported by:php-bugs at majkl578 dot cz Summary:Function naming inconsistency: htmlentities() x html_entity_decode() Status: Wont fix Type: Bug Package:Unknown/Other Function PHP Version:5.3.3 Block user comment: N Private report: N New Comment: +1 to make function name and parameters order more consistent! Previous Comments: [2013-01-24 16:43:46] turneliusz at gmail dot com I think we should keep current look and feel of this low level part of PHP, functions. I don't believe PSR have anything to do with that naming conventions. It could end up with some huge proposal about moving functions to some namespaces which would be huge change. I think it's just simple renaming we have to do. A real proposal about revolution in functions could be IMO autoboxing but this is another topic. And BTW that idea about providing switches in php.int could make huge mess. Let's deprecate and in major release remove, no incompatibility with same versions of PHP due to some magic [2013-01-24 15:54:58] chris at cgsmith dot net It seems silly for any developer to change certain function names even though it is something in the back of there head. It comes down to, if it isn't broke, why fix it?. But for a community this large and people that are trying out PHP and learning best practices, this needs to be done. However, there needs to be a vote on the naming conventions that are used. Perhaps following PSR-1 or PSR-2. [2013-01-24 14:03:43] turneliusz at gmail dot com Excuse me rasmus but WHY NOT? It's completely normal evolution process. Let's deprecated all things that have inconsistent naming in PHP 5.6 to be able to just remove them in PHP 6.0 where breaking compatibility would be possible. It would be just great to have PHP 6.0 as PHP 5.x with consistent function naming convention, with removed all of deprecated stuff. [2013-01-24 04:03:23] nishant dot kanitkar at gmail dot com I don't see why this can't be done. Alias the functions to a single standard and depreciate the old ones. In the next version of PHP, add a configuration toggle ALLOW_LEGACY_FUNCTIONS set to default false. If ALLOW_LEGACY_FUNCTIONS is true, all the depreciated functions work as expected. If ALLOW_LEGACY_FUNCTIONS is false, all the depreciated functions throw errors. Keep the toggle in all future versions of PHP. Eventually applications using the legacy function names will either run a search-and-replace or fall out of use. It wouldn't be too difficult to migrate if the only change is a name change. [2013-01-24 02:46:34] php at lavoie dot sl The core functionsâ naming is one the most frowned upon feature of PHP and it is well overdue for a refactor. Old frameworks and application are a pain to convert, and it pretty pointless to do it for a cosmetic reason as rasmus pointed out, but I think the core devs are underestimating how much the community wants it done and how many people are willing to do their part. Letâs face it: â¢Â htmlentities/html_entity_decode ⢠str_replace/strtr â¢Â current/array_pop ⢠array_push($array, $item)/array_search($item, $array) I believe a very responsible roadmap would be to : 1. Create a PHP library that would essentially just wrap a function in another with consistent naming and arguments order. 2. Get some feedback of the community and work on the names. The guys at FIG would probably be a blessing on that. 3. Implement those using aliasing and a compiled extension. 4. Let it sit for a couple time while people get to know about it. 5. Merge extension into core. Real world application will begin to use it. 6. Drop the deprecated ones in a distant future. 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=52424 -- Edit this bug report at https://bugs.php.net/bug.php?id=52424edit=1
Bug #32510 [Com]: not replaced with �
Edit report at https://bugs.php.net/bug.php?id=32510edit=1 ID: 32510 Comment by: martin at 4playtheband dot co dot uk Reported by:jimmy dot palm at netatonce dot net Summary:not replaced with ¬ Status: Not a bug Type: Bug Package:*General Issues Operating System: Linux PHP Version:5.0.3 Block user comment: N Private report: N New Comment: I just got this bug when passing a query string to another script, I had notes=12345 but the not part was being replaced with ¬ (not;) Previous Comments: [2005-03-31 15:53:41] der...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. This is a browser issue, has nothing to do with PHP itself. [2005-03-31 08:18:02] sni...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this.. [2005-03-31 02:10:30] jimmy dot palm at netatonce dot net Description: when I write not, php 5.0.3 will replace it with ¬ not = replaces with ¬ curren = replaces with ¤ Weird??? ex. $currency = EUR ; printf(currency = %s, $currency) ; will write: ¤cy=EUR ? what is the problem ? Expected result: That: $currency = EUR ; printf(currency = %s, $currency) ; gives output currency = EUR -- Edit this bug report at https://bugs.php.net/bug.php?id=32510edit=1
Bug #62444 [Com]: Handle leak in is_readable
Edit report at https://bugs.php.net/bug.php?id=62444edit=1
ID: 62444
Comment by: vseticka dot martin at gmail dot com
Reported by:sergio dot nalin at gmail dot com
Summary:Handle leak in is_readable
Status: Assigned
Type: Bug
Package:Filesystem function related
Operating System: Win 7 64bit
PHP Version:5.3.14
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Is there any progress? This issue makes PHP really hard to use on Windows.
Previous Comments:
[2012-07-26 17:24:41] mr_pain at operamail dot com
Memory leak confirmed for the following configurations:
PHP vc9 5.3.15, thread safe version + Apache Httpd 2.4.2 + Win XP SP3
PHP vc9 5.4.5, thread safe version + Apache Httpd 2.4.2 + Win XP SP3
Running Test script:
for($i=0; $i100;$i++) {
is_readable(c:\\temp);
}
PHP vc9 5.4.5 tested on WAMP stacks:
XAMPP USB Lite 1.8.0(Windows XP SP3)
Uniform Server 8.5.8-Coral (Windows XP SP3)
For details see:
http://forum.uniformserver.com/index.php?showtopic=2627hl=
Windows 7 SP1 and Windows Server 2008 R2 (both is 64-bit OS)
I agree with above comment, it makes running PHP on a Windows production server
impractical.
[2012-07-25 22:26:05] smiles_indonesia at yahoo dot co dot id
It seems happened since introduction of php 5.3.0. If you see in the changelogs:
http://www.php.net/ChangeLog-5.php
Added support for ACL (is_writable, is_readable, reports now correct results)
on Windows. (Pierre, Venkat Raman Don, Kanwaljeet Singla)
This issue is very critical, because it makes php running on windows production
server impractical / unusable...
My quad xeon box becomes very slow after some days, the ram usage is
mysteriously increased (httpd process usage still remains the same, I thought
handle consumes kernel spaces)...
If your webserver servers 1 million request, then there will be about 1 million
handle opened... Usual application only consumes 20 to 2000 handles...
[2012-06-29 00:10:17] sergio dot nalin at gmail dot com
Description:
PHP vc9 5.3.14, thread safe version + Apache Httpd 2.2.22 + Win 7/Win Server
2008
R2
Each time is_readable in invoked, it leaves an open handle in the httpd process.
Test script:
---
for($i=0; $i100;$i++) {
is_readable(c:\\temp);
}
NOTE: the folder/file must exist for the leak to happen.
Expected result:
No leaked handles
Actual result:
--
100 leaked handles
--
Edit this bug report at https://bugs.php.net/bug.php?id=62444edit=1
Bug #60723 [Com]: error_log error time has changed to UTC ignoring default timezo
Edit report at https://bugs.php.net/bug.php?id=60723edit=1 ID: 60723 Comment by: martin dot marques at gmail dot com Reported by:olemarkus at gentoo dot org Summary:error_log error time has changed to UTC ignoring default timezo Status: Assigned Type: Bug Package:Date/time related Operating System: Gentoo Linux PHP Version:5.3.9 Assigned To:derick Block user comment: N Private report: N New Comment: Is someone working on this? It's quite an annoying bug. Previous Comments: [2012-07-20 03:06:13] ramsy at ramix dot jp Why is it neglected? The cause of this bug is specification change by the wrong bug fix method. [2012-07-13 10:15:55] akempiak at odiso dot com Same, PHP 5.3.14 Debian Squeeze [2012-07-08 02:39:39] likekidz at 126 dot com same problem in PHP 5.3.14 and 5.4.4 my OS is Windows XP [2012-06-14 00:35:11] kris dot glynn at virginaustralia dot com Present also in PHP 5.3.13 CentOS release 5.7 (Final) Linux blah 2.6.18-274.18.1.el5PAE #1 SMP Thu Feb 9 13:25:50 EST 2012 i686 i686 i386 GNU/Linux PHP 5.3.13 (cli) (built: Jun 13 2012 14:53:50) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies [2012-06-06 05:03:35] ramsy at ramix dot jp The merit which makes this message UTC fixation is not known. How about changing in this way? in main/main.c -error_time_str = php_format_date(d-M-Y H:i:s e, 13, error_time, 0 TSRMLS_CC); +error_time_str = php_format_date(d-M-Y H:i:s T, 13, error_time, 1 TSRMLS_CC); output(date.timezone='Asia/Tokyo') [06-Jun-2012 13:54:12 JST] foo 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=60723 -- Edit this bug report at https://bugs.php.net/bug.php?id=60723edit=1
[PHP-BUG] Bug #62839 [NEW]: curl_copy_handle segfault with CURLOPT_FILE
From: martin at mixotv dot com
Operating system: Linux 3.4.8-1
PHP version: 5.4.5
Package: cURL related
Bug Type: Bug
Bug description:curl_copy_handle segfault with CURLOPT_FILE
Description:
When using cURL with the option CURLOPT_FILE (write the result of the curl
request in a file), curl_copy_handle() causes a SEGFAULT.
I use the packages from Archlinux repository (php, libcurl 7.27.0 x86_64).
I get the same results with a current ubuntu distribution.
Test script:
---
?php
$curl = curl_init();
$fd = fopen('/tmp/test', 'wb');
curl_setopt($curl, CURLOPT_FILE, $fd);
$copy = curl_copy_handle($curl);
var_dump($copy);
curl_close($copy);
curl_close($curl);
fclose($fd);
Expected result:
no segfault
Actual result:
--
segfault:
#0 0x75ca6f46 in ?? () from /usr/lib/php/modules/curl.so
#1 0x75ec0f0d in xdebug_execute_internal () from
/usr/lib/php/modules/xdebug.so
#2 0x006dac6d in ?? ()
#3 0x006946ff in execute ()
#4 0x75ec1392 in xdebug_execute () from
/usr/lib/php/modules/xdebug.so
#5 0x006355d9 in zend_execute_scripts ()
#6 0x005d5393 in php_execute_script ()
#7 0x006dd433 in ?? ()
#8 0x0042601a in ?? ()
#9 0x7692d725 in __libc_start_main () from /lib/libc.so.6
#10 0x004260ad in _start ()
--
Edit bug report at https://bugs.php.net/bug.php?id=62839edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62839r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62839r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62839r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62839r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62839r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62839r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62839r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62839r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62839r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62839r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62839r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62839r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62839r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62839r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62839r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62839r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62839r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62839r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62839r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62839r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62839r=mysqlcfg
Bug #62839 [Fbk-Opn]: curl_copy_handle segfault with CURLOPT_FILE
Edit report at https://bugs.php.net/bug.php?id=62839edit=1
ID: 62839
User updated by:martin at mixotv dot com
Reported by:martin at mixotv dot com
Summary:curl_copy_handle segfault with CURLOPT_FILE
-Status: Feedback
+Status: Open
Type: Bug
Package:cURL related
Operating System: Linux 3.4.8-1
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
Hi Felipe,
Here is the backtrace without Xdebug:
Program received signal SIGSEGV, Segmentation fault.
#0 0x75ed9f46 in ?? () from /usr/lib/php/modules/curl.so
#1 0x006dae02 in ?? ()
#2 0x006946ff in execute ()
#3 0x006355d9 in zend_execute_scripts ()
#4 0x005d5393 in php_execute_script ()
#5 0x006dd433 in ?? ()
#6 0x0042601a in ?? ()
#7 0x7692d725 in __libc_start_main () from /lib/libc.so.6
#8 0x004260ad in _start ()
Previous Comments:
[2012-08-16 14:09:36] fel...@php.net
Try disabling xdebug.
[2012-08-16 13:58:36] martin at mixotv dot com
Description:
When using cURL with the option CURLOPT_FILE (write the result of the curl
request in a file), curl_copy_handle() causes a SEGFAULT.
I use the packages from Archlinux repository (php, libcurl 7.27.0 x86_64).
I get the same results with a current ubuntu distribution.
Test script:
---
?php
$curl = curl_init();
$fd = fopen('/tmp/test', 'wb');
curl_setopt($curl, CURLOPT_FILE, $fd);
$copy = curl_copy_handle($curl);
var_dump($copy);
curl_close($copy);
curl_close($curl);
fclose($fd);
Expected result:
no segfault
Actual result:
--
segfault:
#0 0x75ca6f46 in ?? () from /usr/lib/php/modules/curl.so
#1 0x75ec0f0d in xdebug_execute_internal () from
/usr/lib/php/modules/xdebug.so
#2 0x006dac6d in ?? ()
#3 0x006946ff in execute ()
#4 0x75ec1392 in xdebug_execute () from /usr/lib/php/modules/xdebug.so
#5 0x006355d9 in zend_execute_scripts ()
#6 0x005d5393 in php_execute_script ()
#7 0x006dd433 in ?? ()
#8 0x0042601a in ?? ()
#9 0x7692d725 in __libc_start_main () from /lib/libc.so.6
#10 0x004260ad in _start ()
--
Edit this bug report at https://bugs.php.net/bug.php?id=62839edit=1
Bug #61044 [Com]: invalid PHP_BINDIR
Edit report at https://bugs.php.net/bug.php?id=61044edit=1 ID: 61044 Comment by: martin dot leucht at gmail dot com Reported by:bugzilla33 at gmail dot com Summary:invalid PHP_BINDIR Status: Assigned Type: Bug Package:Unknown/Other Function Operating System: win 7 PHP Version:5.4.0RC7 Assigned To:pajoye Block user comment: N Private report: N New Comment: Just to mention: On my configuration (PHP 5.4.4, Win 7) at least the value for PHP_BINARY is correct. Maybe this helps to create a work-around. Previous Comments: [2012-02-11 11:10:04] johan...@php.net rk, that is correct, but on non-Windows you usually don't relocate the installation. Either you install using your package manager or by compiling yourself with a proper prefix, everything else is unsupported. On Windows we have the installer (which defaults to c:\program files\php (system dependent)) and the zip where people almost certainly won't use c:\php [2012-02-11 08:30:04] rk at srsbiz dot pl It is not only Windows problem: root@core /# /root/src/php5.4-201202102030/sapi/cli/php -r 'echo PHP_BINDIR . PHP_EOL;'; /usr/local/php54/bin root@core /# It always point to directory provided in --prefix at compile time. [2012-02-10 22:19:06] johan...@php.net This is defined while compiling PHP (prefix-option from compile.js), the way to fix this would be to do some run-time detection, not sure whether there's a proper way. [2012-02-10 18:05:38] anon at anon dot anon He's right. This seems to be totally broken on Windows: C:\server\php\php.exe --version PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans C:\server\php\php.exe -r echo PHP_BINDIR; C:\php5 [2012-02-10 13:42:02] bugzilla33 at gmail dot com Description: Install php in folder c:\Php5 As module apache Test script: --- ?php print(PHP_BINDIR); phpinfo(); ? Expected result: c:\Php5 Actual result: -- c:\Php -- Edit this bug report at https://bugs.php.net/bug.php?id=61044edit=1
[PHP-BUG] Bug #62497 [NEW]: array_intersect doesn't work properly when data is reversed with duplicates
From: martin at psinas dot com
Operating system: Linux
PHP version: 5.4.4
Package: Arrays related
Bug Type: Bug
Bug description:array_intersect doesn't work properly when data is reversed
with duplicates
Description:
As mentioned here:
http://us3.php.net/manual/en/function.array-intersect.php#92900
array_intersect doesn't work properly when data is reversed with duplicates
Test script:
---
?php
$text1 = one two two;
$text2 = one two three;
$old = explode(' ', $text1);
$new = explode(' ', $text2);
$preserved1 = array_intersect($old, $new);
$deleted = array_diff($old, $preserved1);
$preserved2 = array_intersect($new, $old);
$inserted = array_diff($new, $preserved2);
echo 'pre';
print_r($preserved1);
print_r($deleted);
print_r($preserved2);
print_r($inserted);
echo 'pre';
?
Expected result:
Array
(
[0] = one
[1] = two
)
Array
(
[2] = three
)
Array
(
[0] = one
[1] = two
)
Array
(
[2] = three
)
Actual result:
--
Array
(
[0] = one
[1] = two
[2] = two
)
Array
(
)
Array
(
[0] = one
[1] = two
)
Array
(
[2] = three
)
--
Edit bug report at https://bugs.php.net/bug.php?id=62497edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62497r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62497r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62497r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62497r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62497r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62497r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62497r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62497r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62497r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62497r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62497r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62497r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62497r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62497r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62497r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62497r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62497r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62497r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62497r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62497r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62497r=mysqlcfg
Bug #62497 [Opn-Csd]: array_intersect doesn't work properly when data is reversed with duplicates
Edit report at https://bugs.php.net/bug.php?id=62497edit=1
ID: 62497
User updated by:martin at psinas dot com
Reported by:martin at psinas dot com
Summary:array_intersect doesn't work properly when data is
reversed with duplicates
-Status: Open
+Status: Closed
Type: Bug
Package:Arrays related
Operating System: Linux
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
not a bug.
Previous Comments:
[2012-07-06 22:30:27] martin at psinas dot com
Description:
As mentioned here:
http://us3.php.net/manual/en/function.array-intersect.php#92900
array_intersect doesn't work properly when data is reversed with duplicates
Test script:
---
?php
$text1 = one two two;
$text2 = one two three;
$old = explode(' ', $text1);
$new = explode(' ', $text2);
$preserved1 = array_intersect($old, $new);
$deleted = array_diff($old, $preserved1);
$preserved2 = array_intersect($new, $old);
$inserted = array_diff($new, $preserved2);
echo 'pre';
print_r($preserved1);
print_r($deleted);
print_r($preserved2);
print_r($inserted);
echo 'pre';
?
Expected result:
Array
(
[0] = one
[1] = two
)
Array
(
[2] = three
)
Array
(
[0] = one
[1] = two
)
Array
(
[2] = three
)
Actual result:
--
Array
(
[0] = one
[1] = two
[2] = two
)
Array
(
)
Array
(
[0] = one
[1] = two
)
Array
(
[2] = three
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62497edit=1
[PHP-BUG] Bug #61855 [NEW]: Wrong division of float numbers
From: Operating system: Linux PHP version: 5.3.10 Package: Math related Bug Type: Bug Bug description:Wrong division of float numbers Description: --- From manual page: http://www.php.net/function.floor#refsect1-function.floor-description --- I encountered problem when dividing float numbers. It's simple formula which can be solved by 10 year old child. But not by PHP! See example. The problem is that displayed value (3) doesn't correspond with internal value 2.999 and floor() then returns 2 which is obviously incorrect result! And that's serious problem. The same code in C returns correct numbers. Test script: --- ?php $a = 1.2; $b = 0.4; $v = $a / $b; printf(v(15) = %.15f\n, $v); printf(v(16) = %.16f\n, $v); print v = $v\n; print floor(v) = .floor($v).\n; ? Expected result: v(15) = 3.000 v(16) = 3. v = 3 floor(v) = 3 Actual result: -- v(15) = 3.000 v(16) = 2.9996 v = 3 floor(v) = 2 -- Edit bug report at https://bugs.php.net/bug.php?id=61855edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61855r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61855r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61855r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61855r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61855r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61855r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61855r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61855r=needscript Try newer version: https://bugs.php.net/fix.php?id=61855r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61855r=support Expected behavior: https://bugs.php.net/fix.php?id=61855r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61855r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61855r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61855r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61855r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61855r=dst IIS Stability: https://bugs.php.net/fix.php?id=61855r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61855r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61855r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61855r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61855r=mysqlcfg
Bug #61855 [Nab]: Wrong division of float numbers
Edit report at https://bugs.php.net/bug.php?id=61855edit=1
ID: 61855
User updated by:martin dot edlman at gmail dot com
Reported by:martin dot edlman at gmail dot com
Summary:Wrong division of float numbers
Status: Not a bug
Type: Bug
Package:Math related
Operating System: Linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Thanks for explanation, I'll modify PHP code to do some round()s or casts to
float to get expected results.
I used float instead of double (which uses less decimal points) in my C code,
so I got correct results.
#include math.h
#include stdio.h
int main(char **argv, int argc) {
float a = 1.2;
float b = 0.4;
float v = a/b;
printf(v(15) = %.15f\n, v);
printf(v(16) = %.16f\n, v);
printf(v = %f\n, v);
printf(floor(v) = %f\n, floor(v));
}
v(15) = 3.000
v(16) = 3.
v = 3.00
floor(v) = 3.00
Previous Comments:
[2012-04-26 07:51:41] ras...@php.net
And just for the record, no, the same C code definitely does not return the
correct numbers as you put it:
#include stdio.h
#include math.h
int main(char *argv[], int argc) {
double a = 1.2;
double b = 0.4;
double v = a/b;
printf(v(15) = %.15f\n, v);
printf(v(16) = %.16f\n, v);
printf(v = %f\n, v);
printf(floor(v) = %f\n,floor(v));
}
That, I hope you would agree, is the closest thing to the same C code.
% cc a.c -o a -lm
% ./a
v(15) = 3.000
v(16) = 2.9996
v = 3.00
floor(v) = 2.00
That looks remarkably like the PHP output.
[2012-04-26 07:33:20] paj...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://www.floating-point-gui.de/
Thank you for your interest in PHP.
[2012-04-26 06:53:50] martin dot edlman at gmail dot com
Description:
---
From manual page:
http://www.php.net/function.floor#refsect1-function.floor-description
---
I encountered problem when dividing float numbers. It's simple formula which
can be solved by 10 year old child. But not by PHP! See example.
The problem is that displayed value (3) doesn't correspond with internal value
2.999 and floor() then returns 2 which is obviously incorrect
result! And that's serious problem.
The same code in C returns correct numbers.
Test script:
---
?php
$a = 1.2;
$b = 0.4;
$v = $a / $b;
printf(v(15) = %.15f\n, $v);
printf(v(16) = %.16f\n, $v);
print v = $v\n;
print floor(v) = .floor($v).\n;
?
Expected result:
v(15) = 3.000
v(16) = 3.
v = 3
floor(v) = 3
Actual result:
--
v(15) = 3.000
v(16) = 2.9996
v = 3
floor(v) = 2
--
Edit this bug report at https://bugs.php.net/bug.php?id=61855edit=1
Req #26411 [Com]: while {} else {}
Edit report at https://bugs.php.net/bug.php?id=26411edit=1
ID: 26411
Comment by: ma-martin at hotmail dot de
Reported by:php at bellytime dot com
Summary:while {} else {}
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
Hey, i was also looking for some while {} else {} feature...
but i think it could be difficult to implement such a function in php.
Because the else{} event would start after the while{}-loop ends - everytime
after the last result!
think about it!
Previous Comments:
[2012-01-25 12:16:57] hawkyhawk14 at gmail dot com
This is a great idea. I am currently needing something like this, but however
got
around it using flags and making the flag true in the while. It would be alot
more
convenient if there was an else!
Please add this feature!!!
[2011-12-06 16:31:22] absimu at hotmail dot com
I agree. I think a while () else () will make things easier. I was researching
and
found out that it doesnt exist yet.
while($row = mysqli_fetch_assoc($result)) { }
with al else I would fix it.. I am new in PHP,. I will try to find something to
fix it. but if the while else is release in a new version that would be nice.
[2011-02-18 01:14:34] ijrbiz at gmail dot com
Highly agreed, this request would be very practical for improved coding
structure and
follows logical language syntax nicely.
function remove_items ($arr, $needle) {
while ($key = array_search($needle, $arr)) {
unset( $arr[$key] );
} else return false; // No items present
return true; // Item(s) removed
}
[2010-12-19 13:08:30] trefighter2334 at aol dot com
I'd love to see something like Python's while/else logic implemented in PHP.
This logical construct would allow developers to define blocks of code in else
{} that'd run upon a natural exit from the while(){} loop caused by said loop's
condition becoming FALSE; however, the else {} would be skipped over if the
loop
exits unnaturally -- a la through a break statement or because of an exception.
It is to die for on a semi-daily basis for me (in python)... but I'm not sure
this is what the developers above (and their examples) have in mind or not.
Either implementation would prove useful to me.
[2008-04-09 07:51:11] ois at oisnot dot com
try {
foreach ($nullValue as $nothing) {
echo 'valid input';
} else {
//suppress notice
echo 'null value';
}
//or/and
} catch (ExceptionObjectNotIterator $e) {
//object doesnt implement Iterator
echo $e-getMessage();
}
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=26411
--
Edit this bug report at https://bugs.php.net/bug.php?id=26411edit=1
Req #61439 [Com]: POST and other methods input data handling
Edit report at https://bugs.php.net/bug.php?id=61439edit=1 ID: 61439 Comment by: martin dot koranda at gmail dot com Reported by:martin dot koranda at gmail dot com Summary:POST and other methods input data handling Status: Open Type: Feature/Change Request Package:*General Issues Operating System: * PHP Version:5.4.0 Block user comment: N Private report: N New Comment: mike: yes that's better, parse it regarding on the request content type. it should be also good if it could automatically parse json or xml input, but main is the multipart. do you think you can push your proposal to some of the next builds? Previous Comments: [2012-03-20 09:01:37] m...@php.net I second that. Actually I've sitting an unfinished proposal in my Inbox' Drafts which addresses this issue. BUT, I'm not thinking about php.ini, but SAPI code shouldn't care about the request method, but the request body's content type. And there should be an API to register content-type handlers. [2012-03-19 17:36:38] martin dot koranda at gmail dot com Description: when sending multipart/form-data via a POST method, PHP internally parses all variables into $_POST and files into $_FILES. but the parsing is not done with any other method (PUT,PATCH,PROPFIND ..) additionally, sending POST with multipart/form-data makes php://input unavailable. so there is no universal parsing solution which covers all methods. there should be a setting option (php.ini) where i can determine which particular methods i want the internal parser run for (eg. parse_input_methods = POST,PUT,PATCH) and/or there should be an option for disabling that internal parser completely. -- Edit this bug report at https://bugs.php.net/bug.php?id=61439edit=1
[PHP-BUG] Req #61439 [NEW]: POST and other methods input data handling
From: Operating system: windows PHP version: 5.4.0 Package: *General Issues Bug Type: Feature/Change Request Bug description:POST and other methods input data handling Description: when sending multipart/form-data via a POST method, PHP internally parses all variables into $_POST and files into $_FILES. but the parsing is not done with any other method (PUT,PATCH,PROPFIND ..) additionally, sending POST with multipart/form-data makes php://input unavailable. so there is no universal parsing solution which covers all methods. there should be a setting option (php.ini) where i can determine which particular methods i want the internal parser run for (eg. parse_input_methods = POST,PUT,PATCH) and/or there should be an option for disabling that internal parser completely. -- Edit bug report at https://bugs.php.net/bug.php?id=61439edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61439r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61439r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61439r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61439r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61439r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61439r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61439r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61439r=needscript Try newer version: https://bugs.php.net/fix.php?id=61439r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61439r=support Expected behavior: https://bugs.php.net/fix.php?id=61439r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61439r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61439r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61439r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61439r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61439r=dst IIS Stability: https://bugs.php.net/fix.php?id=61439r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61439r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61439r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61439r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61439r=mysqlcfg
Bug #60715 [Opn]: Segfault
Edit report at https://bugs.php.net/bug.php?id=60715edit=1
ID: 60715
User updated by:martin at martins-creations dot co dot uk
Reported by:martin at martins-creations dot co dot uk
Summary:Segfault
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Debian
PHP Version:5.4.0RC5
Block user comment: N
Private report: N
New Comment:
Program received signal SIGSEGV, Segmentation fault.
0x0072893b in zend_std_write_property (object=0x77fd6070,
member=0x77fda308, value=0x77fd7cf8, key=optimized out)
at /usr/local/src/php-5.4.0RC5/Zend/zend_object_handlers.c:526
526((variable_ptr =
(zval**)zobj-properties_table[property_info-
offset]) != NULL) :
(gdb) bt
#0 0x0072893b in zend_std_write_property (object=0x77fd6070,
member=0x77fda308, value=0x77fd7cf8, key=optimized out)
at /usr/local/src/php-5.4.0RC5/Zend/zend_object_handlers.c:526
#1 0x00775f07 in zend_assign_to_object (retval=0x0,
object_ptr=0xe257c0,
property_name=0x77fda308, value_type=4, value_op=optimized out, Ts=
optimized out,
opcode=136, key=0x77fda308) at /usr/local/src/php-
5.4.0RC5/Zend/zend_execute.c:738
#2 0x00776934 in ZEND_ASSIGN_OBJ_SPEC_UNUSED_CONST_HANDLER
(execute_data=0x77fa41c0) at /usr/local/src/php-
5.4.0RC5/Zend/zend_vm_execute.h:22003
#3 0x007642df in execute (op_array=0x77fd8d60) at
/usr/local/src/php-5.4.0RC5/Zend/zend_vm_execute.h:410
#4 0x00704db9 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/src/php-5.4.0RC5/Zend/zend.c:1272
#5 0x006a557c in php_execute_script (primary_file=0x7fffe890) at
/usr/local/src/php-5.4.0RC5/main/main.c:2476
#6 0x007ac401 in do_cli (argc=2, argv=0x7fffec68) at
/usr/local/src/php-5.4.0RC5/sapi/cli/php_cli.c:983
#7 0x0042ed5c in main (argc=2, argv=0x7fffec68) at
/usr/local/src/php-5.4.0RC5/sapi/cli/php_cli.c:1356
Previous Comments:
[2012-01-13 17:37:03] martin at martins-creations dot co dot uk
Incorrectly diagnosed as a MySQL fault with no comment, so I changed it back.
[2012-01-11 16:04:46] martin at martins-creations dot co dot uk
I meant I had to compile pdo-mysql as shared
./configure --with-pdo-mysql=shared --enable-fpm --enable-inline-optimization
[2012-01-11 15:44:14] martin at martins-creations dot co dot uk
Description:
I can fix this segfault by either removing the ATTR_PERSISTENT option, or by
assigning parent::prepare to a local variable (i.e. $stmt =
parent::prepare('...'))
Also worth nothing I had to compile PHP as shared due to a bug when trying to
compile the extension with mysqlnd which is filed in a separate report.
Linux localdev 3.1.0-1-amd64 #1 SMP Fri Dec 23 16:37:11 UTC 2011 x86_64
GNU/Linux
$ php -v
PHP 5.4.0RC5 (cli) (built: Jan 10 2012 19:42:22)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
$ phpize -v
Configuring for:
PHP Api Version: 20100412
Zend Module Api No: 20100525
Zend Extension Api No: 220100525
$ cat /etc/issue
Debian GNU/Linux wheezy/sid \n \l
$ mysql --version
mysql Ver 14.14 Distrib 5.1.58, for debian-linux-gnu (x86_64) using readline
6.2
Test script:
---
?php
class BuggedPDO extends PDO {
protected $stmt = null;
public function __construct() {
$options = array(
\PDO::ATTR_PERSISTENT = true,
\PDO::ATTR_ERRMODE = \PDO::ERRMODE_EXCEPTION,
);
try {
parent::__construct('mysql:dbname=testdb;host=localhost', 'testuser',
'testpass', $options);
$this-stmt = parent::prepare('select * from table');
} catch (\Exception $ex) {
var_dump($ex);
}
}
}
$test = new BuggedPDO();
Expected result:
A proper resource in $this-stmt
Actual result:
--
Jan 11 10:26:00 kernel: [ 956.330577] php-fpm[2255]: segfault at 0 ip
00729beb sp 7fffad56c8e0 error 4 in php-fpm[40+76d000]
--
Edit this bug report at https://bugs.php.net/bug.php?id=60715edit=1
Bug #60715 [Opn]: Segfault
Edit report at https://bugs.php.net/bug.php?id=60715edit=1
ID: 60715
User updated by:martin at martins-creations dot co dot uk
Reported by:martin at martins-creations dot co dot uk
Summary:Segfault
Status: Open
Type: Bug
-Package:MySQL related
+Package:Reproducible crash
Operating System: Debian
PHP Version:5.4.0RC5
Block user comment: N
Private report: N
New Comment:
Incorrectly diagnosed as a MySQL fault with no comment, so I changed it back.
Previous Comments:
[2012-01-11 16:04:46] martin at martins-creations dot co dot uk
I meant I had to compile pdo-mysql as shared
./configure --with-pdo-mysql=shared --enable-fpm --enable-inline-optimization
[2012-01-11 15:44:14] martin at martins-creations dot co dot uk
Description:
I can fix this segfault by either removing the ATTR_PERSISTENT option, or by
assigning parent::prepare to a local variable (i.e. $stmt =
parent::prepare('...'))
Also worth nothing I had to compile PHP as shared due to a bug when trying to
compile the extension with mysqlnd which is filed in a separate report.
Linux localdev 3.1.0-1-amd64 #1 SMP Fri Dec 23 16:37:11 UTC 2011 x86_64
GNU/Linux
$ php -v
PHP 5.4.0RC5 (cli) (built: Jan 10 2012 19:42:22)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
$ phpize -v
Configuring for:
PHP Api Version: 20100412
Zend Module Api No: 20100525
Zend Extension Api No: 220100525
$ cat /etc/issue
Debian GNU/Linux wheezy/sid \n \l
$ mysql --version
mysql Ver 14.14 Distrib 5.1.58, for debian-linux-gnu (x86_64) using readline
6.2
Test script:
---
?php
class BuggedPDO extends PDO {
protected $stmt = null;
public function __construct() {
$options = array(
\PDO::ATTR_PERSISTENT = true,
\PDO::ATTR_ERRMODE = \PDO::ERRMODE_EXCEPTION,
);
try {
parent::__construct('mysql:dbname=testdb;host=localhost', 'testuser',
'testpass', $options);
$this-stmt = parent::prepare('select * from table');
} catch (\Exception $ex) {
var_dump($ex);
}
}
}
$test = new BuggedPDO();
Expected result:
A proper resource in $this-stmt
Actual result:
--
Jan 11 10:26:00 kernel: [ 956.330577] php-fpm[2255]: segfault at 0 ip
00729beb sp 7fffad56c8e0 error 4 in php-fpm[40+76d000]
--
Edit this bug report at https://bugs.php.net/bug.php?id=60715edit=1
[PHP-BUG] Bug #60715 [NEW]: Segfault
From:
Operating system: Debian
PHP version: 5.4.0RC5
Package: Reproducible crash
Bug Type: Bug
Bug description:Segfault
Description:
I can fix this segfault by either removing the ATTR_PERSISTENT option, or
by
assigning parent::prepare to a local variable (i.e. $stmt =
parent::prepare('...'))
Also worth nothing I had to compile PHP as shared due to a bug when trying
to
compile the extension with mysqlnd which is filed in a separate report.
Linux localdev 3.1.0-1-amd64 #1 SMP Fri Dec 23 16:37:11 UTC 2011 x86_64
GNU/Linux
$ php -v
PHP 5.4.0RC5 (cli) (built: Jan 10 2012 19:42:22)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
$ phpize -v
Configuring for:
PHP Api Version: 20100412
Zend Module Api No: 20100525
Zend Extension Api No: 220100525
$ cat /etc/issue
Debian GNU/Linux wheezy/sid \n \l
$ mysql --version
mysql Ver 14.14 Distrib 5.1.58, for debian-linux-gnu (x86_64) using
readline 6.2
Test script:
---
?php
class BuggedPDO extends PDO {
protected $stmt = null;
public function __construct() {
$options = array(
\PDO::ATTR_PERSISTENT = true,
\PDO::ATTR_ERRMODE = \PDO::ERRMODE_EXCEPTION,
);
try {
parent::__construct('mysql:dbname=testdb;host=localhost', 'testuser',
'testpass', $options);
$this-stmt = parent::prepare('select * from table');
} catch (\Exception $ex) {
var_dump($ex);
}
}
}
$test = new BuggedPDO();
Expected result:
A proper resource in $this-stmt
Actual result:
--
Jan 11 10:26:00 kernel: [ 956.330577] php-fpm[2255]: segfault at 0 ip
00729beb sp 7fffad56c8e0 error 4 in php-fpm[40+76d000]
--
Edit bug report at https://bugs.php.net/bug.php?id=60715edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60715r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60715r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60715r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60715r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60715r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60715r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60715r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60715r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60715r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60715r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60715r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60715r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60715r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60715r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60715r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60715r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60715r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60715r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60715r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60715r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60715r=mysqlcfg
Bug #60715 [Opn]: Segfault
Edit report at https://bugs.php.net/bug.php?id=60715edit=1
ID: 60715
User updated by:martin at martins-creations dot co dot uk
Reported by:martin at martins-creations dot co dot uk
Summary:Segfault
Status: Open
Type: Bug
Package:MySQL related
Operating System: Debian
PHP Version:5.4.0RC5
Block user comment: N
Private report: N
New Comment:
I meant I had to compile pdo-mysql as shared
./configure --with-pdo-mysql=shared --enable-fpm --enable-inline-optimization
Previous Comments:
[2012-01-11 15:44:14] martin at martins-creations dot co dot uk
Description:
I can fix this segfault by either removing the ATTR_PERSISTENT option, or by
assigning parent::prepare to a local variable (i.e. $stmt =
parent::prepare('...'))
Also worth nothing I had to compile PHP as shared due to a bug when trying to
compile the extension with mysqlnd which is filed in a separate report.
Linux localdev 3.1.0-1-amd64 #1 SMP Fri Dec 23 16:37:11 UTC 2011 x86_64
GNU/Linux
$ php -v
PHP 5.4.0RC5 (cli) (built: Jan 10 2012 19:42:22)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
$ phpize -v
Configuring for:
PHP Api Version: 20100412
Zend Module Api No: 20100525
Zend Extension Api No: 220100525
$ cat /etc/issue
Debian GNU/Linux wheezy/sid \n \l
$ mysql --version
mysql Ver 14.14 Distrib 5.1.58, for debian-linux-gnu (x86_64) using readline
6.2
Test script:
---
?php
class BuggedPDO extends PDO {
protected $stmt = null;
public function __construct() {
$options = array(
\PDO::ATTR_PERSISTENT = true,
\PDO::ATTR_ERRMODE = \PDO::ERRMODE_EXCEPTION,
);
try {
parent::__construct('mysql:dbname=testdb;host=localhost', 'testuser',
'testpass', $options);
$this-stmt = parent::prepare('select * from table');
} catch (\Exception $ex) {
var_dump($ex);
}
}
}
$test = new BuggedPDO();
Expected result:
A proper resource in $this-stmt
Actual result:
--
Jan 11 10:26:00 kernel: [ 956.330577] php-fpm[2255]: segfault at 0 ip
00729beb sp 7fffad56c8e0 error 4 in php-fpm[40+76d000]
--
Edit this bug report at https://bugs.php.net/bug.php?id=60715edit=1
[PHP-BUG] Bug #60706 [NEW]: Unable to compile pdo_mysql with mysqlnd
From: Operating system: Debian PHP version: 5.4.0RC5 Package: PDO related Bug Type: Bug Bug description:Unable to compile pdo_mysql with mysqlnd Description: Initially I was getting: /usr/local/src/php-5.4.0RC4/ext/pdo_mysql/php_pdo_mysql_int.h:27:34: fatal error: ext/mysqlnd/mysqlnd.h: No such file or directory so I did a mkdir ext cp -r ../mysqlnd ./ext to fix the path issue. # php -v PHP 5.4.0RC4 (cli) (built: Jan 3 2012 12:00:03) # phpize -v Configuring for: PHP Api Version: 20100412 Zend Module Api No: 20100525 Zend Extension Api No: 220100525 Test script: --- phpize ./configure make make install Expected result: Successful compilation Actual result: -- In file included from /usr/local/src/php- 5.4.0RC4/ext/pdo_mysql/ext/mysqlnd/mysqlnd.h:60:0, from /usr/local/src/php- 5.4.0RC4/ext/pdo_mysql/php_pdo_mysql_int.h:27, from /usr/local/src/php-5.4.0RC4/ext/pdo_mysql/pdo_mysql.c:32: /usr/local/src/php- 5.4.0RC4/ext/pdo_mysql/ext/mysqlnd/mysqlnd_portability.h:40:46: fatal error: ext/mysqlnd/php_mysqlnd_config.h: No such file or directory sure enough: total 804 drwxr-xr-x 2 root root 4096 Jan 10 18:27 . drwxr-xr-x 3 root root 4096 Jan 10 18:33 .. -rw-r--r-- 1 root root 2230 Jan 10 18:27 config9.m4 -rw-r--r-- 1 root root 1172 Jan 10 18:27 config.w32 -rw-r--r-- 1 root root 3312 Jan 10 18:27 config-win.h -rw-r--r-- 1 root root50 Jan 10 18:27 CREDITS -rw-r--r-- 1 root root 20160 Jan 10 18:27 mysqlnd_alloc.c -rw-r--r-- 1 root root 5934 Jan 10 18:27 mysqlnd_alloc.h -rw-r--r-- 1 root root 16643 Jan 10 18:27 mysqlnd_auth.c -rw-r--r-- 1 root root 5955 Jan 10 18:27 mysqlnd_block_alloc.c -rw-r--r-- 1 root root 1750 Jan 10 18:27 mysqlnd_block_alloc.h -rw-r--r-- 1 root root 14026 Jan 10 18:27 mysqlnd_bt.c -rw-r--r-- 1 root root 85349 Jan 10 18:27 mysqlnd.c -rw-r--r-- 1 root root 28599 Jan 10 18:27 mysqlnd_charset.c -rw-r--r-- 1 root root 2450 Jan 10 18:27 mysqlnd_charset.h -rw-r--r-- 1 root root 24722 Jan 10 18:27 mysqlnd_debug.c -rw-r--r-- 1 root root 7552 Jan 10 18:27 mysqlnd_debug.h -rw-r--r-- 1 root root 9753 Jan 10 18:27 mysqlnd_driver.c -rw-r--r-- 1 root root 17588 Jan 10 18:27 mysqlnd_enum_n_def.h -rw-r--r-- 1 root root 6530 Jan 10 18:27 mysqlnd_ext_plugin.c -rw-r--r-- 1 root root 3941 Jan 10 18:27 mysqlnd_ext_plugin.h -rw-r--r-- 1 root root 17025 Jan 10 18:27 mysqlnd.h -rw-r--r-- 1 root root 7534 Jan 10 18:27 mysqlnd_libmysql_compat.h -rw-r--r-- 1 root root 7651 Jan 10 18:27 mysqlnd_loaddata.c -rw-r--r-- 1 root root 36242 Jan 10 18:27 mysqlnd_net.c -rw-r--r-- 1 root root 1812 Jan 10 18:27 mysqlnd_net.h -rw-r--r-- 1 root root 5660 Jan 10 18:27 mysqlnd_plugin.c -rw-r--r-- 1 root root 19302 Jan 10 18:27 mysqlnd_portability.h -rw-r--r-- 1 root root 8949 Jan 10 18:27 mysqlnd_priv.h -rw-r--r-- 1 root root 73074 Jan 10 18:27 mysqlnd_ps.c -rw-r--r-- 1 root root 30964 Jan 10 18:27 mysqlnd_ps_codec.c -rw-r--r-- 1 root root 55262 Jan 10 18:27 mysqlnd_result.c -rw-r--r-- 1 root root 1780 Jan 10 18:27 mysqlnd_result.h -rw-r--r-- 1 root root 15375 Jan 10 18:27 mysqlnd_result_meta.c -rw-r--r-- 1 root root 1917 Jan 10 18:27 mysqlnd_result_meta.h -rw-r--r-- 1 root root 2845 Jan 10 18:27 mysqlnd_reverse_api.c -rw-r--r-- 1 root root 2019 Jan 10 18:27 mysqlnd_reverse_api.h -rw-r--r-- 1 root root 12464 Jan 10 18:27 mysqlnd_statistics.c -rw-r--r-- 1 root root 7945 Jan 10 18:27 mysqlnd_statistics.h -rw-r--r-- 1 root root 49400 Jan 10 18:27 mysqlnd_structs.h -rw-r--r-- 1 root root 77671 Jan 10 18:27 mysqlnd_wireprotocol.c -rw-r--r-- 1 root root 9884 Jan 10 18:27 mysqlnd_wireprotocol.h -rw-r--r-- 1 root root 12009 Jan 10 18:27 php_mysqlnd.c -rw-r--r-- 1 root root 1648 Jan 10 18:27 php_mysqlnd.h That file doesn't exist. -- Edit bug report at https://bugs.php.net/bug.php?id=60706edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60706r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60706r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60706r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60706r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60706r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60706r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60706r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60706r=needscript Try newer version: https://bugs.php.net/fix.php?id=60706r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60706r=support Expected behavior: https://bugs.php.net/fix.php?id=60706r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60706r=notenoughinfo Submitted twice:
Bug #60196 [Opn-Csd]: Session Upload Progress - doesn't work
Edit report at https://bugs.php.net/bug.php?id=60196edit=1
ID: 60196
User updated by:martin at psinas dot com
Reported by:martin at psinas dot com
Summary:Session Upload Progress - doesn't work
-Status: Open
+Status: Closed
Type: Bug
Package:Session related
Operating System: Ubuntu 10.04 / Apache2
PHP Version:5.4.0beta2
Block user comment: N
Private report: N
New Comment:
I believe my installation was not configured correctly. I re-installed 5.4
following the instructions of a friend and everything worked.
Previous Comments:
[2011-12-17 19:06:35] crmalibu at gmail dot com
This seems like expected behavior if session.upload_progress.cleanup = On,
which is default. By the time his var_dump() script executes(even with a huge
file), the upload is finished, and cleanup has already occurred.
Even though the setting is documented here
http://www.php.net/manual/en/session.configuration.php#ini.session.upload-progress.cleanup
I feel strongly it needs to be mentioned here too, or you will get swarmed with
bogus bug reports soon when this feature goes live.
http://www.php.net/manual/en/session.upload-progress.php
[2011-11-02 08:51:08] martin at psinas dot com
How do you define huge? I've modified the form to contain 8 fields instead of
2, and in each field I'm uploading the php-5.4.0beta2.tar.gz (13.6 MB * 8). The
form hangs for a few seconds while loading, then I get the empty array.
[2011-11-02 03:18:05] larue...@php.net
plz use a huge size file to test.
[2011-11-01 23:34:07] martin at psinas dot com
Description:
Trying to test this new feature documented here:
http://php.net/manual/en/session.upload-progress.php
Can't seem to get it working.
Test script:
---
// form.php
?php
session_start();
?
form action=upload.php method=POST enctype=multipart/form-data
input type=hidden name=?php echo ini_get(session.upload_progress.name);
? value=123 /
input type=file name=file1 /
input type=file name=file2 /
input type=submit /
/form
// upload.php
?php
session_start();
var_dump($_SESSION);
?
Expected result:
I expect the following session values to be populated:
?php
$_SESSION[upload_progress_123] = array(
start_time = 1234567890, // The request time
content_length = 57343257, // POST content length
bytes_processed = 453489, // Amount of bytes received and processed
done = false, // true when the POST handler has finished,
successfully or not
files = array(
0 = array(
field_name = file1, // Name of the input/ field
// The following 3 elements equals those in $_FILES
name = foo.avi,
tmp_name = /tmp/phpxx,
error = 0,
done = true,// True when the POST handler has finished
handling this file
start_time = 1234567890,// When this file has started to be processed
bytes_processed = 57343250, // Amount of bytes received and processed for
this file
),
// An other file, not finished uploading, in the same request
1 = array(
field_name = file2,
name = bar.avi,
tmp_name = NULL,
error = 0,
done = false,
start_time = 1234567899,
bytes_processed = 54554,
),
)
);
?
Actual result:
--
I get this:
array(0) {}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60196edit=1
Bug #60290 [Bgs]: Apc.php – Wrong use of var_export
Edit report at https://bugs.php.net/bug.php?id=60290edit=1 ID: 60290 User updated by:klaus-martin dot hansche at kvberlin dot de Reported by:klaus-martin dot hansche at kvberlin dot de Summary:Apc.php â Wrong use of var_export Status: Bogus Type: Bug Package:APC Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Please, remove this report and my mail-address immediately. And think about not publishing unconfirmed addresses anymore. Previous Comments: [2011-11-15 20:46:36] ras...@php.net var_export($var, true) is quite valid and tells var_export to return the exported string instead of outputting it. See http://php.net/var_export [2011-11-14 06:57:45] klaus-martin dot hansche at kvberlin dot de Description: Apc.php line 1000 should be $output = var_export(apc_fetch($entry[$fieldkey])); instead of $output = var_export(apc_fetch($entry[$fieldkey]),true); The last parameter of var_export is a reference to a boolean var. -- Edit this bug report at https://bugs.php.net/bug.php?id=60290edit=1
[PHP-BUG] Bug #60290 [NEW]: Apc.php – Wrong use of var_export
From: Operating system: Irrelevant PHP version: Irrelevant Package: APC Bug Type: Bug Bug description:Apc.php â Wrong use of var_export Description: Apc.php line 1000 should be $output = var_export(apc_fetch($entry[$fieldkey])); instead of $output = var_export(apc_fetch($entry[$fieldkey]),true); The last parameter of var_export is a reference to a boolean var. -- Edit bug report at https://bugs.php.net/bug.php?id=60290edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60290r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60290r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60290r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60290r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60290r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60290r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60290r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60290r=needscript Try newer version: https://bugs.php.net/fix.php?id=60290r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60290r=support Expected behavior: https://bugs.php.net/fix.php?id=60290r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60290r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60290r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60290r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60290r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60290r=dst IIS Stability: https://bugs.php.net/fix.php?id=60290r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60290r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60290r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60290r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60290r=mysqlcfg
Bug #49311 [Com]: WAKE, enigma and arcfour ciphers fail to initialize
Edit report at https://bugs.php.net/bug.php?id=49311edit=1
ID: 49311
Comment by: vseticka dot martin at gmail dot com
Reported by:c58999 at tyldd dot com
Summary:WAKE, enigma and arcfour ciphers fail to initialize
Status: No Feedback
Type: Bug
Package:mcrypt related
Operating System: Windows
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
http://stackoverflow.com/questions/8040901/how-to-encrypt-with-mcrypt-arcfour-in-wamp/8041271
- this question shows that the bug seems to be still present.
Previous Comments:
[2009-09-27 01:00:02] 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.
[2009-09-19 14:48:25] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-08-20 15:06:57] c58999 at tyldd dot com
Description:
The arcfour algoritm fails to initialize on PHP 5.3.0 win32. This also appears
to happen with the wake and enigma ciphers. I could also reproduce this
behaviour on PHP 5.2.6-2ubuntu4.2.
Reproduce code:
---
$algs = mcrypt_list_algorithms();
foreach($algs as $alg){
echo $alg\n;
$td = mcrypt_module_open($alg, '', 'ecb', '');
echo \n;
}
Expected result:
I would expect this code to execute without any errors.
Actual result:
--
C:\phpphp mcrypt.php
cast-128
gost
rijndael-128
twofish
cast-256
loki97
rijndael-192
saferplus
wake
PHP Warning: mcrypt_module_open(): Could not open encryption module in
C:\php\mcrypt.php on line 6
blowfish-compat
des
rijndael-256
serpent
xtea
blowfish
enigma
PHP Warning: mcrypt_module_open(): Could not open encryption module in
C:\php\mcrypt.php on line 6
rc2
tripledes
arcfour
PHP Warning: mcrypt_module_open(): Could not open encryption module in
C:\php\mcrypt.php on line 6
--
Edit this bug report at https://bugs.php.net/bug.php?id=49311edit=1
Bug #30195 [Com]: scandir etc cannot read Chinese file/folder name
Edit report at https://bugs.php.net/bug.php?id=30195edit=1
ID: 30195
Comment by: martin dot keckeis1 at gmail dot com
Reported by:percy at savant dot us
Summary:scandir etc cannot read Chinese file/folder name
Status: No Feedback
Type: Bug
Package:*Directory/Filesystem functions
Operating System: windows xp/2003
PHP Version:5CVS-2004-09-22 (dev)
Block user comment: N
Private report: N
New Comment:
Its a problem in PHP general.
This could have been solved with PHP 6.0 (general multibyte support).
There are some workarounds in the internet with the windows console.
Previous Comments:
[2011-06-07 00:08:23] spidgorny at gmail dot com
Same problem (files with question marks) with Russian files in PHP 5.3.0 on
Windows 7.
mb_convert_encoding() can't help converting question marks.
Maybe DirectoryIterator will help.
[2010-08-29 18:13:24] onekamil at gmail dot com
Hi, have the same problem and my solution is: using mb_convert_encoding.
$open = opendir($path);
foreach( $open as $value )
{
$value = mb_convert_encoding($value, mb_detect_order($value), UTF-8);
}
If saving file to folder using urlencode. To view using urldecode.
[2007-03-31 23:30:05] missingno at ifrance dot com
Same problem here.
On WinXP with PHP 5.2.0, using iso-8859-1 as charset for the system (though the
filesystem uses utf-8 for folders/files names).
I need to access folders whose names are encoded using UTF-8.
readdir/scandir won't allow me to do so (returning '?' for characters outside
the system charset).
The page is served like this:
header('Content-Type: text/html; charset=utf-8');
So the browser really isn't at fault.
Serving the document with a more specific charset is not an option since I have
to display texts in many different languages on the page.
As moleary at preg dot org suggested, it would be really nice to have an option
to force PHP to use a certain encoding while accessing the filesystem. Or
maybe, make it so that it uses the same encoding as the filesystem instead of
defaulting to iso-8859-1...
[2006-07-10 10:02:31] gandhavallakiran at yahoo dot co dot in
hi i have used the babel class in my coding of php. but it could not read the
characters of china and japan i.e. special characters. it is displaying the
blank space instead of china or japan text. could you help me in this reacord
how to display china characters in php. please it is very urgent kindly help me.
[2005-02-25 01:00:07] 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
https://bugs.php.net/bug.php?id=30195
--
Edit this bug report at https://bugs.php.net/bug.php?id=30195edit=1
Bug #60196 [Bgs]: Session Upload Progress - doesn't work
Edit report at https://bugs.php.net/bug.php?id=60196edit=1
ID: 60196
User updated by:martin at psinas dot com
Reported by:martin at psinas dot com
Summary:Session Upload Progress - doesn't work
Status: Bogus
Type: Bug
Package:Session related
Operating System: Ubuntu 10.04 / Apache2
PHP Version:5.4.0beta2
Block user comment: N
Private report: N
New Comment:
How do you define huge? I've modified the form to contain 8 fields instead of
2, and in each field I'm uploading the php-5.4.0beta2.tar.gz (13.6 MB * 8). The
form hangs for a few seconds while loading, then I get the empty array.
Previous Comments:
[2011-11-02 03:18:05] larue...@php.net
plz use a huge size file to test.
[2011-11-01 23:34:07] martin at psinas dot com
Description:
Trying to test this new feature documented here:
http://php.net/manual/en/session.upload-progress.php
Can't seem to get it working.
Test script:
---
// form.php
?php
session_start();
?
form action=upload.php method=POST enctype=multipart/form-data
input type=hidden name=?php echo ini_get(session.upload_progress.name);
? value=123 /
input type=file name=file1 /
input type=file name=file2 /
input type=submit /
/form
// upload.php
?php
session_start();
var_dump($_SESSION);
?
Expected result:
I expect the following session values to be populated:
?php
$_SESSION[upload_progress_123] = array(
start_time = 1234567890, // The request time
content_length = 57343257, // POST content length
bytes_processed = 453489, // Amount of bytes received and processed
done = false, // true when the POST handler has finished,
successfully or not
files = array(
0 = array(
field_name = file1, // Name of the input/ field
// The following 3 elements equals those in $_FILES
name = foo.avi,
tmp_name = /tmp/phpxx,
error = 0,
done = true,// True when the POST handler has finished
handling this file
start_time = 1234567890,// When this file has started to be processed
bytes_processed = 57343250, // Amount of bytes received and processed for
this file
),
// An other file, not finished uploading, in the same request
1 = array(
field_name = file2,
name = bar.avi,
tmp_name = NULL,
error = 0,
done = false,
start_time = 1234567899,
bytes_processed = 54554,
),
)
);
?
Actual result:
--
I get this:
array(0) {}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60196edit=1
[PHP-BUG] Bug #60203 [NEW]: Session upload progress does not work
From:
Operating system: Ubuntu 10.04 / Apache2
PHP version: 5.4.0beta2
Package: Session related
Bug Type: Bug
Bug description:Session upload progress does not work
Description:
Bogus bug is not bogus: https://bugs.php.net/bug.php?id=60196
I've tried small files and large files, no session data is ever returned.
Test script:
---
// form.php
?php
session_start();
?
form action=upload.php method=POST enctype=multipart/form-data
input type=hidden name=?php echo
ini_get(session.upload_progress.name); ? value=123 /
input type=file name=file1 /
input type=file name=file2 /
input type=submit /
/form
// upload.php
?php
session_start();
var_dump($_SESSION);
?
Expected result:
Anything other than: array(0) {}
Actual result:
--
array(0) {}
--
Edit bug report at https://bugs.php.net/bug.php?id=60203edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60203r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60203r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60203r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60203r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60203r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60203r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60203r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60203r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60203r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60203r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60203r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60203r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60203r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60203r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60203r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60203r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60203r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60203r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60203r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60203r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60203r=mysqlcfg
[PHP-BUG] Bug #60196 [NEW]: Session Upload Progress - doesn't work
From:
Operating system: Ubuntu 10.04 / Apache2
PHP version: 5.4.0beta2
Package: Session related
Bug Type: Bug
Bug description:Session Upload Progress - doesn't work
Description:
Trying to test this new feature documented here:
http://php.net/manual/en/session.upload-progress.php
Can't seem to get it working.
Test script:
---
// form.php
?php
session_start();
?
form action=upload.php method=POST enctype=multipart/form-data
input type=hidden name=?php echo
ini_get(session.upload_progress.name); ? value=123 /
input type=file name=file1 /
input type=file name=file2 /
input type=submit /
/form
// upload.php
?php
session_start();
var_dump($_SESSION);
?
Expected result:
I expect the following session values to be populated:
?php
$_SESSION[upload_progress_123] = array(
start_time = 1234567890, // The request time
content_length = 57343257, // POST content length
bytes_processed = 453489, // Amount of bytes received and processed
done = false, // true when the POST handler has finished,
successfully or not
files = array(
0 = array(
field_name = file1, // Name of the input/ field
// The following 3 elements equals those in $_FILES
name = foo.avi,
tmp_name = /tmp/phpxx,
error = 0,
done = true,// True when the POST handler has
finished
handling this file
start_time = 1234567890,// When this file has started to be
processed
bytes_processed = 57343250, // Amount of bytes received and processed
for
this file
),
// An other file, not finished uploading, in the same request
1 = array(
field_name = file2,
name = bar.avi,
tmp_name = NULL,
error = 0,
done = false,
start_time = 1234567899,
bytes_processed = 54554,
),
)
);
?
Actual result:
--
I get this:
array(0) {}
--
Edit bug report at https://bugs.php.net/bug.php?id=60196edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60196r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60196r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60196r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60196r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60196r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60196r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60196r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60196r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60196r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60196r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60196r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60196r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60196r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60196r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60196r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60196r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60196r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60196r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60196r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60196r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60196r=mysqlcfg
[PHP-BUG] Bug #60172 [NEW]: make fails
From: Operating system: Ubuntu 10.04 / Apache2 PHP version: 5.4SVN-2011-10-29 (snap) Package: Compile Failure Bug Type: Bug Bug description:make fails Description: I already have PHP installed, trying to upgrade to latest development version. I'm using Ubuntu 10.04 w/ Apache2. Test script: --- worm@worm-desktop:~$ wget http://snaps.php.net/php5.4-201110292230.tar.gz worm@worm-desktop:~$ tar -xvzf php5.4-201110292230.tar.gz worm@worm-desktop:~$ cd php5.4-201110292230 worm@worm-desktop:~/php5.4-201110292230$ ./configure worm@worm-desktop:~/php5.4-201110292230$ sudo make Actual result: -- /php5.4-201110292230/ext/sqlite3/libsqlite -I/home/worm/php5.4-201110292230/TSRM -I/home/worm/php5.4-201110292230/Zend-I/usr/include -g -O2 - fvisibility=hidden -DZEND_SIGNALS -c /home/worm/php5.4- 201110292230/Zend/zend_ini_parser.c -o Zend/zend_ini_parser.lo cc: /home/worm/php5.4-201110292230/Zend/zend_ini_parser.c: No such file or directory cc: no input files make: *** [Zend/zend_ini_parser.lo] Error 1 -- Edit bug report at https://bugs.php.net/bug.php?id=60172edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60172r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60172r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60172r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60172r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60172r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60172r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60172r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60172r=needscript Try newer version: https://bugs.php.net/fix.php?id=60172r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60172r=support Expected behavior: https://bugs.php.net/fix.php?id=60172r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60172r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60172r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60172r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60172r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60172r=dst IIS Stability: https://bugs.php.net/fix.php?id=60172r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60172r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60172r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60172r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60172r=mysqlcfg
Bug #53735 [Com]: NumberFormatter returns NaN when converting float point
Edit report at https://bugs.php.net/bug.php?id=53735edit=1 ID: 53735 Comment by: martin at tajur dot ee Reported by:mortenskyt at gmail dot com Summary:NumberFormatter returns NaN when converting float point Status: Open Type: Bug Package:I18N and L10N related Operating System: MacOS X 10.6.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: The exact same thing happens on all Debian Squeeze installations, given that php5- intl bundle is installed from the default debian package sources. The error appears right after switching locale to something other than default (en, presumably) and trying to format a number with a comma using NumberFormatter. I was able to fix the issue on Debian Lenny by manually downgrading ICU library to 3.8 but ICU 3.8 does not work on Squeeze which raises importance of this issue even more. Previous Comments: [2011-01-24 01:36:31] s...@php.net I works for me with ICU 4.3.4. Maybe they broke something in 4.6... May be related to this ticket: http://bugs.icu-project.org/trac/ticket/6711 [2011-01-22 13:40:59] mortenskyt at gmail dot com Hello again, On my Mac with PHP 5.3.5 from Macports: Internationalization support = enabled version = 1.1.0 ICU version = 4.6 (same version on non-working FreeBSD PHP 5.3.4-machine) The FreeBSD-machine with PHP 5.3.3, which works with no issues: Internationalization support = enabled version = 1.0.3 ICU version = 3.8.1 [2011-01-22 08:41:40] s...@php.net Works for me in 5.3 on Mac OS X. Which ICU version do you have (check phpinfo())? [2011-01-13 14:46:59] mortenskyt at gmail dot com Description: In PHP 5.3.5, giving float point values to numfmt_format doesn't work when setlocale is set to a country using comma instead of dot in floating point. Also does not work in PHP 5.3.4 (FreeBSD) DOES work on 5.3.3 (FreeBSD) Perhaps interesting notes from my configuration: intl Internationalization support = enabled version = 1.1.0 ICU version = 4.6 Directive = Local Value = Master Value intl.default_locale = no value = no value intl.error_level = 0 = 0 Test script: --- ?php $fmt = numfmt_create(da_DK, \NumberFormatter::CURRENCY); echo numfmt_format($fmt, 5.5).\n; setlocale(LC_ALL, da_DK.UTF-8); echo numfmt_format($fmt, 5.5).\n; echo numfmt_format($fmt, 5,5).\n; Expected result: 5,50 kr 5,50 kr 5,00 kr Actual result: -- 5,50 kr NaN 5,00 kr -- Edit this bug report at https://bugs.php.net/bug.php?id=53735edit=1
Bug #54140 [Com]: array_merge() break keys during merge
Edit report at http://bugs.php.net/bug.php?id=54140edit=1
ID: 54140
Comment by: martin at fleveo dot cz
Reported by:forjest at gmail dot com
Summary:array_merge() break keys during merge
Status: Open
Type: Bug
Package:Arrays related
Operating System: *Nix
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
This bug is on Windows 7 too (same version of PHP).
Previous Comments:
[2011-03-09 19:27:38] cybd at bigmir dot net
Maybe, simpler example.
OK:
$c = array('01'=3, '03'=10);
$d = array('05'=44, '07'=3);
var_dump(array_merge($c,$d));
Failed:
$a = array('01'=1, '02'=73);
$b = array('10'=11, '11'=23);
var_dump(array_merge($a,$b));
[2011-03-02 19:03:46] forjest at gmail dot com
Works as expected on Windows platform.
[2011-03-02 18:21:06] forjest at gmail dot com
Description:
array_merge interprets string keys, containing only digits as numeric
keys, if numeric overflow not reached.
String keys should works as strings regarless of their contents.
Test script:
---
var_dump(array_merge(array('t777'= array(I'm a string;
var_dump(array_merge(array(42424242= array(I'm a string of
digits;
var_dump(array_merge(array(7=
array(I'm string of digits too;
var_dump(is_string(42424242));
var_dump(is_string(42424242));
var_dump(is_string(7));
Expected result:
array(1) {
[t777]=
array(1) {
[0]=
string(12) I'm a string
}
}
array(1) {
[42424242]=
array(1) {
[0]=
string(22) I'm a string of digits
}
}
array(1) {
[7]=
array(1) {
[0]=
string(24) I'm string of digits too
}
}
bool(true)
bool(false)
bool(true)
Actual result:
--
array(1) {
[t777]=
array(1) {
[0]=
string(12) I'm a string
}
}
array(1) {
[0]=
array(1) {
[0]=
string(22) I'm a string of digits
}
}
array(1) {
[7]=
array(1) {
[0]=
string(24) I'm string of digits too
}
}
bool(true)
bool(false)
bool(true)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54140edit=1
[PHP-BUG] Req #54078 [NEW]: Array / string functions parameter inconsistence
From: Operating system: PHP version: 5.3.5 Package: *General Issues Bug Type: Feature/Change Request Bug description:Array / string functions parameter inconsistence Description: In the string and array functions the $needle and $haystack parameter doesn't have the same order. From the documentation: int stripos ( string $haystack , string $needle [, int $offset = 0 ] ) mixed array_search ( mixed $needle , array $haystack [, bool $strict ] ) This is a very confusing inconsistence for me, since I program now PHP for several years, I cannot accustom on this. And I'm sure not the only one - maybe a change for the next version 5.4 or 6.0? Best regards Martin -- Edit bug report at http://bugs.php.net/bug.php?id=54078edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54078r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54078r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54078r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54078r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54078r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54078r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54078r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54078r=needscript Try newer version: http://bugs.php.net/fix.php?id=54078r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54078r=support Expected behavior: http://bugs.php.net/fix.php?id=54078r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54078r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54078r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54078r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54078r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54078r=dst IIS Stability: http://bugs.php.net/fix.php?id=54078r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54078r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54078r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54078r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54078r=mysqlcfg
[PHP-BUG] Req #54076 [NEW]: Feature request - function array_walk_recursive
From:
Operating system: All
PHP version: 5.3.5
Package: Arrays related
Bug Type: Feature/Change Request
Bug description:Feature request - function array_walk_recursive
Description:
---
From manual page:
http://www.php.net/function.array-walk-recursive#Parameters
---
This function does not send arrays to the callback function, and in most
cases this is what you want, but sometimes you may need at least the keys
of the arrays (example below). My suggestion is to add a fourth parameter
to this function which takes a boolean value, and defaults to FALSE. The
callback function can then handle the arrays and their keys if this
parameter is set to TRUE.
One usage for this feature would be if you want to make a custom function
for serializing an array and all its content. A serialized string must
contain the keys of child arrays, else the custom unserializer will be
unable to restore child arrays properly. A custom serializer may be able to
make binary strings rather than human-readable strings like serialize()
does, which will save a lot of space e.g. when storing $_SESSION data in a
database.
Additionally, this feature would also allow custom output of arrays in a
human-friendly way, especially if the callback function can get the depth
of the iteration (see the code example below).
Test script:
---
function awr_callback($val, $key, $ptr, $depth = 0) {
$indent = str_pad('', $depth, ' ');
if (is_array($val)) $ptr[0] .= ${indent}Array '$key' ( . count($val) .
):\n;
elseif (is_string($val)) $ptr[0] .= ${indent}String '$key' ( .
strlen($val) . ): $val\n;
// ...
}
$a = array('beginning', 'first child' = array('an element', 'another
element'), 'end');
$s = '';
array_walk_recursive($a, 'awr_callback', array($s), true);
echo $s;
// This short example is written to demonstrate usage of the suggested
features, and will not work with the current version of PHP.
Expected result:
Expected output when/if the features are implemented:
String '0' (9): beginning
Array 'first child' (2):
String '0' (10): an element
String '1' (15): another element
String '1' (3): end
Actual result:
--
Actual output (if you first remove the fourth input parameter when calling
array_walk_recursive):
String '0' (9): beginning
String '0' (10): an element
String '1' (15): another element
String '1' (3): end
--
Edit bug report at http://bugs.php.net/bug.php?id=54076edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54076r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54076r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54076r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54076r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54076r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54076r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54076r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54076r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54076r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54076r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54076r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54076r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54076r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54076r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54076r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54076r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54076r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54076r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54076r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54076r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54076r=mysqlcfg
[PHP-BUG] Bug #53989 [NEW]: Notice: Undefined variable/index with xor, but not with or
From: Operating system: Tested only with Windows PHP version: 5.3.5 Package: Scripting Engine problem Bug Type: Bug Bug description:Notice: Undefined variable/index with xor, but not with or Description: I want to check, if a variable is not set. If the variable is not set, i want to check, if this variable has a special value. There is no problem with or, but with xor outputs a notice. Test script: --- ? session_start(); if(!isset($_SESSION['foo']) xor $_SESSION['foo'] == 1) echo foo; if(!isset($bar) xor $bar== 1) echo bar; if(!isset($_SESSION['foo']) or $_SESSION['foo'] == 1) echo foo; if(!isset($bar) or $bar== 1) echo bar; ? Expected result: foobarfoobar Actual result: -- Notice: Undefined index: foo in C:\xampp\htdocs\feredoras\testing.php on line 4 foo Notice: Undefined variable: bar in C:\xampp\htdocs\feredoras\testing.php on line 5 barfoobar -- Edit bug report at http://bugs.php.net/bug.php?id=53989edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53989r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53989r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53989r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53989r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53989r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53989r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53989r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53989r=needscript Try newer version: http://bugs.php.net/fix.php?id=53989r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53989r=support Expected behavior: http://bugs.php.net/fix.php?id=53989r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53989r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53989r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53989r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53989r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53989r=dst IIS Stability: http://bugs.php.net/fix.php?id=53989r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53989r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53989r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53989r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53989r=mysqlcfg
[PHP-BUG] Bug #53737 [NEW]: segfault / php crash on nl2br(object)
From: Operating system: gentoo 1.12.14, FreeBSD 8.0 PHP version: 5.3.5 Package: Strings related Bug Type: Bug Bug description:segfault / php crash on nl2br(object) Description: Calling nl2br(any_object) causes segmentation fault and crashing php. Test script: --- ?php // any object echo nl2br(new mysqli()); Expected result: fatal error is expected Catchable fatal error: Object of class mysqli could not be converted to string in - on line 3 Actual result: -- segfault and php crash dmesg shows this: [12476.986676] php-cgi[21195]: segfault at 3118 ip 7ff86c5d6074 sp 7fff1edd4e60 error 4 in php-cgi[7ff86c26f000+77e000] -- Edit bug report at http://bugs.php.net/bug.php?id=53737edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53737r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53737r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53737r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53737r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53737r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53737r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53737r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53737r=needscript Try newer version: http://bugs.php.net/fix.php?id=53737r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53737r=support Expected behavior: http://bugs.php.net/fix.php?id=53737r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53737r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53737r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53737r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53737r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53737r=dst IIS Stability: http://bugs.php.net/fix.php?id=53737r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53737r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53737r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53737r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53737r=mysqlcfg
Bug #53737 [Fbk-Csd]: segfault / php crash on nl2br(object)
Edit report at http://bugs.php.net/bug.php?id=53737edit=1 ID: 53737 User updated by:martin at veverka dot eu Reported by:martin at veverka dot eu Summary:segfault / php crash on nl2br(object) -Status: Feedback +Status: Closed Type: Bug Package:Strings related Operating System: gentoo 1.12.14, FreeBSD 8.0 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Seems that the segfault is caused by the object itself, I will post more details as soon as i know something. Sorry for the misleading description. Previous Comments: [2011-01-13 15:58:20] cataphr...@php.net I can't reproduce: $ ~/php/php5.3-t/bin/php -r echo nl2br(new mysqli); Warning: nl2br() expects parameter 1 to be string, object given in Command line code on line 1 I also find no problem in nl2br (all pretty standard). Can you give more details? [2011-01-13 14:58:10] martin at veverka dot eu Description: Calling nl2br(any_object) causes segmentation fault and crashing php. Test script: --- ?php // any object echo nl2br(new mysqli()); Expected result: fatal error is expected Catchable fatal error: Object of class mysqli could not be converted to string in - on line 3 Actual result: -- segfault and php crash dmesg shows this: [12476.986676] php-cgi[21195]: segfault at 3118 ip 7ff86c5d6074 sp 7fff1edd4e60 error 4 in php-cgi[7ff86c26f000+77e000] -- Edit this bug report at http://bugs.php.net/bug.php?id=53737edit=1
[PHP-BUG] Req #53493 [NEW]: xmlrpc_decode should not be sensitive to leading whitespace
From: Operating system: Ubuntu 10.04 LTS Server PHP version: 5.3.3 Package: XMLRPC-EPI related Bug Type: Feature/Change Request Bug description:xmlrpc_decode should not be sensitive to leading whitespace Description: My version of PHP is PHP 5.3.2-1ubuntu4.5. I did some upgrades a few hours/days back and I noticed that my XMLRPC responses are decoded as NULL by the xmlrpc_decode() function. As I experimented around this function, I found that it is sensitive to leading whitespace. When leading whitespace is present (a newline in my case), xmlrpc_decode() returns NULL. When ltrim() is used on the string before passed into xmlrpc_decode(), output is alright. Presence of whitespace present at the end of the string does not have any effect. Summary: xmlrpc_decode() is sensitive to leading whitespace and it should not be. --- From manual page: http://www.php.net/function.xmlrpc-decode#Description --- -- Edit bug report at http://bugs.php.net/bug.php?id=53493edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53493r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53493r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53493r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53493r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53493r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53493r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53493r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53493r=needscript Try newer version: http://bugs.php.net/fix.php?id=53493r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53493r=support Expected behavior: http://bugs.php.net/fix.php?id=53493r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53493r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53493r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53493r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53493r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53493r=dst IIS Stability: http://bugs.php.net/fix.php?id=53493r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53493r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53493r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53493r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53493r=mysqlcfg
[PHP-BUG] Bug #53450 [NEW]: Autoloading random failures , Fatal error: Class * not found
From: Operating system: Debian Etch PHP version: 5.3.3 Package: *General Issues Bug Type: Bug Bug description:Autoloading random failures , Fatal error: Class * not found Description: Since upgrade to version 5.0.3 of Zend Server CE and PHP 5.3.3 we have problems with autoloading classes. Sometimes (randomly) autoloading classes failed with Fatal error. Most times everytihnig works correctly but sometimes series of failures happend. Problem occurs in all our applications on server (including Zend Server administratio cosole). Example of log entries: [01-Dec-2010 16:15:19] PHP Fatal error: Class 'Debug' not found in /var/www/zakazky/papouch/cz/ariadne/debug.php on line 16 [01-Dec-2010 16:15:30] PHP Fatal error: Class 'Debug' not found in /var/www/zakazky/papouch/cz/ariadne/debug.php on line 16 [01-Dec-2010 16:15:37] PHP Fatal error: Class 'Zwas_Path' not found in /usr/local/zend/gui/UserServer/index.php on line 43 We using Zend server CE 5.0.3, PHP 5.3.3, Server Apache/2.2.3 (Debian) PHP/5.3.3 mod_ssl/2.2.3 OpenSSL/0.9.8c -- Edit bug report at http://bugs.php.net/bug.php?id=53450edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53450r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53450r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53450r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53450r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53450r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53450r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53450r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53450r=needscript Try newer version: http://bugs.php.net/fix.php?id=53450r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53450r=support Expected behavior: http://bugs.php.net/fix.php?id=53450r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53450r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53450r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53450r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53450r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53450r=dst IIS Stability: http://bugs.php.net/fix.php?id=53450r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53450r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53450r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53450r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53450r=mysqlcfg
Req #53392 [Opn]: curl_getcontent
Edit report at http://bugs.php.net/bug.php?id=53392edit=1 ID: 53392 User updated by:martin dot k at atlas dot cz Reported by:martin dot k at atlas dot cz Summary:curl_getcontent Status: Open Type: Feature/Change Request Package:cURL related PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Yes, I can! But if I use curl multi functions, I can also use write function to save the partial content. So why is there curl_multi_getcontent function? Moreover, it's very difficult to use write function (I must create new function, set up it for callback, manualy handle and store written data). Same for case, when I can initialize curl_multi and use it only for download 1 file (I must call curl_init, curl_multi_init, curl_multi_add_handle then call curl_multi_exec in do-while cycle and more..) In both of these case, the source code lost its brilliant simplicity :-( As I wrote, there is no SIMPLE way how to do that. And if is requested function already implemented for multi curl, it should be easy make it for single curl. The getcontent functions are not vital functions for cURL. As you said, everybody can use write function to save the partial content - this applies to single curl and also for multi curl! I really don't understand, why is function implemented only for multi curl and not for single curl? Why to want make easy life only for multi curl and no for single curl? For both case of use, there is ugly alternative way (write function) to solve problem. And there should be great function getcontent also for both, not only for one... Previous Comments: [2010-11-27 21:16:47] cataphr...@php.net Well, you can use a write function to save the partial content. [2010-11-23 22:56:15] martin dot k at atlas dot cz Description: Please add function curl_getcontent similar to curl_multi_getcontent. Why? When I call function curl_exec with set CURLOPT_TIMEOUT and timeout happend. It will return false and I have bad luck :-( However when I call function curl_multi_exec also with set CURLOPT_TIMEOUT and timeout happend. It will return false as well, but then I can call function curl_multi_getcontent and get partial content of downloaded file :-) Bottom line, there is no simple way how to get content (including header body) if function curl_exec ends up with fail. But if function curl_multi_exec will fail, I can call function curl_multi_getcontent and try get a part of content at least. Which can be useful! -- Edit this bug report at http://bugs.php.net/bug.php?id=53392edit=1
[PHP-BUG] Bug #53402 [NEW]: . is converted to _ in input type=file name=test.txt
From:
Operating system: Mandriva 2010 spring
PHP version: 5.2.14
Package: *General Issues
Bug Type: Bug
Bug description:. is converted to _ in input type=file name=test.txt
Description:
If a the name-tag of an input contains a dot, if is transferred to an
underscore. I googled all around, but can't find anything.
I wonder because:
$test = array( 'title_image.img'='bla');
works. So why it is converted?
Is it a bug or a feature :-)?
Test script:
---
html
head
titleTest/title
/head
body
pre
?php
echo $_FILES['title_image.img']['name'];
var_dump( $_FILES);
?
/pre
form name=form method=post action= enctype=multipart/form-data
input type=file name=title_image.img /
input type=submit name=save value=Speichern /
/form
/body
/html
Expected result:
array(1) {
[title_image.img]=
array(5) {
[name]=
string(0)
[type]=
string(0)
[tmp_name]=
string(0)
[error]=
int(4)
[size]=
int(0)
}
}
Actual result:
--
Notice: Undefined index: title_image.img in
/media/DATA/home/mschmitz/public_html/customer/uni/fm/tischlerei/test.php
on line 9
array(1) {
[title_image_img]=
array(5) {
[name]=
string(0)
[type]=
string(0)
[tmp_name]=
string(0)
[error]=
int(4)
[size]=
int(0)
}
}
--
Edit bug report at http://bugs.php.net/bug.php?id=53402edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53402r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53402r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53402r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53402r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53402r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53402r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53402r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53402r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53402r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53402r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53402r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53402r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53402r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53402r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53402r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53402r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53402r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53402r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53402r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53402r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53402r=mysqlcfg
[PHP-BUG] Req #53392 [NEW]: curl_getcontent
From: Operating system: PHP version: 5.3.3 Package: cURL related Bug Type: Feature/Change Request Bug description:curl_getcontent Description: Please add function curl_getcontent similar to curl_multi_getcontent. Why? When I call function curl_exec with set CURLOPT_TIMEOUT and timeout happend. It will return false and I have bad luck :-( However when I call function curl_multi_exec also with set CURLOPT_TIMEOUT and timeout happend. It will return false as well, but then I can call function curl_multi_getcontent and get partial content of downloaded file :-) Bottom line, there is no simple way how to get content (including header body) if function curl_exec ends up with fail. But if function curl_multi_exec will fail, I can call function curl_multi_getcontent and try get a part of content at least. Which can be useful! -- Edit bug report at http://bugs.php.net/bug.php?id=53392edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53392r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53392r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53392r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53392r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53392r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53392r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53392r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53392r=needscript Try newer version: http://bugs.php.net/fix.php?id=53392r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53392r=support Expected behavior: http://bugs.php.net/fix.php?id=53392r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53392r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53392r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53392r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53392r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53392r=dst IIS Stability: http://bugs.php.net/fix.php?id=53392r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53392r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53392r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53392r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53392r=mysqlcfg
[PHP-BUG] Bug #52930 [NEW]: Engine not responding to code properly
From:
Operating system: Windows 7 Business
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Engine not responding to code properly
Description:
cipher using php code to allow 2 way encryption currently it uses a
predefined
array of Char's it then loops though this and creates every cipher possible
by
shifting the first char to the end in a new array, and as it ciphers one
letter
the cipher moves forward on cipher it's using
No my problem is that i have had to place a check in to make sure the
cipher has
finished if it has and the decrypted cipher is not the same as the original
string rerun the cipher with the same string,
Now this should not be needed, also this still creates error's
This has been tested in php 5.3.1 and 5.3.3,
The occurrence the same some times refreshing the system give a cipher
that's to
short for the string and this is with the check
whats more annoying is that there is a check in the code to prevent this
happening as it was happening more and more
P.S now i got to re-random my cipher base as its useless one made public
haha
Test script:
---
http://pastebin.com/r934gLpM
inside encryptString you will see
if($this-decryptString($encoded) === $string){
return $encoded;
}else{
return $this-encryptString($string);
}
at the end it should not be possible for me to get a string thats dose not
break back.
Expected result:
The cipher to not occasionally return a string that is to short
Actual result:
--
Using the code above works but keep refreshing it and you will see you will
get
ciphers back that are 2 small a common one for me is LX on its own.
this happens more and more with a bigger string in the
$secure-encryptString
--
Edit bug report at http://bugs.php.net/bug.php?id=52930edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52930r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52930r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52930r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52930r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52930r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52930r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52930r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52930r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52930r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52930r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52930r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52930r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52930r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52930r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52930r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52930r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52930r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52930r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52930r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52930r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52930r=mysqlcfg
Bug #52930 [Opn]: Engine not responding to code properly
Edit report at http://bugs.php.net/bug.php?id=52930edit=1
ID: 52930
User updated by:martin at appware dot co dot uk
Reported by:martin at appware dot co dot uk
Summary:Engine not responding to code properly
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Windows 7 Business
PHP Version:5.3.3
Block user comment: N
New Comment:
http://pastebin.com/NQByiELh
Updated the test script to fix a E_NOTICE bug,
The PHP Error still occurs though
Previous Comments:
[2010-09-27 09:55:08] martin at appware dot co dot uk
Description:
cipher using php code to allow 2 way encryption currently it uses a
predefined
array of Char's it then loops though this and creates every cipher
possible by
shifting the first char to the end in a new array, and as it ciphers one
letter
the cipher moves forward on cipher it's using
No my problem is that i have had to place a check in to make sure the
cipher has
finished if it has and the decrypted cipher is not the same as the
original
string rerun the cipher with the same string,
Now this should not be needed, also this still creates error's
This has been tested in php 5.3.1 and 5.3.3,
The occurrence the same some times refreshing the system give a cipher
that's to
short for the string and this is with the check
whats more annoying is that there is a check in the code to prevent this
happening as it was happening more and more
P.S now i got to re-random my cipher base as its useless one made public
haha
Test script:
---
http://pastebin.com/r934gLpM
inside encryptString you will see
if($this-decryptString($encoded) === $string){
return $encoded;
}else{
return $this-encryptString($string);
}
at the end it should not be possible for me to get a string thats dose
not break back.
Expected result:
The cipher to not occasionally return a string that is to short
Actual result:
--
Using the code above works but keep refreshing it and you will see you
will get
ciphers back that are 2 small a common one for me is LX on its own.
this happens more and more with a bigger string in the
$secure-encryptString
--
Edit this bug report at http://bugs.php.net/bug.php?id=52930edit=1
Bug #52930 [Bgs]: Engine not responding to code properly
Edit report at http://bugs.php.net/bug.php?id=52930edit=1
ID: 52930
User updated by:martin at appware dot co dot uk
Reported by:martin at appware dot co dot uk
Summary:Engine not responding to code properly
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: Windows 7 Business
PHP Version:5.3.3
Block user comment: N
New Comment:
if($this-decryptString($encoded) === $string){
return $encoded;
}else{
return $this-encryptString($string);
}
Sorry but learn to read
How the hell dose the code above Return a string that dose not work,
even though
the Decryptor works perfectly as i did all the math and worked it out
and
tested.
Add
die(pre.print_r(array($string,
$this-decryptString($encoded)))./pre);
above the code i pasted at the top of this message and watch it loop yet
it will
say it works then return a code that dose not work something is
happening to the
return cipher.
Previous Comments:
[2010-09-27 10:34:48] cataphr...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
[2010-09-27 10:18:08] martin at appware dot co dot uk
http://pastebin.com/NQByiELh
Updated the test script to fix a E_NOTICE bug,
The PHP Error still occurs though
[2010-09-27 09:55:08] martin at appware dot co dot uk
Description:
cipher using php code to allow 2 way encryption currently it uses a
predefined
array of Char's it then loops though this and creates every cipher
possible by
shifting the first char to the end in a new array, and as it ciphers one
letter
the cipher moves forward on cipher it's using
No my problem is that i have had to place a check in to make sure the
cipher has
finished if it has and the decrypted cipher is not the same as the
original
string rerun the cipher with the same string,
Now this should not be needed, also this still creates error's
This has been tested in php 5.3.1 and 5.3.3,
The occurrence the same some times refreshing the system give a cipher
that's to
short for the string and this is with the check
whats more annoying is that there is a check in the code to prevent this
happening as it was happening more and more
P.S now i got to re-random my cipher base as its useless one made public
haha
Test script:
---
http://pastebin.com/r934gLpM
inside encryptString you will see
if($this-decryptString($encoded) === $string){
return $encoded;
}else{
return $this-encryptString($string);
}
at the end it should not be possible for me to get a string thats dose
not break back.
Expected result:
The cipher to not occasionally return a string that is to short
Actual result:
--
Using the code above works but keep refreshing it and you will see you
will get
ciphers back that are 2 small a common one for me is LX on its own.
this happens more and more with a bigger string in the
$secure-encryptString
--
Edit this bug report at http://bugs.php.net/bug.php?id=52930edit=1
[PHP-BUG] Req #52583 [NEW]: Improved casting and hinting, new magic method __cast()
From: Operating system: Irrelevant PHP version: Irrelevant Package: Class/Object related Bug Type: Feature/Change Request Bug description:Improved casting and hinting, new magic method __cast() Description: Type casting in PHP is currently limited to the builtin types. It would be very useful (IMO) if one could cast a value/variable to a class. And also type hinting could be improved by casting instead of type checking only. I suggest to solve this by introducing a new magic method for classes, called __cast(), that accepts the value to cast as parameter. I see two possible solutions for its functionality: (1) __cast() replaces the constructor method This will force the developer to move logics from the constructor into a separate function/method (which isn't even so bad) or to copy his code (which is indeed bad). If the function returns with the boolean value false, the default error mechanism is started saying something like cast to XYZ not allowed. (2) __cast() acts like a static constructor The code must return the casted result itself. That means one would implement some logics to transform the given value to the needed constructor parameters and create a new instance on his own. To handle an unsupported value the method would throw an exception or an error. The negative (or let's say curious) thing about this solution is, that this cast method could also return a value of a totally different type (see example). Test script: --- // see patch file Expected result: // working cast Actual result: -- // parse errors -- Edit bug report at http://bugs.php.net/bug.php?id=52583edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52583r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52583r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52583r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52583r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52583r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52583r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52583r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52583r=needscript Try newer version: http://bugs.php.net/fix.php?id=52583r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52583r=support Expected behavior: http://bugs.php.net/fix.php?id=52583r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52583r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52583r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52583r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52583r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52583r=dst IIS Stability: http://bugs.php.net/fix.php?id=52583r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52583r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52583r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52583r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52583r=mysqlcfg
Bug #52565 [Fbk-Opn]: print out of Zend_Form causing segmentation fault
Edit report at http://bugs.php.net/bug.php?id=52565edit=1
ID: 52565
User updated by:martin dot minka at gmail dot com
Reported by:martin dot minka at gmail dot com
Summary:print out of Zend_Form causing segmentation fault
-Status: Feedback
+Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.3.3
Block user comment: N
New Comment:
Thank you for quick reactions. I compiled PHP with debug enabled and
produced backtrace. It is attached in patch section.
Reproduce script is included in the original text. That exact script
crashes for me everytime.
Previous Comments:
[2010-08-09 09:41:57] m...@php.net
IIRC there's a place in (older version of?) the ZF Form libs where
__toString() does not return a string, causing a unexpected SIGSEGV.
[2010-08-09 09:29:28] paj...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
We also need a small reproduce script.
[2010-08-09 00:30:49] ras...@php.net
And the backtrace?
[2010-08-09 00:25:49] martin dot minka at gmail dot com
Description:
Our real application is crashing with signal 11. I was able to simplify
the code to following test code which is far from our real application,
but causes crash in the same kind of code construction: echo
is_null($form) ? '': $form;
I am able to reproduce this crash with PHP 5.3.3 and PHP 5.2.14.
It does not crash when runnig in CLI mode.
How to run:
1. configure include path to contain Zend library (I was testing with
http://framework.zend.com/svn/framework/standard/tags/release-1.10.6/library/Zend)
2. restart apache
3. point your browser to bug.php
Test script:
---
set_include_path('.' . PATH_SEPARATOR . '/var/www/library');
require 'Zend/Form.php';
class TestClass {
function crash() {
$form = new Zend_Form();
echo is_null($form) ? '': $form;
// it works if there echo instead of die() here
die(this ends with signal 11 SIGSEGV, returns HTTP code 500);
}
}
$test = new TestClass();
$test-crash();
Expected result:
the program should die and print out message this ends with signal 11
SIGSEGV, returns HTTP code 500
Actual result:
--
HTTP response code 500 returned and signal 11 SIGSEGV logged
--
Edit this bug report at http://bugs.php.net/bug.php?id=52565edit=1
[PHP-BUG] Bug #52565 [NEW]: print out of Zend_Form causing segmentation fault
From:
Operating system: Linux
PHP version: 5.3.3
Package: Reproducible crash
Bug Type: Bug
Bug description:print out of Zend_Form causing segmentation fault
Description:
Our real application is crashing with signal 11. I was able to simplify the
code to following test code which is far from our real application, but
causes crash in the same kind of code construction: echo is_null($form) ?
'': $form;
I am able to reproduce this crash with PHP 5.3.3 and PHP 5.2.14.
It does not crash when runnig in CLI mode.
How to run:
1. configure include path to contain Zend library (I was testing with
http://framework.zend.com/svn/framework/standard/tags/release-1.10.6/library/Zend)
2. restart apache
3. point your browser to bug.php
Test script:
---
set_include_path('.' . PATH_SEPARATOR . '/var/www/library');
require 'Zend/Form.php';
class TestClass {
function crash() {
$form = new Zend_Form();
echo is_null($form) ? '': $form;
// it works if there echo instead of die() here
die(this ends with signal 11 SIGSEGV, returns HTTP code 500);
}
}
$test = new TestClass();
$test-crash();
Expected result:
the program should die and print out message this ends with signal 11
SIGSEGV, returns HTTP code 500
Actual result:
--
HTTP response code 500 returned and signal 11 SIGSEGV logged
--
Edit bug report at http://bugs.php.net/bug.php?id=52565edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52565r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52565r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52565r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52565r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52565r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52565r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52565r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52565r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52565r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52565r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52565r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52565r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52565r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52565r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52565r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52565r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52565r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52565r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52565r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52565r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52565r=mysqlcfg
Bug #52521 [Fbk-Opn]: self-referenced array is copied instead of referenced after serialization
Edit report at http://bugs.php.net/bug.php?id=52521edit=1
ID: 52521
User updated by:martin dot leucht at gmail dot com
Reported by:martin dot leucht at gmail dot com
-Summary:serialize() loses reference to root
+Summary:self-referenced array is copied instead of
referenced after serialization
-Status: Feedback
+Status: Open
Type: Bug
-Package:*Programming Data Structures
+Package:Arrays related
Operating System: WIN32
PHP Version:5.3.3
Block user comment: N
New Comment:
// updated bug information
Previous Comments:
[2010-08-04 22:50:22] martin dot leucht at googlemail dot com
It seems it is array-related. The same thing using the stdclass works
fine.
Test script:
?php
$Object = (object)array(
'a' = 1,
'b' = $Object,
);
print_r($Object);
$Array = array(
'a' = 1,
'b' = $Array,
);
print_r($Array);
$Array = unserialize(serialize($Array));
$Object = unserialize(serialize($Object));
$Object-b-a = 2;
print_r($Object);
$Array['b']['a'] = 2;
print_r($Array);
?
Actual result:
--
stdClass Object
(
[a] = 1
[b] = stdClass Object
*RECURSION*
)
Array
(
[a] = 1
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
stdClass Object
(
[a] = 2
[b] = stdClass Object
*RECURSION*
)
Array
(
[a] = 1
[b] = Array
(
[a] = 2
[b] = Array
*RECURSION*
)
)
[2010-08-04 22:03:08] martin dot leucht at googlemail dot com
Okay, I finally made it though. I setup a build environment, built the
latest dev-version of PHP and ran the test script. But still: identical
results.
Please tell me how can I provide some help or assistence to solve this
issue?!
[2010-08-03 13:23:39] martin dot leucht at gmail dot com
Sorry, but there are no builds on the Windows snapshots page and as I do
not maintain a PHP build environment (nor am currently willing to do so
due to a lack of time) I can not test it right now.
Could you please give me a hint when the snapshot builds are available
or if anyone else can do this test using the given test script above.
[2010-08-03 09:53:39] m...@php.net
Please try using this snapshot:
http://snaps.php.net/php-trunk-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Could you please try a trunk snapshot, IIRC this problem might be fixed
already.
Thanks.
[2010-08-03 09:27:20] martin dot leucht at gmail dot com
I have to correct myself:
If I unserialize the correct serialized string, it works correctly.
It just works for print_r() afterwards, but if I do some stuff on the
referenced value it creates even more confusing structures.
Test script:
echo *** using correct value ***\n\n;
$Array = unserialize('a:2:{s:1:a;i:1;s:1:b;R:1;}');
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
$Array['b']['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
Actual result
-
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
print_r():
--
Array
(
[a] = 1
[b] = Array
(
[a] = 2
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
)
Expected result
---
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=52521
--
Edit this bug report at http://bugs.php.net/bug.php?id=52521edit=1
Bug #52521 [Com]: serialize() loses reference to root
Edit report at http://bugs.php.net/bug.php?id=52521edit=1
ID: 52521
Comment by: martin dot leucht at googlemail dot com
Reported by:martin dot leucht at gmail dot com
Summary:serialize() loses reference to root
Status: Feedback
Type: Bug
Package:*Programming Data Structures
Operating System: WIN32
PHP Version:5.3.3
Block user comment: N
New Comment:
Okay, I finally made it though. I setup a build environment, built the
latest dev-version of PHP and ran the test script. But still: identical
results.
Please tell me how can I provide some help or assistence to solve this
issue?!
Previous Comments:
[2010-08-03 13:23:39] martin dot leucht at gmail dot com
Sorry, but there are no builds on the Windows snapshots page and as I do
not maintain a PHP build environment (nor am currently willing to do so
due to a lack of time) I can not test it right now.
Could you please give me a hint when the snapshot builds are available
or if anyone else can do this test using the given test script above.
[2010-08-03 09:53:39] m...@php.net
Please try using this snapshot:
http://snaps.php.net/php-trunk-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Could you please try a trunk snapshot, IIRC this problem might be fixed
already.
Thanks.
[2010-08-03 09:27:20] martin dot leucht at gmail dot com
I have to correct myself:
If I unserialize the correct serialized string, it works correctly.
It just works for print_r() afterwards, but if I do some stuff on the
referenced value it creates even more confusing structures.
Test script:
echo *** using correct value ***\n\n;
$Array = unserialize('a:2:{s:1:a;i:1;s:1:b;R:1;}');
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
$Array['b']['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
Actual result
-
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
print_r():
--
Array
(
[a] = 1
[b] = Array
(
[a] = 2
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
)
Expected result
---
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
[2010-08-03 09:14:31] martin dot leucht at gmail dot com
Description:
When trying to serialize - unserialize a structure (i.e. array)
containing a child (or a subordinate child) referencing the root element
(meaning the structure to serialize) itself, it will be lost
afterwards.
This leads to annoying misbehaviour and memory abuse.
If I unserialize the correct serialized string, it works correctly.
May be its a bug in reference creation?!
Test script:
---
$Array = array(
'a' = 1
);
$Array['b'] = $Array;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo serialize():\n;
echo \n;
echo serialize($Array);
echo \n\n;
echo print_r(unserialize(serialize())):\n;
echo --\n;
print_r(unserialize(serialize($Array)));
echo \n;
echo *** modify referenced value ***\n\n;
$Array['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo *** modify re-serialized refererenced value ***\n\n;
$Array['a'] = 1;
$Array = unserialize(serialize($Array));
$Array['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo *** using correct value ***\n\n;
$Array = unserialize('a:2:{s:1:a;i:1;s:1:b;R:1;}');
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
Expected result:
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
serialize():
a:2:{s:1:a;i:1;s:1:b;R:1;}
print_r(unserialize(serialize())):
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
*** modify referenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
*** modify re-serialized refererenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
Actual result:
--
print_r():
--
Array
(
[a] = 1
[b
Bug #52521 [Com]: serialize() loses reference to root
Edit report at http://bugs.php.net/bug.php?id=52521edit=1
ID: 52521
Comment by: martin dot leucht at googlemail dot com
Reported by:martin dot leucht at gmail dot com
Summary:serialize() loses reference to root
Status: Feedback
Type: Bug
Package:*Programming Data Structures
Operating System: WIN32
PHP Version:5.3.3
Block user comment: N
New Comment:
It seems it is array-related. The same thing using the stdclass works
fine.
Test script:
?php
$Object = (object)array(
'a' = 1,
'b' = $Object,
);
print_r($Object);
$Array = array(
'a' = 1,
'b' = $Array,
);
print_r($Array);
$Array = unserialize(serialize($Array));
$Object = unserialize(serialize($Object));
$Object-b-a = 2;
print_r($Object);
$Array['b']['a'] = 2;
print_r($Array);
?
Actual result:
--
stdClass Object
(
[a] = 1
[b] = stdClass Object
*RECURSION*
)
Array
(
[a] = 1
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
stdClass Object
(
[a] = 2
[b] = stdClass Object
*RECURSION*
)
Array
(
[a] = 1
[b] = Array
(
[a] = 2
[b] = Array
*RECURSION*
)
)
Previous Comments:
[2010-08-04 22:03:08] martin dot leucht at googlemail dot com
Okay, I finally made it though. I setup a build environment, built the
latest dev-version of PHP and ran the test script. But still: identical
results.
Please tell me how can I provide some help or assistence to solve this
issue?!
[2010-08-03 13:23:39] martin dot leucht at gmail dot com
Sorry, but there are no builds on the Windows snapshots page and as I do
not maintain a PHP build environment (nor am currently willing to do so
due to a lack of time) I can not test it right now.
Could you please give me a hint when the snapshot builds are available
or if anyone else can do this test using the given test script above.
[2010-08-03 09:53:39] m...@php.net
Please try using this snapshot:
http://snaps.php.net/php-trunk-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Could you please try a trunk snapshot, IIRC this problem might be fixed
already.
Thanks.
[2010-08-03 09:27:20] martin dot leucht at gmail dot com
I have to correct myself:
If I unserialize the correct serialized string, it works correctly.
It just works for print_r() afterwards, but if I do some stuff on the
referenced value it creates even more confusing structures.
Test script:
echo *** using correct value ***\n\n;
$Array = unserialize('a:2:{s:1:a;i:1;s:1:b;R:1;}');
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
$Array['b']['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
Actual result
-
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
print_r():
--
Array
(
[a] = 1
[b] = Array
(
[a] = 2
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
)
Expected result
---
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
[2010-08-03 09:14:31] martin dot leucht at gmail dot com
Description:
When trying to serialize - unserialize a structure (i.e. array)
containing a child (or a subordinate child) referencing the root element
(meaning the structure to serialize) itself, it will be lost
afterwards.
This leads to annoying misbehaviour and memory abuse.
If I unserialize the correct serialized string, it works correctly.
May be its a bug in reference creation?!
Test script:
---
$Array = array(
'a' = 1
);
$Array['b'] = $Array;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo serialize():\n;
echo \n;
echo serialize($Array);
echo \n\n;
echo print_r(unserialize(serialize())):\n;
echo --\n;
print_r(unserialize(serialize($Array)));
echo \n;
echo *** modify referenced value ***\n\n;
$Array['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo *** modify re-serialized refererenced value ***\n\n;
$Array['a'] = 1;
$Array = unserialize
[PHP-BUG] Bug #52521 [NEW]: serialize() loses reference to root
From:
Operating system: WIN32
PHP version: 5.3.3
Package: *Programming Data Structures
Bug Type: Bug
Bug description:serialize() loses reference to root
Description:
When trying to serialize - unserialize a structure (i.e. array) containing
a child (or a subordinate child) referencing the root element (meaning the
structure to serialize) itself, it will be lost afterwards.
This leads to annoying misbehaviour and memory abuse.
If I unserialize the correct serialized string, it works correctly. May
be its a bug in reference creation?!
Test script:
---
$Array = array(
'a' = 1
);
$Array['b'] = $Array;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo serialize():\n;
echo \n;
echo serialize($Array);
echo \n\n;
echo print_r(unserialize(serialize())):\n;
echo --\n;
print_r(unserialize(serialize($Array)));
echo \n;
echo *** modify referenced value ***\n\n;
$Array['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo *** modify re-serialized refererenced value ***\n\n;
$Array['a'] = 1;
$Array = unserialize(serialize($Array));
$Array['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo *** using correct value ***\n\n;
$Array = unserialize('a:2:{s:1:a;i:1;s:1:b;R:1;}');
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
Expected result:
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
serialize():
a:2:{s:1:a;i:1;s:1:b;R:1;}
print_r(unserialize(serialize())):
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
*** modify referenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
*** modify re-serialized refererenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
Actual result:
--
print_r():
--
Array
(
[a] = 1
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
serialize():
a:2:{s:1:a;i:1;s:1:b;a:2:{s:1:a;i:1;s:1:b;R:3;}}
print_r(unserialize(serialize())):
--
Array
(
[a] = 1
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
*** modify referenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
(
[a] = 2
[b] = Array
*RECURSION*
)
)
*** modify re-serialized refererenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
--
Edit bug report at http://bugs.php.net/bug.php?id=52521edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52521r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52521r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52521r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52521r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52521r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52521r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52521r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52521r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52521r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52521r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52521r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52521r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52521r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52521r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52521r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52521r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52521r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52521r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52521r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52521r=nozend
MySQL Configuration Error:
Bug #52521 [Com]: serialize() loses reference to root
Edit report at http://bugs.php.net/bug.php?id=52521edit=1
ID: 52521
Comment by: martin dot leucht at gmail dot com
Reported by:martin dot leucht at gmail dot com
Summary:serialize() loses reference to root
Status: Open
Type: Bug
Package:*Programming Data Structures
Operating System: WIN32
PHP Version:5.3.3
Block user comment: N
New Comment:
I have to correct myself:
If I unserialize the correct serialized string, it works correctly.
It just works for print_r() afterwards, but if I do some stuff on the
referenced value it creates even more confusing structures.
Test script:
echo *** using correct value ***\n\n;
$Array = unserialize('a:2:{s:1:a;i:1;s:1:b;R:1;}');
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
$Array['b']['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
Actual result
-
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
print_r():
--
Array
(
[a] = 1
[b] = Array
(
[a] = 2
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
)
Expected result
---
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
Previous Comments:
[2010-08-03 09:14:31] martin dot leucht at gmail dot com
Description:
When trying to serialize - unserialize a structure (i.e. array)
containing a child (or a subordinate child) referencing the root element
(meaning the structure to serialize) itself, it will be lost
afterwards.
This leads to annoying misbehaviour and memory abuse.
If I unserialize the correct serialized string, it works correctly.
May be its a bug in reference creation?!
Test script:
---
$Array = array(
'a' = 1
);
$Array['b'] = $Array;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo serialize():\n;
echo \n;
echo serialize($Array);
echo \n\n;
echo print_r(unserialize(serialize())):\n;
echo --\n;
print_r(unserialize(serialize($Array)));
echo \n;
echo *** modify referenced value ***\n\n;
$Array['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo *** modify re-serialized refererenced value ***\n\n;
$Array['a'] = 1;
$Array = unserialize(serialize($Array));
$Array['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo *** using correct value ***\n\n;
$Array = unserialize('a:2:{s:1:a;i:1;s:1:b;R:1;}');
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
Expected result:
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
serialize():
a:2:{s:1:a;i:1;s:1:b;R:1;}
print_r(unserialize(serialize())):
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
*** modify referenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
*** modify re-serialized refererenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
Actual result:
--
print_r():
--
Array
(
[a] = 1
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
serialize():
a:2:{s:1:a;i:1;s:1:b;a:2:{s:1:a;i:1;s:1:b;R:3;}}
print_r(unserialize(serialize())):
--
Array
(
[a] = 1
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
*** modify referenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
(
[a] = 2
[b] = Array
*RECURSION*
)
)
*** modify re-serialized refererenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52521edit=1
Bug #52521 [Com]: serialize() loses reference to root
Edit report at http://bugs.php.net/bug.php?id=52521edit=1
ID: 52521
Comment by: martin dot leucht at gmail dot com
Reported by:martin dot leucht at gmail dot com
Summary:serialize() loses reference to root
Status: Feedback
Type: Bug
Package:*Programming Data Structures
Operating System: WIN32
PHP Version:5.3.3
Block user comment: N
New Comment:
Sorry, but there are no builds on the Windows snapshots page and as I do
not maintain a PHP build environment (nor am currently willing to do so
due to a lack of time) I can not test it right now.
Could you please give me a hint when the snapshot builds are available
or if anyone else can do this test using the given test script above.
Previous Comments:
[2010-08-03 09:53:39] m...@php.net
Please try using this snapshot:
http://snaps.php.net/php-trunk-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Could you please try a trunk snapshot, IIRC this problem might be fixed
already.
Thanks.
[2010-08-03 09:27:20] martin dot leucht at gmail dot com
I have to correct myself:
If I unserialize the correct serialized string, it works correctly.
It just works for print_r() afterwards, but if I do some stuff on the
referenced value it creates even more confusing structures.
Test script:
echo *** using correct value ***\n\n;
$Array = unserialize('a:2:{s:1:a;i:1;s:1:b;R:1;}');
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
$Array['b']['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
Actual result
-
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
print_r():
--
Array
(
[a] = 1
[b] = Array
(
[a] = 2
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
)
Expected result
---
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
[2010-08-03 09:14:31] martin dot leucht at gmail dot com
Description:
When trying to serialize - unserialize a structure (i.e. array)
containing a child (or a subordinate child) referencing the root element
(meaning the structure to serialize) itself, it will be lost
afterwards.
This leads to annoying misbehaviour and memory abuse.
If I unserialize the correct serialized string, it works correctly.
May be its a bug in reference creation?!
Test script:
---
$Array = array(
'a' = 1
);
$Array['b'] = $Array;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo serialize():\n;
echo \n;
echo serialize($Array);
echo \n\n;
echo print_r(unserialize(serialize())):\n;
echo --\n;
print_r(unserialize(serialize($Array)));
echo \n;
echo *** modify referenced value ***\n\n;
$Array['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo *** modify re-serialized refererenced value ***\n\n;
$Array['a'] = 1;
$Array = unserialize(serialize($Array));
$Array['a'] = 2;
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
echo *** using correct value ***\n\n;
$Array = unserialize('a:2:{s:1:a;i:1;s:1:b;R:1;}');
echo print_r():\n;
echo --\n;
print_r($Array);
echo \n;
Expected result:
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
serialize():
a:2:{s:1:a;i:1;s:1:b;R:1;}
print_r(unserialize(serialize())):
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
*** modify referenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
*** modify re-serialized refererenced value ***
print_r():
--
Array
(
[a] = 2
[b] = Array
*RECURSION*
)
*** using correct value ***
print_r():
--
Array
(
[a] = 1
[b] = Array
*RECURSION*
)
Actual result:
--
print_r():
--
Array
(
[a] = 1
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION*
)
)
serialize():
a:2:{s:1:a;i:1;s:1:b;a:2:{s:1:a;i:1;s:1:b;R:3;}}
print_r(unserialize(serialize())):
--
Array
(
[a] = 1
[b] = Array
(
[a] = 1
[b] = Array
*RECURSION
Req #49543 [Com]: closures cannot import/inherit $this
Edit report at http://bugs.php.net/bug.php?id=49543edit=1
ID: 49543
Comment by: martin dot partel at gmail dot com
Reported by: mjs at beebo dot org
Summary: closures cannot import/inherit $this
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: Ubuntu
PHP Version: 5.3.0
New Comment:
The '$tmp' workaround is not good enough, since private/protected
members cannot be accessed that way. This renders closures frustratingly
useless in OO code in quite a few situations.
All other OO languages with closures that I know of allow such access
one way or the other. Come on guys, find your consensus and get it done!
Previous Comments:
[2009-09-13 14:55:50] mjs at beebo dot org
Description:
Attempting to import/inherit $this produces the compile-time error
Cannot use $this as lexical variable.
Note that the workaround of assigning $this to the temporary variable
$tmp, and inheriting $tmp instead does work, so there appears to be no
limitation in the engine:
class Foo {
public function bar() {
$tmp = $this;
return function() use ($tmp) {
echo in closure\n;
}
}
}
See also http://wiki.php.net/rfc/closures/removal-of-this. (It
appears that $this was once automatically imported into the closure's
scope, but that this turned out to be a bad idea. This bug report
concerns what happens when $this is explicitly imported, however.)
Reproduce code:
---
?php
class Foo {
public function bar() {
return function() use ($this) {
echo in closure\n;
}
}
}
Expected result:
in closure
Actual result:
--
PHP Fatal error: Cannot use $this as lexical variable in
/mnt/hgfs/workspace/scratch/wart2.php on line 7
--
Edit this bug report at http://bugs.php.net/bug.php?id=49543edit=1
[PHP-BUG] Bug #51999 [NEW]: Code within sqlite_error_string cannot be reached
From: Operating system: Linux / Debian PHP version: 5.3SVN-2010-06-05 (SVN) Package: SQLite related Bug Type: Bug Bug description:Code within sqlite_error_string cannot be reached Description: When writing phpt tests I was trying to reach a part of the code where the result of sqlite_error_string would not return a message. When passing 127 as an argument to sqlite_error_string I still get a message returned though. So this part of the code seems unreachable. Looking in the function declaration of the extension source the default value for error codes is the Unknown error message, which also confirms what I already assumed. Test script: --- var_dump(sqlite_error_string( 127 ) ); Expected result: NULL Actual result: -- string(13) unknown error -- Edit bug report at http://bugs.php.net/bug.php?id=51999edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51999r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51999r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51999r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51999r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51999r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51999r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51999r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51999r=needscript Try newer version: http://bugs.php.net/fix.php?id=51999r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51999r=support Expected behavior: http://bugs.php.net/fix.php?id=51999r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51999r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51999r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51999r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51999r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51999r=dst IIS Stability: http://bugs.php.net/fix.php?id=51999r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51999r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51999r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51999r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51999r=mysqlcfg
Bug #45546 [Com]: PCRE with utf8 kill apache childprocess
Edit report at http://bugs.php.net/bug.php?id=45546edit=1 ID: 45546 Comment by: martin at veverka dot eu Reported by: kaiser at macbureau dot de Summary: PCRE with utf8 kill apache childprocess Status: No Feedback Type: Bug Package: PCRE related Operating System: FreeBSD 7 PHP Version: 5.2.6 New Comment: Hi. Still broken. from Apache error log: [notice] child pid 43125 exit signal Illegal instruction (4) FreeBSD 8.0 Apache/2.2.15 PHP 5.3.2 with Suhosin-Patch PCRE Library Version = 8.02 2010-03-19 Previous Comments: [2009-09-18 19:57:50] chris at smartt dot com Still happening on FreeBSD 7.2 and PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: May 11 2009 22:23:18) #1860 0x28cdcad1 in match () from /usr/local/lib/libpcre.so.0 #1861 0x28cde851 in match () from /usr/local/lib/libpcre.so.0 #1862 0x28ce6ad7 in pcre_exec () from /usr/local/lib/libpcre.so.0 #1863 0x28cc931b in php_pcre_match_impl () from /usr/local/lib/php/20060613/pcre.so #1864 0x28cc9de0 in php_do_pcre_match () from /usr/local/lib/php/20060613/pcre.so #1865 0x0815c7bd in execute_internal () #1866 0x285d16e0 in suhosin_execute_internal () from /usr/local/lib/php/20060613/suhosin.so #1867 0x081695db in zend_do_fcall_common_helper_SPEC () #1868 0x0815d961 in execute () #1869 0x287810c2 in _su3jdmx () from /usr/local/lib/php/20060613/ioncube_loader_fre_5.2.so #1870 0x2912ef9c in ?? () #1871 0x in ?? () #1872 0x285dc780 in __JCR_LIST__ () from /usr/local/lib/php/20060613/suhosin.so #1873 0x285d1c55 in suhosin_execute_ex () from /usr/local/lib/php/20060613/suhosin.so [2009-06-10 18:06:00] bob at veznat dot com This is still broken. FreeBSD 7.1 and PHP 5.2.9. It seems that the original bug filer has provided plenty of repro. If that is not the case I'd be happy to go through the process of digging up all I can from my machine. [2009-02-26 01:30:01] joe at lastpass dot com Happens at somewhere between 3500 and 6400 characters on every Linux platform I have access to (x86 and x86_64): PHP 5.2.6-3ubuntu2 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 13 2009 20:07:08) PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11 2009 20:44:58) PHP 5.2.4-2ubuntu5.5 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11 2009 20:09:11) PHP 5.2.6-3ubuntu2 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 13 2009 20:20:01) [2009-02-08 11:55:20] vanav at vanav dot com dot ua Two gdb examples: gdb66: Program received signal SIGSEGV, Segmentation fault. match ( eptr=0x29385a68 3'\;\n$select[] = \SELECT p1.id, nick, p1.creation_date, p1.modification_date, p1.post_title, p1.post_text, p1.parent_post_id, p2.post_title AS parent_post_title, p3.post_title AS answer_parent_post_ti..., ecode=0x28f160ed \034\T, mstart=0x293854bc ?php\n$select = array();\n$select[] = \SELECT uni_files.id, name, disk_filename, icon, size FROM uni_files INNER JOIN uni_filetypes ON uni_files.filetype_id=uni_filetypes.id WHERE post_id='167' AND blo..., offset_top=4, md=0xbfbef000, ims=6, eptrb=0x0, flags=0, rdepth=1362) at /usr/ports/lang/php5/work/php-5.2.8/ext/pcre/pcrelib/pcre_exec.c:580 580 prop_value = 0; and 0x2863b28a in match ( eptr=0x2940b64f ?#1072;#1052;202#1052;214, #1076;#1072;#1078;#1077; #1052;201#1052;200#1077;#1076;#1085;#1077;#1084;#1052;203 #1082;#1083;#1072;#1052;201#1052;201#1052;203, ?00\223 #1079;#1072;#1052;217#1074;#1080;#1083; ?232#1052;203#1085;#1080;#1052;206#1052;213#1085;. #1076;#1072;#1078;#1077; #1052;201#1052;200#1077;#1076;#1085;#1077;#1084;#1052;203 #1082;#1083;#1072;#1052;201#1052;201#1052;203, ?00\223 #1079;#1072;#1052;217#1074;#1080;#1083; ?232#1052;203#1085;#1080;#1052;206#1052;213#1085;. /pp?222#1052;213 #1079;#1085;#1072;#1077;#1052;202#1077;, #1052;207#1052;202#1086; ?..., ecode=0x28ef03bb \034'U, mstart=0x2940b398 'p?237#1086; #1084;#1085;#1077;#1085;#1080;#1052;216 ?232#1052;203#1085;#1080;#1052;206#1052;213#1085;#1072;, #1082;#1052;200#1052;213#1084;#1052;201#1082;#1080;#1077; #1074;#1083;#1072;#1052;201#1052;202#1080; #1076;#1086;#1083;#1078;#1085;#1052;213 #1076;#1072;#1052;202#1052;214 #1074;#1086;#1079;#1084;#1086;#1078;#1085;#1086;#1052;201#1052;202#1052;214 #1052;201#1052;200#1077;#1076;#1085;#1077;#1084;#1052;203 #1082;#1083;#1072;#1052;201#1052;201#1052;203 #1082;#1072;#1087;#1080;#1052;202#1072;#1083;#1080;#1079;#1080;#1052;200#1086;#1074;#1072;#1052;202#1052;214 #1080;#1052;205 #1052;201#1073;#1077;#1052;200#1077;#1078;#1077;#1085;?..., offset_top=4, md=0xbfbf89d0, ims=0, eptrb=0xbfa006a0, flags=2, rdepth=1388) at /usr/ports/lang/php5/work/php-5.2.8/ext/pcre
Bug #51298 [Com]: Error when loading php5apache2_2.dll
Edit report at http://bugs.php.net/bug.php?id=51298edit=1 ID: 51298 Comment by: peter dot martin at spam dot la Reported by: trotsky_icepick at hotmail dot com Summary: Error when loading php5apache2_2.dll Status: Assigned Type: Bug Package: Apache2 related Operating System: Windows Vista SP2 PHP Version: 5.3.2 Assigned To: pajoye New Comment: I've got faulting module php5ts.dll error while starting the Apache server with PHP and Postgres in following instalation: - httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi - php-5.3.2-Win32-VC6-x86.zip httpd.conf: - nothing unusual configured php.ini configuration: - set up my own php error log file error_log = C:/PHP/logs/error.log - uncomment PgSQL extension The solution for this was to modify httpd.conf as follows: LoadModule php5_module C:/PHP/php5apache2_2.dll PHPIniDir C:/PHP # added Loadfile C:/PHP/php5ts.dll Loadfile C:/PHP/libpq.dll Try it and send response...:) Previous Comments: [2010-05-19 17:18:00] paj...@php.net If you feel like you can fix this bug within days, heh, please go ahead. [2010-05-19 17:10:33] williams at uncc dot edu There is still a problem with the Windows PHP binaries. From 4/19 pajoye seems to believe it is a date bug to fix as soon as possible. It has been a month! I have php-5.3.2-Win32-VC6-x86 and httpd-2.2.15-win32-x86-no_ssl installed. If I run phpinfo() (in web page) more than once (first run - get results, second or later runs within a few seconds - get crash) I get this error message: AppName httpd.exe AppVer 2.2.15.0 ModName php5ts.dll ModVer 5.3.2.0 offset 001d79b5 I have searched for other versions of php5ts.dll - none I have NOT mixed vc9 PHP with Apache PHP seems to run okay in command-line, ie I can run phpinfo() in cmd box with no problem. I If run as test web page I get the error. Here are php -m /php -m -n results: C:\php -m [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib [Zend Modules] C:\php -m -n [PHP Modules] bcmath calendar com_dotnet Core ctype date dom ereg filter ftp hash iconv json libxml mcrypt mhash mysqlnd odbc pcre PDO Phar Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zip zlib [Zend Modules] I have disabled all but core modules. [2010-04-30 15:43:09] slowchaos at msn dot com Update I have Apached 2.2.15 and PHP 5.3.2 running just fine (WinXP system). I'm not sure of the difference in 5.2 and 5.3 - I'm not a nuts and bolts php guy - but all is now well in my world :) [2010-04-30 06:55:02] slowchaos at msn dot com Had this problem with Apache 2.2.15 and PHP 5.2.13. Tried rolling back to earlier versions of PHP - back to PHP 5.2.10. Same thing. Rolled back to Apache 2.2.14 - still same issue. My apache crashes when trying to enable mysqli or mysql extension. System path is correct. Libmysql is in appropriate place. Mcrypt also crashes the server as well as a few others. [2010-04-20 01:48:09] paj...@php.net It happens to be a date bug (thread safety issue). We are trying to get a fix as soon as possible. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51298 -- Edit this bug report at http://bugs.php.net/bug.php?id=51298edit=1
[PHP-BUG] Bug #51525 [NEW]: Getting a node with a - in it
From:
Operating system: Windows
PHP version: 5.2.13
Package: SimpleXML related
Bug Type: Bug
Bug description:Getting a node with a - in it
Description:
If a XML node have a - in it you can't get the data from it
display-name
echo $channel-display-name;
Notice: Use of undefined constant name - assumed 'name'
Test script:
---
?xml version=1.0 encoding=UTF-8 ?
tv generator-info-name=www.ontv.dk/xmltv
channel id=www.ontv.dk/tv/1
display-name lang=dkDR1 DK/display-name
/channel
/tv
$xml = simplexml_load_string($xml);
$channels = $this-xml-xpath('//channel');
foreach($channels AS $channel) {
echo $channel-display-name;
}
Expected result:
DR1 DK
Actual result:
--
Notice: Use of undefined constant name - assumed 'name'
--
Edit bug report at http://bugs.php.net/bug.php?id=51525edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51525r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51525r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51525r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51525r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51525r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51525r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51525r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51525r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51525r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51525r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51525r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51525r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51525r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51525r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51525r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51525r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51525r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51525r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51525r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51525r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51525r=mysqlcfg
Bug-Req #51525 [Opn]: Getting a node with a - in it
Edit report at http://bugs.php.net/bug.php?id=51525edit=1
ID: 51525
User updated by: martin at aarhof dot eu
Reported by: martin at aarhof dot eu
Summary: Getting a node with a - in it
Status: Open
-Type: Bug
+Type: Feature/Change Request
Package: SimpleXML related
Operating System: Windows
PHP Version: 5.2.13
New Comment:
Solution is
echo $channel-{display-name};
Could this be fixed so you dont need the {} ?
Previous Comments:
[2010-04-10 03:56:21] martin at aarhof dot eu
Description:
If a XML node have a - in it you can't get the data from it
display-name
echo $channel-display-name;
Notice: Use of undefined constant name - assumed 'name'
Test script:
---
?xml version=1.0 encoding=UTF-8 ?
tv generator-info-name=www.ontv.dk/xmltv
channel id=www.ontv.dk/tv/1
display-name lang=dkDR1 DK/display-name
/channel
/tv
$xml = simplexml_load_string($xml);
$channels = $this-xml-xpath('//channel');
foreach($channels AS $channel) {
echo $channel-display-name;
}
Expected result:
DR1 DK
Actual result:
--
Notice: Use of undefined constant name - assumed 'name'
--
Edit this bug report at http://bugs.php.net/bug.php?id=51525edit=1
[PHP-BUG] Doc #51241 [NEW]: missing changelog for prepend parameter on spl_autoload_register
From:
Operating system:
PHP version: 5.2.13
Package: SPL related
Bug Type: Documentation Problem
Bug description:missing changelog for prepend parameter on spl_autoload_register
Description:
The documentation fails to mention that the $prepend parameter was added in
php
5.3
Test script:
---
?php
function foo($class) {}
function bar($class) {}
spl_autoload_register('foo');
spl_autoload_register('bar', true, true);
$funcs = spl_autoload_functions();
assert('bar' == $funcs[0]);
assert(2 == count($funcs));
print_r($funcs);
Expected result:
According to the documentation, the two assertions in the test scripts
should
pass for any php version = 5.1.2. However, the two assertions fail in
5.2.13.
Expected output
Array
(
[0] = bar,
[1] = foo
)
Actual result:
--
Warning: assert(): Assertion failed in blah.php on line 9
Warning: assert(): Assertion failed in blah.php on line 10
Array
(
[0] = foo
)
--
Edit bug report at http://bugs.php.net/bug.php?id=51241edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51241r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51241r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51241r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51241r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51241r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51241r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51241r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51241r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51241r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51241r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51241r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51241r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51241r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51241r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51241r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51241r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51241r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51241r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51241r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51241r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51241r=mysqlcfg
#50844 [NEW]: misbehaviour of zend_ts_hash_apply_with_arguments
From: Martin dot Eisengardt at fiducia dot de
Operating system: Vista64-cygwin
PHP version: 5.3.1
PHP Bug Type: Reproducible crash
Bug description: misbehaviour of zend_ts_hash_apply_with_arguments
Description:
I was using a TsHashTable in my extension and assumed that it behaves the
same as normal HashTable. It is almost the same except function
zend_ts_hash_apply_with_arguments.
Reproduce code:
---
function applyFunc(void *pDest TSRMLS_DC, int num_args, va_list args,
zend_hash_key *hash_key)
{
int myint = va_arg(args, int);
// myint will contain the wrong integer. Hoever the following code
will work
// va_list args2 = va_arg(args2, va_list);
// int myint = va_arg(args2, int);
}
zend_ts_hash_apply_with_arguments(ht TSRMLS_CC, applyFunc, 1, myInt);
Expected result:
Expected that there is no need to extract args2 before extracting the
actual argument. In other word: Expected to use the same applyFunc for
both, TsHashTable and HashTable
Actual result:
--
You need to extract another va_list first before extracting the arguments
--
Edit bug report at http://bugs.php.net/?id=50844edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50844r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50844r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50844r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50844r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50844r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50844r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50844r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50844r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50844r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50844r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50844r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50844r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50844r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50844r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50844r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50844r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50844r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50844r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50844r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50844r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50844r=mysqlcfg
#50791 [NEW]: simulation of cookie_io_functions
From: martin dot eisengardt at fiducia dot de Operating system: Win64-Cygwin PHP version: 5.3.1 PHP Bug Type: Compile Failure Bug description: simulation of cookie_io_functions Description: main/streams/cast.c line 32 The comment says Under BSD, emulate fopencookie using funopen However under my gcywin both compiler options are set: HAVE_FUNOPEN and HAVE_FOPENCOOKIE. Of course compilation failes because of duplicate definitions. Changing the preprocessor directive in line 33 solves the problem for me: - #if HAVE_FUNOPEN + #if HAVE_FUNOPEN !HAVE_FOPENCOOKIE It compiles fine now and my scripts were successful. I did no make test to verify the change. -- Edit bug report at http://bugs.php.net/?id=50791edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50791r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50791r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50791r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50791r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50791r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50791r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50791r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50791r=needscript Try newer version: http://bugs.php.net/fix.php?id=50791r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50791r=support Expected behavior: http://bugs.php.net/fix.php?id=50791r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50791r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50791r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50791r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50791r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50791r=dst IIS Stability: http://bugs.php.net/fix.php?id=50791r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50791r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50791r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50791r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50791r=mysqlcfg
#36246 [Com]: Memory problem (double free)
ID: 36246 Comment by: fabian dot martin at gmail dot com Reported By: eustaquiorangel at yahoo dot com Status: No Feedback Bug Type: XSLT related Operating System: Linux, Slackware 10.2 (current) PHP Version: 5.1.2 New Comment: I have the same Problem on two different Server, but I'm don't using XSLT. Here are the Logs. Server 1 (PHP 5.2.11, running as FastCGI): *** glibc detected *** ps: double free or corruption (fasttop): 0x0968fe30 *** === Backtrace: = /lib/i686/cmov/libc.so.6[0xb7ef48f4] /lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7ef6896] ps[0x8049af2] ps[0x804a735] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7e9c7a5] ps[0x8049401] === Memory map: 08048000-0805b000 r-xp 08:05 16794109 /bin/ps 0805b000-0805c000 rw-p 00012000 08:05 16794109 /bin/ps 0805c000-0807c000 rw-p 00:00 0 0968f000-096b rw-p 00:00 0 [heap] b7b0-b7b21000 rw-p 00:00 0 b7b21000-b7c0 ---p 00:00 0 b7c2f000-b7c59000 r-xp 08:05 933898 /lib/libgcc_s.so.1 b7c59000-b7c5a000 rw-p 00029000 08:05 933898 /lib/libgcc_s.so.1 b7c63000-b7c84000 rw-p 00:00 0 b7c84000-b7c85000 ---p 00:00 0 b7c85000-b7e85000 r--p 08:05 17662043 /usr/lib/locale/locale-archive b7e85000-b7e86000 rw-p 00:00 0 b7e86000-b7fde000 r-xp 08:05 1473 /lib/i686/cmov/libc-2.9.so b7fde000-b7fdf000 ---p 00158000 08:05 1473 /lib/i686/cmov/libc-2.9.so b7fdf000-b7fe1000 r--p 00158000 08:05 1473 /lib/i686/cmov/libc-2.9.so b7fe1000-b7fe2000 rw-p 0015a000 08:05 1473 /lib/i686/cmov/libc-2.9.so b7fe2000-b7fe5000 rw-p 00:00 0 b7fe5000-b7ff3000 r-xp 08:05 933943 /lib/libproc-3.2.8.so b7ff3000-b7ff4000 rw-p e000 08:05 933943 /lib/libproc-3.2.8.so b7ff4000-b8006000 rw-p 00:00 0 b800e000-b8011000 rw-p 00:00 0 b8011000-b8012000 r-xp 00:00 0 [vdso] b8012000-b802e000 r-xp 08:05 17186860 /lib/ld-2.9.so b802e000-b802f000 r--p 0001b000 08:05 17186860 /lib/ld-2.9.so b802f000-b803 rw-p 0001c000 08:05 17186860 /lib/ld-2.9.so bfe04000-bfe19000 rw-p 00:00 0 [stack] --- Server 2 (PHP 5.2.11, running as FastCGI): *** glibc detected *** ps: double free or corruption (fasttop): 0x0063a8a0 *** === Backtrace: = /lib/libc.so.6[0x7f17861706c8] /lib/libc.so.6(cfree+0x76)[0x7f17861721d6] ps[0x4022f0] ps[0x402f6e] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f178611d5c6] ps[0x401ba9] === Memory map: 0040-00418000 r-xp 09:01 93617 /bin/ps 00618000-00619000 rw-p 00018000 09:01 93617 /bin/ps 00619000-0065a000 rw-p 00619000 00:00 0 [heap] 7f178000-7f1780021000 rw-p 7f178000 00:00 0 7f1780021000-7f178400 ---p 7f1780021000 00:00 0 7f1785b96000-7f1785bb r-xp 09:01 61865 /lib/libgcc_s.so.1 7f1785bb-7f1785daf000 ---p 0001a000 09:01 61865 /lib/libgcc_s.so.1 7f1785daf000-7f1785db rw-p 00019000 09:01 61865 /lib/libgcc_s.so.1 7f1785db7000-7f1785dbe000 r--s 09:05 389 /usr/lib/gconv/gconv-modules.cache 7f1785dbe000-7f1785de rw-p 7f1785dbe000 00:00 0 7f1785de-7f1785de1000 ---p 7f1785de 00:00 0 7f1785de1000-7f17860ff000 r--p 09:05 4194433 /usr/lib/locale/locale-archive 7f17860ff000-7f1786246000 r-xp 09:01 62149 /lib/libc-2.9.so 7f1786246000-7f1786446000 ---p 00147000 09:01 62149 /lib/libc-2.9.so 7f1786446000-7f178644a000 r--p 00147000 09:01 62149 /lib/libc-2.9.so 7f178644a000-7f178644b000 rw-p 0014b000 09:01 62149 /lib/libc-2.9.so 7f178644b000-7f178645 rw-p 7f178644b000 00:00 0 7f178645-7f1786461000 r-xp 09:01 61889 /lib/libproc-3.2.8.so 7f1786461000-7f178666 ---p 00011000 09:01 61889 /lib/libproc-3.2.8.so 7f178666-7f1786661000 rw-p 0001 09:01 61889 /lib/libproc-3.2.8.so 7f1786661000-7f1786674000 rw-p 7f1786661000 00:00 0 7f1786674000-7f1786691000 r-xp 09:01 62146 /lib/ld-2.9.so 7f1786884000-7f1786886000 rw-p 7f1786884000 00:00 0 7f178688d000-7f178689 rw-p 7f178688d000 00:00 0 7f178689-7f1786891000 r--p 0001c000 09:01 62146 /lib/ld-2.9.so 7f1786891000-7f1786892000 rw-p 0001d000 09:01 62146 /lib/ld-2.9.so 7fff8e87c000-7fff8e891000 rw-p 7ffea000 00:00 0 [stack] 7fff8e9fe000-7fff8e9ff000 r-xp 7fff8e9fe000 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Previous
#49495 [NEW]: PHP doesn't run correct method
From: martin at spuetz dot net
Operating system: Linux
PHP version: 5.3.0
PHP Bug Type: SOAP related
Bug description: PHP doesn't run correct method
Description:
I have two methods test1() and test2(), but PHP always runs the first
one.
You can see this on the following link:
http://www.spuetz.net/client.php
http://www.spuetz.net/source.txt
It does works, when I add a parameter (change the method signature?):
http://www.spuetz.net/client1.php
http://www.spuetz.net/source1.txt
The server is running 5.2.10 (http://www.spuetz.net/info.php), but I tried
it with 5.3.0, too.
The wsdl file was generated with Zend Studio.
Reproduce code:
---
class Testserver {
public function test1()
{
return test1;
}
public function test2()
{
return test2;
}
}
[...]
var_dump($client-test1());
var_dump($client-test2());
Expected result:
string(5) test1
string(5) test2
Actual result:
--
string(5) test1
string(5) test1
--
Edit bug report at http://bugs.php.net/?id=49495edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49495r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49495r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49495r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49495r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49495r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49495r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49495r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49495r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49495r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49495r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49495r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49495r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49495r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49495r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49495r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49495r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49495r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49495r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49495r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49495r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49495r=mysqlcfg
#49495 [Opn-Bgs]: PHP doesn't run correct method
ID: 49495
User updated by: martin at spuetz dot net
Reported By: martin at spuetz dot net
-Status: Open
+Status: Bogus
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
I found the problem. It will work when you change the soap binding
style
to rpc.
doesn't work:
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
works:
soap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http/
Greetings from Germany
Martin
Previous Comments:
[2009-09-08 06:27:07] martin at spuetz dot net
Description:
I have two methods test1() and test2(), but PHP always runs the first
one.
You can see this on the following link:
http://www.spuetz.net/client.php
http://www.spuetz.net/source.txt
It does works, when I add a parameter (change the method signature?):
http://www.spuetz.net/client1.php
http://www.spuetz.net/source1.txt
The server is running 5.2.10 (http://www.spuetz.net/info.php), but I
tried it with 5.3.0, too.
The wsdl file was generated with Zend Studio.
Reproduce code:
---
class Testserver {
public function test1()
{
return test1;
}
public function test2()
{
return test2;
}
}
[...]
var_dump($client-test1());
var_dump($client-test2());
Expected result:
string(5) test1
string(5) test2
Actual result:
--
string(5) test1
string(5) test1
--
Edit this bug report at http://bugs.php.net/?id=49495edit=1
#38851 [Com]: Failed to created Apache 2 shared library
ID: 38851 Comment by: martin at searchoptics dot com Reported By: shorb at optonline dot net Status: No Feedback Bug Type: Compile Failure Operating System: RedHat EL 4 PHP Version: 5.1.6 New Comment: I've had a similar issue on Centos 5.3 x64 using the following configure option on 5.2.12 CONFIGURE_COMMAND = './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql=/usr/local/mysql' '--enable-ftp' '--with-gd' '--with-png-dir=/usr' '--with-freetype-di r=/usr/local' '--with-mcrypt=/usr/local' '--with-zlib=/usr' '--with-openssl' Apache was configured with: ./configure enable-rewrite=shared enable-status=shared enable-ssl=shared Please advise Previous Comments: [2006-09-24 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. [2006-09-16 17:28:31] m...@php.net Uhm right, because the actual name is --enable-versioning. IIRC that may be cause by some library only available statically whne you try to link. You need to identify it and either build a shared lib or build withgout its support enabled. [2006-09-16 15:36:44] shorb at optonline dot net Without that, compilation still fails [2006-09-16 10:52:37] m...@php.net Please don't ever use --with-versioning. [2006-09-15 23:12:12] shorb at optonline dot net Description: 'make install' fails because shared lib (.so is not created) mod_so is installed on apache [r...@steve php-5.1.6]# make install Installing PHP SAPI module: apache2handler /opt/httpd/build/instdso.sh SH_LIBTOOL='/opt/httpd/build/libtool' libphp5.la /opt/httpd/modules /opt/httpd/build/libtool --mode=install cp libphp5.la /opt/httpd/modules/ cp .libs/libphp5.lai /opt/httpd/modules/libphp5.la cp .libs/libphp5.a /opt/httpd/modules/libphp5.a ranlib /opt/httpd/modules/libphp5.a chmod 644 /opt/httpd/modules/libphp5.a libtool: install: warning: remember to run `libtool --finish /root/php-5.1.6/libs' Warning! dlname not found in /opt/httpd/modules/libphp5.la. Assuming installing a .so rather than a libtool archive. chmod 755 /opt/httpd/modules/libphp5.so chmod: cannot access `/opt/httpd/modules/libphp5.so': No such file or directory apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 The compiler log from 'make' shows this: *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libphp5. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. Reproduce code: --- ./configure --with-apxs2=/opt/httpd/bin/apxs --prefix=/opt/httpd/php5 --sharedstatedir=/opt/httpd/php5/com --enable-discard-path --disable-force-cgi-redirect --disable-debug --disable-rpath --enable-inline-optimization --enable-memory-limit --with-config-file-path=/opt/httpd/php5/etc --with-peardir=/opt/httpd/php5/share/pear --enable-magic-quotes --enable-debugger --enable-track-vars --with-exec-dir=/usr/bin --with-versioning --with-regex=php --enable-trans-sid --enable-safe-mode --enable-ctype --enable-ftp --with-gettext=/usr --enable-posix --enable-session --enable-sysvsem --enable-sysvshm --enable-yp --with-openssl=/usr --with-kerberos --with-ttf --with-freetype-dir=/usr --with-zlib --with-mysql=/usr --with-sqlite --with-gd --with-imap --with-imap-ssl --with-ldap --enable-bcmath --enable-calendar --with-curl --enable-dba --with-gd --with-gmp --with-ldap --with-mcal=/usr/local --with-mycrypt --with-mime-magic --with-ncurses --with-unixODBC --enable-xml --with-jpeg-dir --with-zlib-dir --with-tiff-dir --with-pspell --with-png-dir=/usr/lib --with-mysql-sock=/var/lib/mysql --with-dom --with-mcrypt --with-iconv --enable-mbstring --with-mbstring=all -- Edit this bug report at http://bugs.php.net/?id=38851edit=1
#48926 [Bgs]: Configure option --enable-fastcgi doesn't work
ID: 48926 User updated by: abel dot martin dot ruiz at gmail dot com Reported By: abel dot martin dot ruiz at gmail dot com Status: Bogus Bug Type: Compile Failure Operating System: RHEL 5 PHP Version: 5.2.10 New Comment: OK. I did what you told me and everything works like a charm. Thanks for your help. Previous Comments: [2009-07-16 13:31:28] j...@php.net Ah. You can't build 3 SAPIs the same time. It's either CGI and CLI or Apache and CLI. This is not a bug. Also this is wrong: --with-mcrypt=/usr/local/lib NEVER ever add /lib in any paths passed to configure options! [2009-07-16 06:47:27] abel dot martin dot ruiz at gmail dot com I didn't do a make clean, true. The line was this: ./configure --enable-bcmath --enable-dba--with-gd --with-ldap --enable-mbstring --with-mcrypt=/usr/local/lib --with-mysql --with-unixODBC=/usr --with-pear --with-snmp --enable-zip --with-openssl --with-pdo-mysql --with-mhash --enable-soap --with-curl --enable-ftp --enable-fastcgi I configured the sources from a fresh untarred tarball with the line above and I got fcgi support: PHP 5.2.10 (cgi-fcgi) (built: Jul 16 2009 08:31:45) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Another thing I noticed (done with newly untarred sources, again) is that php-cgi doesn't get built if I enable mod_php with --with-apxs2=/usr/sbin/apxs before --enable-fastcgi. Not sure if both options are mutually exclusive). This was the line: ./configure --enable-bcmath --enable-dba--with-gd --with-ldap --enable-mbstring --with-mcrypt=/usr/local/lib --with-mysql --with-unixODBC=/usr --with-pear --with-snmp --enable-zip --with-openssl --with-pdo-mysql --with-mhash --enable-soap --with-curl --enable-ftp --with-apxs2=/usr/sbin/apxs --enable-fastcgi Thanks for your quick reply! [2009-07-15 16:03:50] j...@php.net What was the full configure line? Did you do it on clean sources where configure hadn't been run before? Where there any warnings about unknown options after configure? make clean ? [2009-07-15 13:01:18] abel dot martin dot ruiz at gmail dot com Description: Fastcgi support isn't enabled even though configure is invoked with option --enable-fastcgi. When running ./sapi/cgi/php-cgi -v the ouput is: PHP 5.2.10 (cgi) (built: Jul 15 2009 08:28:33) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Note the (cgi) instead of the expected (cgi-fcgi). -- Edit this bug report at http://bugs.php.net/?id=48926edit=1
#48926 [Fbk-Opn]: Configure option --enable-fastcgi doesn't work
ID: 48926 User updated by: abel dot martin dot ruiz at gmail dot com Reported By: abel dot martin dot ruiz at gmail dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: RHEL 5 PHP Version: 5.2.10 New Comment: I didn't do a make clean, true. The line was this: ./configure --enable-bcmath --enable-dba--with-gd --with-ldap --enable-mbstring --with-mcrypt=/usr/local/lib --with-mysql --with-unixODBC=/usr --with-pear --with-snmp --enable-zip --with-openssl --with-pdo-mysql --with-mhash --enable-soap --with-curl --enable-ftp --enable-fastcgi I configured the sources from a fresh untarred tarball with the line above and I got fcgi support: PHP 5.2.10 (cgi-fcgi) (built: Jul 16 2009 08:31:45) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Another thing I noticed (done with newly untarred sources, again) is that php-cgi doesn't get built if I enable mod_php with --with-apxs2=/usr/sbin/apxs before --enable-fastcgi. Not sure if both options are mutually exclusive). This was the line: ./configure --enable-bcmath --enable-dba--with-gd --with-ldap --enable-mbstring --with-mcrypt=/usr/local/lib --with-mysql --with-unixODBC=/usr --with-pear --with-snmp --enable-zip --with-openssl --with-pdo-mysql --with-mhash --enable-soap --with-curl --enable-ftp --with-apxs2=/usr/sbin/apxs --enable-fastcgi Thanks for your quick reply! Previous Comments: [2009-07-15 16:03:50] j...@php.net What was the full configure line? Did you do it on clean sources where configure hadn't been run before? Where there any warnings about unknown options after configure? make clean ? [2009-07-15 13:01:18] abel dot martin dot ruiz at gmail dot com Description: Fastcgi support isn't enabled even though configure is invoked with option --enable-fastcgi. When running ./sapi/cgi/php-cgi -v the ouput is: PHP 5.2.10 (cgi) (built: Jul 15 2009 08:28:33) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Note the (cgi) instead of the expected (cgi-fcgi). -- Edit this bug report at http://bugs.php.net/?id=48926edit=1
#48926 [NEW]: Configure option --enable-fastcgi doesn't work
From: abel dot martin dot ruiz at gmail dot com Operating system: RHEL 5 PHP version: 5.2.10 PHP Bug Type: *Compile Issues Bug description: Configure option --enable-fastcgi doesn't work Description: Fastcgi support isn't enabled even though configure is invoked with option --enable-fastcgi. When running ./sapi/cgi/php-cgi -v the ouput is: PHP 5.2.10 (cgi) (built: Jul 15 2009 08:28:33) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Note the (cgi) instead of the expected (cgi-fcgi). -- Edit bug report at http://bugs.php.net/?id=48926edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48926r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48926r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48926r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48926r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48926r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48926r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48926r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48926r=needscript Try newer version: http://bugs.php.net/fix.php?id=48926r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48926r=support Expected behavior: http://bugs.php.net/fix.php?id=48926r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48926r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48926r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48926r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48926r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48926r=dst IIS Stability: http://bugs.php.net/fix.php?id=48926r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48926r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48926r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48926r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48926r=mysqlcfg
#47767 [Com]: include_once does not resolve windows symlinks or junctions
ID: 47767
Comment by: martin at curlybracket dot de
Reported By: lukemoynihan at gmail dot com
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: win32 only - Windows Vista
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
I've tryed symlinked files and that is working for me, you're right.
So, maybe the symlinked directory thing is another but related bug,
right? I've also tryed the latest snapshot, but the problem is the same
for me.
Previous Comments:
[2009-06-17 19:37:30] paj...@php.net
Does it work for you for symlinked files? Or does it fail too?
[2009-06-17 12:43:22] martin at curlybracket dot de
I've just checked the snapshot
PHP 5.3 (5.3.0RC4-dev) VC6 x86 Non Thread Safe (2009-Jun-17 13:00:00)
(Zip, sha1: 269d823708ed9bec3cd4ab5ca563245ed6aed820)
and neither symlink nor junction is working for me. My scenario is a
bit different, i'm linking not a file but a directory:
D:\dev\lib is the target.
D:\dev\link is the symlink/junction.
When i try to include the file D:\dev\link\test.php i get the following
error:
Warning: include_once(D:\dev\link\test.php) [function.include-once]:
failed to open stream: No such file or directory in
D:\dev\test-47767.php on line 2
Fatal error: include_once() [function.include]: Failed opening required
'D:\dev\link\test.php' (include_path='.') in D:\dev\test-47767.php on
line 2
is_file('D:\dev\link\test.php') returns true and an include to
D:\dev\lib\test.php is working correctly.
[2009-06-16 00:21:16] paj...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-03-26 02:47:05] lukemoynihan at gmail dot com
Ok, I can understand not wanting to support Junctions, It would be
fantastic to support symlinks though - this is bound to come up more
as people on windows learn to use links, if you need any testing done
for this let me know.
[2009-03-25 11:13:31] paj...@php.net
Ok, will see what can be done for symlink. I'm not sure 2k/xp are worst
a hack, but 2k8/vista/win7 have real symlinks support.
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/47767
--
Edit this bug report at http://bugs.php.net/?id=47767edit=1
#47767 [Com]: include_once does not resolve windows symlinks or junctions
ID: 47767
Comment by: martin at curlybracket dot de
Reported By: lukemoynihan at gmail dot com
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: win32 only - Windows Vista
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
I've just checked the snapshot
PHP 5.3 (5.3.0RC4-dev) VC6 x86 Non Thread Safe (2009-Jun-17 13:00:00)
(Zip, sha1: 269d823708ed9bec3cd4ab5ca563245ed6aed820)
and neither symlink nor junction is working for me. My scenario is a
bit different, i'm linking not a file but a directory:
D:\dev\lib is the target.
D:\dev\link is the symlink/junction.
When i try to include the file D:\dev\link\test.php i get the following
error:
Warning: include_once(D:\dev\link\test.php) [function.include-once]:
failed to open stream: No such file or directory in
D:\dev\test-47767.php on line 2
Fatal error: include_once() [function.include]: Failed opening required
'D:\dev\link\test.php' (include_path='.') in D:\dev\test-47767.php on
line 2
is_file('D:\dev\link\test.php') returns true and an include to
D:\dev\lib\test.php is working correctly.
Previous Comments:
[2009-06-16 00:21:16] paj...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-03-26 02:47:05] lukemoynihan at gmail dot com
Ok, I can understand not wanting to support Junctions, It would be
fantastic to support symlinks though - this is bound to come up more
as people on windows learn to use links, if you need any testing done
for this let me know.
[2009-03-25 11:13:31] paj...@php.net
Ok, will see what can be done for symlink. I'm not sure 2k/xp are worst
a hack, but 2k8/vista/win7 have real symlinks support.
[2009-03-25 10:51:01] andrew at mcgl dot co dot nz
Have the same problem on V5.2.8 running on windows XP
[2009-03-25 02:15:55] lukemoynihan at gmail dot com
FYI: I've tested this on Windows XP, Vista to get the results for
windows, and Centos 5 for linux results
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/47767
--
Edit this bug report at http://bugs.php.net/?id=47767edit=1
#41027 [Fbk-Opn]: Executing prepared statement changes type of bound parameters to string
ID: 41027 User updated by: martin at bangaroo dot net Reported By: martin at bangaroo dot net -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.2CVS-2009-04-26 Assigned To: wez New Comment: Same result with php5.3-200904271830: Bug still present. Previous Comments: [2009-04-27 15:33:21] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-04-26 18:30:35] martin at bangaroo dot net I just checked with the snapshot php5.2-200904261630. Unfortunately the bug still exists. [2009-04-25 14:44:51] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2007-04-09 14:31:34] martin at bangaroo dot net Description: Executing a prepared statement changes the type of bound parameters to string (Tested only with pgsql driver). This bite me when I wanted to execute an insert statement only when the double value to be inserted actually changed, NULL being a possible value. Unfortunatly, comparing the new value with the old value with the !== operator didn't work, because the type-change made the test always evaluate to TRUE. Reproduce code: --- ?php $db = new PDO(pgsql:host=localhost dbname=test user=dummy); $db-query(CREATE TABLE test_table ( val REAL )); $qry = $db-prepare(INSERT INTO test_table VALUES (:val)); $qry-bindParam(:val,$bound_val); $bound_val = 5.2; echo Type before execute(): .gettype($bound_val).\n; $qry-execute(); echo Type after execute(): .gettype($bound_val).\n; $db-query(DROP TABLE test); ? Expected result: Type before execute(): double Type after execute(): double Actual result: -- Type before execute(): double Type after execute(): string -- Edit this bug report at http://bugs.php.net/?id=41027edit=1
#41027 [Fbk-Opn]: Executing prepared statement changes type of bound parameters to string
ID: 41027 User updated by: martin at bangaroo dot net Reported By: martin at bangaroo dot net -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.2.1 Assigned To: wez New Comment: I just checked with the snapshot php5.2-200904261630. Unfortunately the bug still exists. Previous Comments: [2009-04-25 14:44:51] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2007-04-09 14:31:34] martin at bangaroo dot net Description: Executing a prepared statement changes the type of bound parameters to string (Tested only with pgsql driver). This bite me when I wanted to execute an insert statement only when the double value to be inserted actually changed, NULL being a possible value. Unfortunatly, comparing the new value with the old value with the !== operator didn't work, because the type-change made the test always evaluate to TRUE. Reproduce code: --- ?php $db = new PDO(pgsql:host=localhost dbname=test user=dummy); $db-query(CREATE TABLE test_table ( val REAL )); $qry = $db-prepare(INSERT INTO test_table VALUES (:val)); $qry-bindParam(:val,$bound_val); $bound_val = 5.2; echo Type before execute(): .gettype($bound_val).\n; $qry-execute(); echo Type after execute(): .gettype($bound_val).\n; $db-query(DROP TABLE test); ? Expected result: Type before execute(): double Type after execute(): double Actual result: -- Type before execute(): double Type after execute(): string -- Edit this bug report at http://bugs.php.net/?id=41027edit=1
#42893 [Com]: segfault on ia64 when working w/ constants
ID: 42893 Comment by: xavier dot martin at enovance dot com Reported By: hoffie at gentoo dot org Status: No Feedback Bug Type: Reproducible crash Operating System: Linux on ia64 PHP Version: 5.2.5 New Comment: Same issue with: * Sun UltraSparc * php-5.2.8 * gcc 4.3 (debian stable, lenny) * default CFLAGS (gdb) run -n -r 'var_dump(defined(foo));' Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf7fcc6b0 (LWP 29465)] 0x002ceb88 in _zval_ptr_dtor (zval_ptr=0xffee16f4) at /tmp/src/php- 5.2.8/Zend/zend_execute_API.c:412 412 (*zval_ptr)-refcount--; Previous Comments: [2008-07-26 01:00:00] 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-07-18 16:23:05] j...@php.net Even if some change between PHP versions is causing this, it's only happening on ia64, so it might as well be a bug in the compiler. Have you tried more recent GCC version..? [2008-06-26 00:56:54] ryan dot oliver at dse dot vic dot gov dot au Same issue here with php-5.2.6 on ia64 (SGI Prism w SLES 9 SP3) using gcc-4.2.4 + binutils-2.18.0. As soon as debugging symbols are enabled (CFLAGS=-g or ./configure --enable-debug) the problem disappears ... Issue appears from my rudimentary tests to be due to compiler optimizations, debug symbols have no bearing on the issue Compiled with CFLAGS=-O0 CXXFLAGS=-O0 no segfault occurs. Compiled with CFLAGS=-O1 CXXFLAGS=-O1 no segfault occurs. So whatever the issue is, it is exposed by one/some of the 27 -O2 gcc optimizations. [2007-11-17 09:07:52] hoffie at gentoo dot org I've only tried Gentoo and Debian so far, but I think this should be sufficient. If it fails on two distros and previous versions of php worked (and still work) then it's likely that it is a bug which got introduced with php-5.2, isn't it? If you still want me to try it on another distro, please point me to some resource to easily install one (like Debians debootstrap). [2007-11-17 01:56:02] j...@php.net Can you reproduce this with any linux distro on that machine? 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/42893 -- Edit this bug report at http://bugs.php.net/?id=42893edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285
Comment by: martin at 925 dot dk
Reported By: danger at FreeBSD dot org
Status: Assigned
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.8
Assigned To: derick
New Comment:
This patch (which reverts the fix for bug 45529) against parse_date.c
seems to fix the leak:
Hence this patch against parse_date.c:
--- parse_date_.c 2009-03-09 19:33:37.0 +0100
+++ parse_date.c2009-03-09 19:33:45.0 +0100
@@ -733,7 +733,7 @@
}
#endif
/* If we have a TimeZone identifier to start with, use
it */
- if (strstr(tz_abbr, /) || strcmp(tz_abbr, UTC) ==
0) {
+ if (strstr(tz_abbr, /)) {
if ((res = timelib_parse_tzfile(tz_abbr,
tzdb)) != NULL) {
t-tz_info = res;
t-zone_type = TIMELIB_ZONETYPE_ID;
Previous Comments:
[2009-02-27 14:48:14] maarten at vivesta dot com
Same here. I've added a date_default_timezone_set() before using
strtotime() and it removed the error but not the leak.
[2009-02-27 13:53:29] danger at FreeBSD dot org
I tried to run my script with php -d error_reporting=E_STRICT test.php
and been receiving this error until I stopped the script:
Strict Standards: strtotime(): It is not safe to rely on the system's
timezone settings. Please use the date.timezone setting, the TZ
environment variable or the date_default_timezone_set() function. In
case you used any of those methods and you are still getting this
warning, you most likely misspelled the timezone identifier. We selected
'Europe/Berlin' for 'CET/1.0/no DST' instead in /root/test.php on line
10
[2009-02-27 13:25:37] danger at FreeBSD dot org
Hey there,
I have tried to build a stock php-5.2.9 (no FreeBSD patches or anything
else) with ./configure make.
When I run my test script as this:
r...@[temp /var/ports/distfiles/php-5.2.9]# sapi/cli/php
/root/test.php
No modified php.ini is being used, no additional extensions are being
loaded. I can still verify that it leaks.
[2009-02-27 11:44:35] der...@php.net
I am not forgetting about this, but at the moment just really occupied.
Just as a quick question, this is the *stock* PHP without any ports
patches, also, if you set the error level to also show e_Strict
messages, do you see anything? Also, do you have the date.timezone
setting made in PHP.ini?
[2009-02-27 10:41:02] danger at FreeBSD dot org
verified to still leak with:
r...@[temp /basejail/usr/ports/lang/php5]# php -v
PHP 5.2.9 (cli) (built: Feb 27 2009 11:36:57)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
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/47285
--
Edit this bug report at http://bugs.php.net/?id=47285edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285
Comment by: martin at 925 dot dk
Reported By: danger at FreeBSD dot org
Status: Assigned
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.8
Assigned To: derick
New Comment:
Removing UTC from the timestamp in php_date.c also fixes the leak:
--- php_date_.c 2009-03-09 22:30:15.0 +0100
+++ php_date.c 2009-03-09 22:30:21.0 +0100
@@ -1117,7 +1117,7 @@
now = timelib_time_ctor();
initial_ts = emalloc(25);
- snprintf(initial_ts, 24, @%ld UTC, preset_ts);
+ snprintf(initial_ts, 24, @%ld, preset_ts);
t = timelib_strtotime(initial_ts, strlen(initial_ts),
NULL, DATE_TIMEZONEDB); /* we ignore the error here, as this should
never fail */
timelib_update_ts(t, tzi);
now-tz_info = tzi;
Previous Comments:
[2009-03-09 18:46:22] martin at 925 dot dk
This patch (which reverts the fix for bug 45529) against parse_date.c
seems to fix the leak:
Hence this patch against parse_date.c:
--- parse_date_.c 2009-03-09 19:33:37.0 +0100
+++ parse_date.c2009-03-09 19:33:45.0 +0100
@@ -733,7 +733,7 @@
}
#endif
/* If we have a TimeZone identifier to start with, use
it */
- if (strstr(tz_abbr, /) || strcmp(tz_abbr, UTC) ==
0) {
+ if (strstr(tz_abbr, /)) {
if ((res = timelib_parse_tzfile(tz_abbr,
tzdb)) != NULL) {
t-tz_info = res;
t-zone_type = TIMELIB_ZONETYPE_ID;
[2009-02-27 14:48:14] maarten at vivesta dot com
Same here. I've added a date_default_timezone_set() before using
strtotime() and it removed the error but not the leak.
[2009-02-27 13:53:29] danger at FreeBSD dot org
I tried to run my script with php -d error_reporting=E_STRICT test.php
and been receiving this error until I stopped the script:
Strict Standards: strtotime(): It is not safe to rely on the system's
timezone settings. Please use the date.timezone setting, the TZ
environment variable or the date_default_timezone_set() function. In
case you used any of those methods and you are still getting this
warning, you most likely misspelled the timezone identifier. We selected
'Europe/Berlin' for 'CET/1.0/no DST' instead in /root/test.php on line
10
[2009-02-27 13:25:37] danger at FreeBSD dot org
Hey there,
I have tried to build a stock php-5.2.9 (no FreeBSD patches or anything
else) with ./configure make.
When I run my test script as this:
r...@[temp /var/ports/distfiles/php-5.2.9]# sapi/cli/php
/root/test.php
No modified php.ini is being used, no additional extensions are being
loaded. I can still verify that it leaks.
[2009-02-27 11:44:35] der...@php.net
I am not forgetting about this, but at the moment just really occupied.
Just as a quick question, this is the *stock* PHP without any ports
patches, also, if you set the error level to also show e_Strict
messages, do you see anything? Also, do you have the date.timezone
setting made in PHP.ini?
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/47285
--
Edit this bug report at http://bugs.php.net/?id=47285edit=1
#47565 [NEW]: Extend serialize and unserialize with encryption key.
From: martin at itmission dot com Operating system: PHP version: 5.3.0beta1 PHP Bug Type: Feature/Change Request Bug description: Extend serialize and unserialize with encryption key. Description: Request: Add simple encryption support to serialize and unserialize. Rationale: It is useful to be able to serialize an object and hide it in a form variable on a web page. This is vulnerable to tampering by the end user. serialize(mixed $value[, string $key]) unserialize(string $str[, string $key]) This new definition won't break existing code and could be implemented using a TEA variant in a few lines. It would be nice if objects didn't have to be persisted in $_SESSION, because some power users want to use multiple windows to work with different objects simultaneously (editing two invoice objects at the same time, but commiting only complete changes of each). -- Edit bug report at http://bugs.php.net/?id=47565edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47565r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47565r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47565r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47565r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47565r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47565r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47565r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47565r=needscript Try newer version: http://bugs.php.net/fix.php?id=47565r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47565r=support Expected behavior: http://bugs.php.net/fix.php?id=47565r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47565r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47565r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47565r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47565r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47565r=dst IIS Stability: http://bugs.php.net/fix.php?id=47565r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47565r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47565r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47565r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47565r=mysqlcfg
#47388 [Opn]: Array Foreach Reference Broken
ID: 47388
User updated by: martin at itmission dot com
Reported By: martin at itmission dot com
Status: Open
-Bug Type: Feature/Change Request
+Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
Changed category
Previous Comments:
[2009-02-14 19:47:28] martin at itmission dot com
Description:
When using foreach on an array using the reference syntax, stuff breaks
later.
Reproduce code:
---
?php
$a = array(0, 1, 2, 3, 4);
foreach($a as $k = $v)
{
$v++;
}
foreach($a as $k = $v)
{
echo($k = $v\n);
}
?
Expected result:
0 = 1
1 = 2
2 = 3
3 = 4
4 = 5
Actual result:
--
0 = 1
1 = 2
2 = 3
3 = 4
4 = 4
--
Edit this bug report at http://bugs.php.net/?id=47388edit=1
#47388 [Com]: Array Foreach Reference Broken
ID: 47388
Comment by: martin at itmission dot com
Reported By: martin at itmission dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
Also happens in 5.2.8
Previous Comments:
[2009-02-16 18:56:12] martin at itmission dot com
Changed category
[2009-02-14 19:47:28] martin at itmission dot com
Description:
When using foreach on an array using the reference syntax, stuff breaks
later.
Reproduce code:
---
?php
$a = array(0, 1, 2, 3, 4);
foreach($a as $k = $v)
{
$v++;
}
foreach($a as $k = $v)
{
echo($k = $v\n);
}
?
Expected result:
0 = 1
1 = 2
2 = 3
3 = 4
4 = 5
Actual result:
--
0 = 1
1 = 2
2 = 3
3 = 4
4 = 4
--
Edit this bug report at http://bugs.php.net/?id=47388edit=1
#47388 [Bgs]: Array Foreach Reference Broken
ID: 47388
User updated by: martin at itmission dot com
Reported By: martin at itmission dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
The error is in my code. Sorry. Always unset variables after a
foreach with a reference unless you know what you are doing.
unset($v);
Previous Comments:
[2009-02-16 19:15:58] der...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
.
[2009-02-16 18:57:13] martin at itmission dot com
Also happens in 5.2.8
[2009-02-16 18:56:12] martin at itmission dot com
Changed category
[2009-02-14 19:47:28] martin at itmission dot com
Description:
When using foreach on an array using the reference syntax, stuff breaks
later.
Reproduce code:
---
?php
$a = array(0, 1, 2, 3, 4);
foreach($a as $k = $v)
{
$v++;
}
foreach($a as $k = $v)
{
echo($k = $v\n);
}
?
Expected result:
0 = 1
1 = 2
2 = 3
3 = 4
4 = 5
Actual result:
--
0 = 1
1 = 2
2 = 3
3 = 4
4 = 4
--
Edit this bug report at http://bugs.php.net/?id=47388edit=1
#47388 [NEW]: Array Foreach Reference Broken
From: martin at itmission dot com
Operating system: Windows XP
PHP version: 5.3.0beta1
PHP Bug Type: Feature/Change Request
Bug description: Array Foreach Reference Broken
Description:
When using foreach on an array using the reference syntax, stuff breaks
later.
Reproduce code:
---
?php
$a = array(0, 1, 2, 3, 4);
foreach($a as $k = $v)
{
$v++;
}
foreach($a as $k = $v)
{
echo($k = $v\n);
}
?
Expected result:
0 = 1
1 = 2
2 = 3
3 = 4
4 = 5
Actual result:
--
0 = 1
1 = 2
2 = 3
3 = 4
4 = 4
--
Edit bug report at http://bugs.php.net/?id=47388edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47388r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47388r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47388r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47388r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47388r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47388r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47388r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47388r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47388r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47388r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47388r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47388r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47388r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47388r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47388r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47388r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47388r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47388r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47388r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47388r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47388r=mysqlcfg
#46889 [Com]: Memory leak in strtotime()
ID: 46889
Comment by: martin at 925 dot dk
Reported By: tim at digicol dot de
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.2.8
Assigned To: derick
New Comment:
Reproduced here.
OS:
FreeBSD 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4
PHP:
PHP 5.2.8 (cli) (built: Dec 8 2008 19:11:49)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
Previous Comments:
[2008-12-17 16:55:59] php at degoulet dot net
same issue on centos
[2008-12-17 15:11:48] tim at digicol dot de
Description:
With PHP 5.2.8, strtotime() on my Linux box leaks memory; we've
noticed it because we're using long-running scripts with the PHP CLI.
In our case, the PHP processes grew to hundreds of MB RAM usage within
minutes. This is not the case with PHP 5.2.6.
The funny thing is that neither memory_get_usage(false) nor
memory_get_usage(true) report the actual memory usage; here's a line
from top:
22728 digicol 25 0 258m 218m 6928 R 75.4 43.4 0:42.91 php
... while the PHP functions report at the same time:
memory_get_usage(false): 1738020
memory_get_usage(true): 1835008
What's also funny is that the default memory_limit = 128M setting
doesn't help: PHP doesn't notice that this much RAM is being
used and so doesn't kill the script. (But I can trigger the memory
limit as usual with other PHP scripts, so PHP's memory limit isn't
entirely broken.)
I tested with an unchanged copy of php.ini-recommended.
My configure string:
'./configure' '--with-apxs2=/usr/bin/apxs2' '--enable-exif' '--
enable-ftp' '--enable-mbregex' '--enable-mbstring=all' '--enable-
pcntl' '--enable-soap' '--enable-zip' '--with-zlib' '--with-curl' '--
with-freetype-dir=/usr' '--with-gd' '--with-jpeg-dir=/usr' '--with-
ldap' '--with-mysqli' '--with-
oci8=instantclient,/usr/local/lib/instantclient' '--enable-sigchild'
'--with-png-dir=/usr' '--with-xsl' '--with-mcrypt'
This is Debian Linux 4.0, running in VMware Fusion on an Intel Mac.
Thanks a lot for looking into this, and for the great work on PHP!
Reproduce code:
---
?php
// Run with the PHP CLI on the Linux shell...
// WARNING: If this bug affects you as well, your machine
// might start swapping within just a few seconds!
while (true)
strtotime('2008-12-16 19:48:27');
?
Expected result:
No increase in memory usage.
Actual result:
--
Memory usage is increasing dramatically - on my box, the process is
growing by 100 MB per second...
--
Edit this bug report at http://bugs.php.net/?id=46889edit=1
#46123 [NEW]: Problem using arrays and value references
From: martin dot akesson at qbrick dot com
Operating system: FreeBSD 7.0
PHP version: 5.2.6
PHP Bug Type: Arrays related
Bug description: Problem using arrays and value references
Description:
Using a foreach loop to edit values by reference in an array will mangle
the array. From testing seems the last item in the array will be
replaced by the second last item. It seems the problem shows once the
array has been traversed start to end.
The code to reproduce the problem does a much better job describing the
issue.
Reproduce code:
---
?php
$list = array('one', 'two', 'three', 'four');
foreach ($list as $item) {
$item = Row $item;
}
print_r($list);
foreach ($list as $index = $item) {
printf(Item #%u: %s\n, $index, $item);
}
print_r($list);
?
Expected result:
Array
(
[0] = Row one
[1] = Row two
[2] = Row three
[3] = Row four
)
Item #0: Row one
Item #1: Row two
Item #2: Row three
Item #3: Row four
Array
(
[0] = Row one
[1] = Row two
[2] = Row three
[3] = Row four
)
Actual result:
--
Array
(
[0] = Row one
[1] = Row two
[2] = Row three
[3] = Row four
)
Item #0: Row one
Item #1: Row two
Item #2: Row three
Item #3: Row three
Array
(
[0] = Row one
[1] = Row two
[2] = Row three
[3] = Row three
)
--
Edit bug report at http://bugs.php.net/?id=46123edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46123r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46123r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46123r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46123r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46123r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46123r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46123r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46123r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46123r=support
Expected behavior:http://bugs.php.net/fix.php?id=46123r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46123r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46123r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46123r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46123r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46123r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46123r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46123r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46123r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46123r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46123r=mysqlcfg
#46123 [Bgs]: Problem using arrays and value references
ID: 46123
User updated by: martin dot akesson at qbrick dot com
Reported By: martin dot akesson at qbrick dot com
Status: Bogus
Bug Type: Arrays related
Operating System: FreeBSD 7.0
PHP Version: 5.2.6
New Comment:
Excellent! Thank you for the quick reply and sorry for wasting your
time.
Previous Comments:
[2008-09-19 13:15:53] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
After the first forach $item is still a reference to the last entry,
you then start to assign it again within your second loop.
The following code gives the behaviour you want.
?php
$list = array('one', 'two', 'three', 'four');
foreach ($list as $item) {
$item = Row $item;
}
unset($item);
print_r($list);
foreach ($list as $index = $item) {
printf(Item #%u: %s\n, $index, $item);
}
var_dump($list);
?
[2008-09-19 12:56:28] martin dot akesson at qbrick dot com
Description:
Using a foreach loop to edit values by reference in an array will
mangle
the array. From testing seems the last item in the array will be
replaced by the second last item. It seems the problem shows once the
array has been traversed start to end.
The code to reproduce the problem does a much better job describing the
issue.
Reproduce code:
---
?php
$list = array('one', 'two', 'three', 'four');
foreach ($list as $item) {
$item = Row $item;
}
print_r($list);
foreach ($list as $index = $item) {
printf(Item #%u: %s\n, $index, $item);
}
print_r($list);
?
Expected result:
Array
(
[0] = Row one
[1] = Row two
[2] = Row three
[3] = Row four
)
Item #0: Row one
Item #1: Row two
Item #2: Row three
Item #3: Row four
Array
(
[0] = Row one
[1] = Row two
[2] = Row three
[3] = Row four
)
Actual result:
--
Array
(
[0] = Row one
[1] = Row two
[2] = Row three
[3] = Row four
)
Item #0: Row one
Item #1: Row two
Item #2: Row three
Item #3: Row three
Array
(
[0] = Row one
[1] = Row two
[2] = Row three
[3] = Row three
)
--
Edit this bug report at http://bugs.php.net/?id=46123edit=1
#45282 [NEW]: SoapClient has namespace issues when WSDL is distributed
From: Martin dot Bosslet at googlemail dot com
Operating system: Windows XP SP2
PHP version: 5.2.6
PHP Bug Type: SOAP related
Bug description: SoapClient has namespace issues when WSDL is distributed
Description:
I have tried to access a web service whose WSDL is distributed among
several files each of which contains references to several further XSDs.
Now the WSDL itself is valid, as .NET or Java clients have accessed the
services without any problems. But when creating a new instance of
SoapClient it fails because I'm told that a certain element has already
been defined. The problem is, that there are message elements with the
same name, but they DO differ in namespaces.
Reproduce code:
---
$client = new SoapClient('someURI');
/* Please email me to get a copy of the WSDLs producing the error. They're
too large to be posted here (although I tried to keep them small already)
and I have no facility to make them available online. */
Expected result:
No error when parsing the WSDL.
Actual result:
--
SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: 'Element' already
defined in FILE
--
Edit bug report at http://bugs.php.net/?id=45282edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45282r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45282r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45282r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45282r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45282r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45282r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45282r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45282r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45282r=support
Expected behavior:http://bugs.php.net/fix.php?id=45282r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45282r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45282r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45282r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45282r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45282r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45282r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45282r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45282r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45282r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45282r=mysqlcfg
#38915 [Com]: Apache: system() (and similar) don't cleanup opened handles of Apache
ID: 38915 Comment by: martin at activevb dot de Reported By: dimmoborgir at gmail dot com Status: Open Bug Type: Feature/Change Request Operating System: UNIX PHP Version: 5.2.2, 4.4.7 New Comment: Will this ever be fixed... or shall we better rewrite our 3 lines of PHP code in Perl? :-| Is it possible to use apr_proc_create() and apr_pool_cleanup_for_exec() directly from PHP source code without patching PHP? Previous Comments: [2008-02-19 03:59:36] anomie at users dot sf dot net On 29 Jan 6:20pm UTC, adrian dot rollett at unt dot edu wrote: For those of you that found this page while looking for info on why exim is blocking port 80 after inheriting apache's file descriptors, I believe I found the reason for this. It seems that exim will only work with a maximum of 1000 file descriptors, (or 256 on older systems) after which point it will hang, consuming all available cpu cycles, and preventing apache from restarting. You should submit more detailed information on this to Exim's bug tracking system so it has a chance of being fixed. As far as this ridiculous bug, I've been working around it by using a small program that closes all FDs above 2 (either via the F_CLOSEM fcntl, reading /proc/self/fd, or just blindly calling close for every possible fd) and then execs the real program. [2008-01-29 18:20:39] adrian dot rollett at unt dot edu For those of you that found this page while looking for info on why exim is blocking port 80 after inheriting apache's file descriptors, I believe I found the reason for this. It seems that exim will only work with a maximum of 1000 file descriptors, (or 256 on older systems) after which point it will hang, consuming all available cpu cycles, and preventing apache from restarting. The only possible solutions I have found: 1. modify the source, and re-compile exim with a higher file descriptor limit. 2. run a cron job at regular intervals to search for hung exim processes and kill them. 3. switch MUAs. (postfix may fail more gracefully, but I haven't tried this yet) [2007-12-06 21:41:36] jameskyle at ucla dot edu Whether the blame lie with Apache or PHP is irrelevant. It directly impacts the security of PHP. Thus, the PHP team should work on a fix or apply substantial and vocal pressure on the Apache team. This would at least open discourse and allow the two teams to work toward a solution and determine the quickest path. The fact that this has remained a bug for an entire year is unacceptable. As is the relative silence on the topic from both of the primary development teams. [2007-12-06 20:56:01] gabe-php at mudbugmedia dot com I'm also running into a problem where, because my Apache is hosting 500+ vhosts, gobbling up 1000+ descriptors for logs. All this gets passed to any program it executes, causing problems with processes with a 1024 limit compiled in. Apache might be able to deal with having that many descriptors open, but we shouldn't assume anything PHP execs should. [2007-12-04 19:14:45] [EMAIL PROTECTED] I think that's exactly what FD_CLOEXEC does. 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/38915 -- Edit this bug report at http://bugs.php.net/?id=38915edit=1
#44208 [Bgs]: preg_* UTF-8 support breaks w/ external PCRE
ID: 44208
User updated by: martin dot adolfsson at movel dot se
Reported By: martin dot adolfsson at movel dot se
Status: Bogus
Bug Type: PCRE related
Operating System: Debian GNU/Linux 4.0
PHP Version: 5.2.5
New Comment:
It is quite possible that you are correct, and that the problem
actually is on my side, but I would like for you to consider the
following:
- All software is built on a dedicated build-host, by automated
scripts.
- No other installations of PCRE exists on the system.
- The same build-system is building a whole bunch of other software,
all without problems.
With this background, you can surely see why I feel that simply stating
that the problem is on my side is unsatisfactory, when all indications
show that PCRE has been build successfully with UTF-8 support.
Since this is a stripped, dedicated buildhost, I can provide you with
SSH access to it if you wish to validate my claims.
Previous Comments:
[2008-03-02 16:22:08] [EMAIL PROTECTED]
You've something broken on your end. I've compiled pcre with the same
options as you did and it worked correctly.
[2008-02-22 08:26:37] martin dot adolfsson at movel dot se
Might add some details from pcre-7.6:
pcre-7.6 configuration summary:
...
Enable UTF-8 support : yes
Unicode properties .. : yes
...
[src/pcre_tables.c]--
#ifdef SUPPORT_UTF8
const int _pcre_utf8_table1[] =...
.
[src/pcre_tables.c]--
$ strings lib/libpcre.a | grep pcre_utf8_table1
_pcre_utf8_table1
...
So AFAIK, PCRE has been built successfully w/ UTF-8 support.
[2008-02-22 08:03:39] martin dot adolfsson at movel dot se
Description:
Attempting to use external PCRE library (7.6), configured with
--enable-static
--disable-shared
--enable-utf8
--enable-unicode-properties
--disable-cpp
in PHP 5.2.5, configured with (among other options):
--with-pcre-regex={PATH_TO_PCRE_INSTALLATION}
Results in calls to preg_match() with /u modifier triggering an error
and stating that this version of PCRE is not compiled with PCRE_UTF8
support.
Reproduce code:
---
preg_match('//u', '' );
Expected result:
empty
Actual result:
--
preg_match() [a href='function.preg-match'function.preg-match/a]:
Compilation failed: this version of PCRE is not compiled with PCRE_UTF8
support at offset 0 in ...
--
Edit this bug report at http://bugs.php.net/?id=44208edit=1
#44305 [NEW]: odbc_next_result - mysql procedure with multiple results
From: martin dot dufka at atlas dot cz
Operating system: WIN2000
PHP version: 5.2.5
PHP Bug Type: ODBC related
Bug description: odbc_next_result - mysql procedure with multiple results
Description:
problem with: odbc_next_result()
mysql-server: 5.0.51a (.45-the same problem)
odbc driver: Driver={MySQL ODBC 3.51 Driver}
when MySQL procedure returns 2 rowsets, after the second rowset
odbc_next_result() returns true.
Reproduce code:
---
?php
/*
mysql:
CREATE PROCEDURE `multiplerowsets`()
BEGIN
select 'rs1';
select 'rs2';
END;
*/
$dsn=Driver={MySQL ODBC 3.51
Driver};Server=localhost;Port=3306;Database=db_name;;
$conn=odbc_connect($dsn,'user','passwd');
$query=call multiplerowsets;
$result=odbc_exec($conn,$query);
$row=odbc_fetch_array ($result); var_dump(odbc_next_result($result));
$row=odbc_fetch_array ($result); var_dump(odbc_next_result($result));
$row=odbc_fetch_array ($result); var_dump(odbc_next_result($result));
?
Expected result:
bool(true) bool(false) bool(false)
Actual result:
--
bool(true) bool(true)
Warning: odbc_fetch_array() [function.odbc-fetch-array]: No tuples
available at this result index in D:\Apache2.2\htdocs\test\x.php on line
19
bool(false)
--
Edit bug report at http://bugs.php.net/?id=44305edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44305r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44305r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44305r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44305r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44305r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44305r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44305r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44305r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44305r=support
Expected behavior:http://bugs.php.net/fix.php?id=44305r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44305r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44305r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44305r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44305r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44305r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44305r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44305r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44305r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44305r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44305r=mysqlcfg
#44229 [NEW]: Too many subpattern matches cause segfault
From: martin dot kevin at gmail dot com
Operating system: Debian
PHP version: 5.2CVS-2008-02-23 (snap)
PHP Bug Type: PCRE related
Bug description: Too many subpattern matches cause segfault
Description:
Matching a string against a pattern that will have many subpattern matches
causes a segmentation fault.
Reproduce code:
---
#!/usr/bin/env php
?php
$testPattern = EOS
/([^])+/
EOS;
$testString = '';
for ( $count = 0; $count 1030; $count++ )
$testString .= '\x90';
for ( $count = 1030; $count 4000; $count++ )
{
$testString .= '\x90';
echo $count\n;
preg_match ( $testPattern, $testString . '', $matches );
}
exit ( 0 );
?
Expected result:
Over 1000 matches:
[...]
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
Actual result:
--
Segmentation fault at either 1037 or 1038:
1030
1031
1032
1033
1034
1035
1036
1037
1038
Segmentation fault
Note that this seems to vary where it fails; either after 1037 matches or
1038 matches.
--
Edit bug report at http://bugs.php.net/?id=44229edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44229r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44229r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44229r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44229r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44229r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44229r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44229r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44229r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44229r=support
Expected behavior:http://bugs.php.net/fix.php?id=44229r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44229r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44229r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44229r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44229r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44229r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44229r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44229r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44229r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44229r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44229r=mysqlcfg
#44208 [NEW]: preg_* UTF-8 support breaks w/ external PCRE
From: martin dot adolfsson at movel dot se
Operating system: Debian GNU/Linux 4.0
PHP version: 5.2.5
PHP Bug Type: PCRE related
Bug description: preg_* UTF-8 support breaks w/ external PCRE
Description:
Attempting to use external PCRE library (7.6), configured with
--enable-static
--disable-shared
--enable-utf8
--enable-unicode-properties
--disable-cpp
in PHP 5.2.5, configured with (among other options):
--with-pcre-regex={PATH_TO_PCRE_INSTALLATION}
Results in calls to preg_match() with /u modifier triggering an error and
stating that this version of PCRE is not compiled with PCRE_UTF8 support.
Reproduce code:
---
preg_match('//u', '' );
Expected result:
empty
Actual result:
--
preg_match() [a href='function.preg-match'function.preg-match/a]:
Compilation failed: this version of PCRE is not compiled with PCRE_UTF8
support at offset 0 in ...
--
Edit bug report at http://bugs.php.net/?id=44208edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44208r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44208r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44208r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44208r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44208r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44208r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44208r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44208r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44208r=support
Expected behavior:http://bugs.php.net/fix.php?id=44208r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44208r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44208r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44208r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44208r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44208r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44208r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44208r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44208r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44208r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44208r=mysqlcfg
#44208 [Opn]: preg_* UTF-8 support breaks w/ external PCRE
ID: 44208
User updated by: martin dot adolfsson at movel dot se
Reported By: martin dot adolfsson at movel dot se
Status: Open
Bug Type: PCRE related
Operating System: Debian GNU/Linux 4.0
PHP Version: 5.2.5
New Comment:
Might add some details from pcre-7.6:
pcre-7.6 configuration summary:
...
Enable UTF-8 support : yes
Unicode properties .. : yes
...
[src/pcre_tables.c]--
#ifdef SUPPORT_UTF8
const int _pcre_utf8_table1[] =...
.
[src/pcre_tables.c]--
$ strings lib/libpcre.a | grep pcre_utf8_table1
_pcre_utf8_table1
...
So AFAIK, PCRE has been built successfully w/ UTF-8 support.
Previous Comments:
[2008-02-22 08:03:39] martin dot adolfsson at movel dot se
Description:
Attempting to use external PCRE library (7.6), configured with
--enable-static
--disable-shared
--enable-utf8
--enable-unicode-properties
--disable-cpp
in PHP 5.2.5, configured with (among other options):
--with-pcre-regex={PATH_TO_PCRE_INSTALLATION}
Results in calls to preg_match() with /u modifier triggering an error
and stating that this version of PCRE is not compiled with PCRE_UTF8
support.
Reproduce code:
---
preg_match('//u', '' );
Expected result:
empty
Actual result:
--
preg_match() [a href='function.preg-match'function.preg-match/a]:
Compilation failed: this version of PCRE is not compiled with PCRE_UTF8
support at offset 0 in ...
--
Edit this bug report at http://bugs.php.net/?id=44208edit=1
#44180 [NEW]: key in an array cannot be a reference in foreach loop
From: martin dot koranda at gmail dot com
Operating system: linux
PHP version: 5.2.5
PHP Bug Type: Feature/Change Request
Bug description: key in an array cannot be a reference in foreach loop
Description:
in foreach loop, if i try to use keys as a reference, i'll get Fatal
error: Key element cannot be a reference. my question is why not? can Zend
developers add the possibility of key element reference in the sixth PHP
version??
Reproduce code:
---
foreach($arr as $key = $val)
{
...
}
Expected result:
change keys inside the foreach loop
Actual result:
--
Fatal error: Key element cannot be a reference
--
Edit bug report at http://bugs.php.net/?id=44180edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44180r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44180r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44180r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44180r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44180r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44180r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44180r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44180r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44180r=support
Expected behavior:http://bugs.php.net/fix.php?id=44180r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44180r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44180r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44180r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44180r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44180r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44180r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44180r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44180r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44180r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44180r=mysqlcfg
#44132 [NEW]: mysql_connect hangs
From: martin-israel at gmx dot de
Operating system: Linux 2.6.23
PHP version: 5.2CVS-2008-02-15 (CVS)
PHP Bug Type: MySQL related
Bug description: mysql_connect hangs
Description:
Php hangs when the new_link parameter of the function mysql_connect is set
to FALSE.
Used for example by phpMyAdmin.
Sorry I've just tested it with PHP Version 5.2.5_p20080206
(The current latest Gentoo-Version)
Reproduce code:
---
?php
$link = mysql_connect('localhost', 'user', 'password', FALSE);
if (!$link) {
die('no connection possible: ' . mysql_error());
}
echo 'Connected!';
mysql_close($link);
?
Expected result:
Connected!
Actual result:
--
nothing, because the Server hangs.
--
Edit bug report at http://bugs.php.net/?id=44132edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44132r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44132r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44132r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44132r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44132r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44132r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44132r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44132r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44132r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44132r=support
Expected behavior:http://bugs.php.net/fix.php?id=44132r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44132r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44132r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44132r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44132r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44132r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44132r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44132r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44132r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44132r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44132r=mysqlcfg
#44061 [NEW]: When changing system tzdata, PHP keeps using the old timezone
From: martin at marquesminen dot com dot ar
Operating system: Linux
PHP version: 5.2.5
PHP Bug Type: Date/time related
Bug description: When changing system tzdata, PHP keeps using the old timezone
Description:
I got an update from tzdata on a Debian server due to a daylight saving
change here in Argentina (same thing happens on a Fedora 7 server).
The problem is that, even when the system sees the correct time, php keeps
giving me the *old* hour (CLI and mod_apache).
Reproduce code:
---
$ date
mié feb 6 09:03:57 ARST 2008
$ echo ?php echo date('H:i') . \\n\; ?|php
08:04
$ date +%z
-0200
$ echo ?php echo date('Z')/3600 . \\n\; ?|php
-3
--
Edit bug report at http://bugs.php.net/?id=44061edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44061r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44061r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44061r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44061r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44061r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44061r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44061r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44061r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44061r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44061r=support
Expected behavior:http://bugs.php.net/fix.php?id=44061r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44061r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44061r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44061r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44061r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44061r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44061r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44061r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44061r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44061r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44061r=mysqlcfg
#44022 [NEW]: Infinite loop with each( )
From: martin at bang dot ca
Operating system: Linux
PHP version: 4.4.8
PHP Bug Type: Arrays related
Bug description: Infinite loop with each( )
Description:
Infinite loop when using a function call which returns an array in each(
)
Reproduce code:
---
Infinite loop here (prints 1 - 1\n forever)
while( list( $k, $v ) = each( getTestArray() ) ) {
echo $k - $v\n;
}
function getTestArray() {
return array( 1 = 1 );
}
This works OK (prints 1 - 1 once):
$GLOBALS['test'] = array( 1 = 1 );
while( list( $k, $v ) = each( getTestArray() ) ) {
echo $k - $v\n;
}
function getTestArray() {
return $GLOBALS['test'];
}
--
Edit bug report at http://bugs.php.net/?id=44022edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44022r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44022r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44022r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44022r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44022r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44022r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44022r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44022r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44022r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44022r=support
Expected behavior:http://bugs.php.net/fix.php?id=44022r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44022r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44022r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44022r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44022r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44022r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44022r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44022r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44022r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44022r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44022r=mysqlcfg
