#47504 [Com]: error "SQLSTATE[HY000]: General error: 2014" with sql comments
ID: 47504 Comment by: admin at ifyouwantblood dot de Reported By: admin at ifyouwantblood dot de Status: Open Bug Type: PDO related Operating System: Windows XP SP 3 PHP Version: 5.2.8 New Comment: also appears in 5.2.9 Previous Comments: [2009-02-25 21:07:16] admin at ifyouwantblood dot de Description: i get this error with following code: - SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. HY000 #0 D:\_projects\web\1.php(13): PDO->query('INSERT INTO `te...') #1 {main} -- removing !SQL COMMENTS! will solve this. this only appears on windows (XP), linux is fine. mysql version is 5.0.51a. latest XAMPP package was used to test this (without modifications). Reproduce code: --- setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION); $pdo->query(' CREATE TABLE IF NOT EXISTS `test` ( `some` VARCHAR( 100 ) NOT NULL ) ENGINE = INNODB '); $pdo->query('SET TRANSACTION ISOLATION LEVEL SERIALIZABLE'); $pdo->query('START TRANSACTION'); $pdo->query("INSERT INTO `test` (some) VALUES (''), ('1'); -- I AM AN SQL COMMENT, REMOVING ME WILL SOLVE THIS PROBLEM"); $pdo->query("INSERT INTO `test` (some) VALUES (''), ('1')"); $pdo->query('COMMIT'); function ehandler($exception) { echo ''."\r\n"; echo $exception->getMessage().' '.$exception->getCode(); echo "\r\n\r\n"; echo $exception->getTraceAsString(); echo ''; } Expected result: nothing Actual result: -- SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. HY000 #0 D:\_projects\web\1.php(13): PDO->query('INSERT INTO `te...') #1 {main} -- Edit this bug report at http://bugs.php.net/?id=47504&edit=1
#42060 [Com]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)
ID: 42060 Comment by: jochen at keutel dot de Reported By: iarenuno at eteo dot mondragon dot edu Status: Assigned Bug Type: LDAP related Operating System: * PHP Version: 5CVS, 6CVS (2008-11-01) Assigned To: pajoye New Comment: I'd definitely need this patch going into an official PHP release. We're using PHP-LDAP to access the corporate directory - including authentication against the directory. We definitely need to support password policies. This patch would be the perfect solution. Regards, Jochen. Previous Comments: [2009-02-13 15:34:13] bartzy at gmail dot com Hi, I wanted to ask if there's anything new with this patch ? When will it be integrated into a PHP release ? Thank you ! [2009-01-12 03:38:01] Tyron dot Delean at unisa dot edu dot au I really really really really need Paging support for PHP LDAP calls. This is a super super super high priority for me to get an App working. Could somebody please tell me when the support for Paged Results from LDAP calls will be available, and what version of PHP will support it. I have checked the latest source versions for PHP 5.3 & PHP 6.0 snapshots and can't see it in there. I hope I am missing something. Extremely concerned. Tyron [2009-01-03 20:48:50] nelg at linuxsolutions dot co dot nz Hi, I am really keen to see this patch applied, as without it, the is some things that cannot easily be done in LDAP with PHP. Any progress? last comment seems to indicate it was going to be committed soon, but I don't see it in the php source tree yet. [2008-11-16 23:22:00] iarenuno at eteo dot mondragon dot edu pajoye, thanks a lot for your work to get this patch into core. This was a much needed feature in big LDAP installations. Saludos. Iñaki. [2008-11-16 14:57:56] paj...@php.net Alexey has ported the patch to 5.3, it will committed in the next days. 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/42060 -- Edit this bug report at http://bugs.php.net/?id=42060&edit=1
#47517 [Fbk->Opn]: php-cgi.exe missing UAC manifest
ID: 47517 User updated by: louis at steelbytes dot com Reported By: louis at steelbytes dot com -Status: Feedback +Status: Open Bug Type: Feature/Change Request Operating System: Win32 PHP Version: 5.2.9 New Comment: > Why do you need one? as originally stated, to avoid Vista's (or 2k8's) virtualisation of the file system. eg if from a script I attempt to write to c:\ProgramData\MyCompany\MyApp\file.ext and I don't have enough NTFS perms, then vista virtualises this into %USERPROFILE%\AppData\Local\VirtualStore\ProgramData\MyCompany\MyApp\file.ext instead of giving me an access denied error. > inherits the UAC from the caller no, but yes, but no. it the caller is elevated, then yes the spawned task (php) inherits this elevation. this is not the same thing that I am talking about though. if an app has this manifest embedded, then no matter what the elevation status or what perms the user has, file and reg operations won't be virtulised. .. note: this probably has very little relavence when run as cgi/fcgi on a webserver, but when running as a cli for misc scripts on my pc then it matters. really there is no reason to not have one that I can see. Previous Comments: [2009-02-27 09:13:05] paj...@php.net Why do you need one? php can be used in any situations and inherits (or is set by) the UAC from the caller (in case of fcgi or another SAPI for example). [2009-02-27 06:23:35] louis at steelbytes dot com reason: so that UAC won't virtualize file read/writes. [2009-02-27 03:51:48] louis at steelbytes dot com Description: php-cgi.exe (and I guess other php .exe's) should have a UAC manifest stating "asInvoker" Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=47517&edit=1
#47525 [NEW]: value returned from __call copied prematurely
From: rodricg at sellingsource dot com Operating system: linux PHP version: 5.2.9 PHP Bug Type: Class/Object related Bug description: value returned from __call copied prematurely Description: Values returned from the magic __call method are copied immediately resulting in increased memory usage. Reproduce code: --- str = str_repeat("a", 100); } public function __call($m, $a) {return $this->str;} public function getStr() {return $this->str;} } $a = new A(); mem('new A()'); $b = $a->str; mem('$a->str'); $c = $a->getStr(); mem('$a->getStr()'); $d = $a->magic(); mem('$a->magic()'); ?> Expected result: new A(): 1,310,720 $a->str: 1,310,720 $a->getStr(): 1,310,720 $a->magic(): 1,310,720 Actual result: -- new A(): 1,310,720 $a->str: 1,310,720 $a->getStr(): 1,310,720 $a->magic(): 2,359,296 -- Edit bug report at http://bugs.php.net/?id=47525&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47525&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47525&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47525&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47525&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47525&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47525&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47525&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47525&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47525&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47525&r=support Expected behavior: http://bugs.php.net/fix.php?id=47525&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47525&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47525&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47525&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47525&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47525&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47525&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47525&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47525&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47525&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47525&r=mysqlcfg
#47520 [Bgs->Fbk]: PHP segfaulted in preg_replace on processing long string
ID: 47520 Updated by: fel...@php.net Reported By: pahan at hubbitus dot spb dot su -Status: Bogus +Status: Feedback Bug Type: PCRE related Operating System: Linux PHP Version: 5.3.0beta1 New Comment: I cannot download the coredump file: "You don't have permission to access /_temp/php-pcre-bug/2/core.10135 on this server." Can you give us a backtrace? Previous Comments: [2009-02-27 20:06:13] pahan at hubbitus dot spb dot su I'm thrice check the previous reports about this issue. And what? All closed as bogus, but segmentatoin fault still here! Where solution/fix??? Even common workaraund of problem is absent. Why it is bogus but not bug??? And also, please again read note: I use "Once-only subpattern", so, this should prevent recursion as I can understand. Or not? [2009-02-27 19:37:00] fel...@php.net Please, check the previous reports about this issue: http://bugs.php.net/search.php?search_for=&boolean=1&limit=10&order_by=id&direction=DESC&cmd=display&status=Bogus&bug_type%5B%5D=PCRE+related&php_os=&phpver=&assign=&author_email=&bug_age=0 http://docs.php.net/manual/en/pcre.configuration.php [2009-02-27 11:13:58] pahan at hubbitus dot spb dot su Description: PHP segfaulted when I try replace in long string by next regexp: '((?>(?:[^']|(?<=\\\)')*))' Some comments to reproduce code comments to case 1 and 2 is clearly. In case 3 and 4 I just run script several times, like (assume file named test.php): for (( i=100; i>0; i-- )) ; do echo -n $i: ; ./test.php ; done Sample results of its run you may see here: http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by length of tested string), and for 4 - http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log Coredump may be downloaded here: http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135 Also, please note, I add construction (?> ... ) to speedup and dissallow recursion, so, it is must be different from bugs http://bugs.php.net/bug.php?id=27492 , http://bugs.php.net/bug.php?id=47376 , http://bugs.php.net/bug.php?id=47376 and http://bugs.php.net/bug.php?id=27310 . Reproduce code: --- //1: Always "segmantation fault" //$cont = "'" . str_pad('', 4000, '-');>//2: "Never" (Is I can see in 1000 iterations) "segmantation fault" //$cont = "'" . str_pad('', 4965, '-');>//3: Segfaulted from times to times ~ 1-2 times from 100 executions //$cont = "'" . str_pad('', 4967, '-');>//4: Segfaulted 50/50% $reg = "#'((?>(?:[^']|(?<=\\\)')*))'#"; preg_replace($reg, '', $cont); echo "OK\n"; ?> Expected result: OK Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=47520&edit=1
#47243 [Asn]: oci_fetch_assoc() causes Apache 2.2.11 crashed and restarted (SQL CURSOR)
ID: 47243 Updated by: s...@php.net Reported By: pcdinh at gmail dot com Status: Assigned Bug Type: OCI8 related Operating System: Windows XP SP3 PHP Version: 5.3.0beta1 Assigned To: sixd New Comment: Fix is being reviewed prior to testing. Previous Comments: [2009-02-03 02:16:21] s...@php.net Reproduces on Windows. Also crashes with --enable-maintainer-zts mode on Linux [2009-01-30 04:47:03] kureikain at gmail dot com I don't think that is a bug!I have ever had same problem(MySQL)!Because i used wrong version of libmysql.dll!I copied frm XAMPP to System32! &when i install PHP from zip package,i forget to overwrite libmysql.dll in system32!Apache keep crashing whenever PHP execs query [2009-01-29 19:19:15] pcdinh at gmail dot com Description: I wrote code to retrieve data that was returned from a query with Oracle cursor. However oci_fetch_assoc() causes Apache 2.2.11 being crashed and restarted. I am not sure if it is a Oracle client native library or OCI8 issue. Reproduce code: --- Expected result: Those code is a slightly modified version taken from PHP Manual http://vn2.php.net/oci_new_cursor It should be executed without any crash and data can be retrieved normally (as guided by PHP Manual) Actual result: -- Apache crashes and restarts Type of Analysis Performed Crash Analysis Machine Name HOME-4F44218659 Operating System Windows XP Service Pack 3 Number Of Processors 2 Process ID 2200 Process Image C:\server\Apache2.2\bin\httpd.exe System Up-Time 10:12:12 Process Up-Time 00:01:07 Thread 169 - System ID 2128 Entry point msvcrt!endthreadex+3a Create time 1/30/2009 1:57:53 AM Time spent in user mode 0 Days 0:0:0.15 Time spent in kernel mode 0 Days 0:0:0.93 Function Arg 1 Arg 2 Arg 3 Source OraClient10!kpufhndl0+33 4e5f544e 0002 OraClient10!kpufhndl+10 4e5f544e 0002 049ff9e8 OraClient10!OCIHandleFree+1a 4e5f544e 0002 0084eef0 oci!OCIHandleFree+1d 4e5f544e 0002 01b8a9d8 php_oci8!php_oci_statement_free+121 05ecf448 01b8a9d8 0083aa23 php_oci8!php_oci_statement_list_dtor+11 05ed09b8 01b8a9d8 01be5278 php5ts!list_entry_destructor+43 05ed09b8 01b8a9d8 05ed0988 php5ts!zend_hash_apply_deleter+97 01be5278 05ed0988 01b8a9d8 php5ts!zend_hash_apply_with_argument+5a 01be5278 01976a90 0022 php_oci8!zm_deactivate_oci+8a 0001 0029 01b8a9d8 php5ts!module_registry_cleanup+1c 00fd4ec8 01b8a9d8 01b8a9d8 php5ts!zend_hash_apply+40 00cd7340 007882c0 01b8a9d8 php5ts!zend_deactivate_modules+62 049fffa4 56433230 php5ts!zend_deactivate_modules+48 01b82a01 05ecc7c0 php5ts!php_end_ob_buffers+26 01b8a9d8 0073a040 01b8a9d8 php5ts!php_request_shutdown+247 00622fb6 01b82a18 php5apache2_2!php_apache_request_dtor+8 01b82a18 01b8a9d8 0005 php5apache2_2!php_handler+646 01b82a18 0073a040 01b82a18 libhttpd!ap_run_handler+21 01b82a18 01b82a18 01b82a18 libhttpd!ap_invoke_handler+ae 01b7d9c0 049fff38 libhttpd!ap_die+29e 01b82a18 007447a8 libhttpd!ap_get_request_note+1c9c 01b7d9c0 01b7d9c0 01b7d9c0 libhttpd!ap_run_process_connection+21 01b7d9c0 007121e8 049fff80 libhttpd!ap_process_connection+33 01b7d9c0 01b76990 00e4 libhttpd!ap_regkey_value_remove+c7c 01b7d9b8 00e4 00e8 msvcrt!endthreadex+a9 01b73958 00e4 00e8 kernel32!GetModuleFileNameA+1b4 77c3a341 01b73958 ORACLIENT10!KPUFHNDL0+33WARNING - DebugDiag was not able to locate debug symbols for OraClient10.Dll, so the information below may be incomplete. In httpd__PID__2200__Date__01_30_2009__Time_01_59_00AM__328__Second_Chance_Exception_C005.dmp the assembly instruction at OraClient10!kpufhndl0+33 in C:\oraclexe\app\oracle\product\10.2.0\server\BIN\OraClient10.Dll from Oracle Corporation has caused an access violation exception (0xC005) when trying to read from memory location 0x4e5f544e on thread 169 Module Information Image Name: C:\oraclexe\app\oracle\product\10.2.0\server\BIN\OraClient10.Dll Symbol Type: Export Base address: 0x61c2 Time Stamp: Wed Feb 01 04:19:50 2006 Checksum: 0x00251a65 Comments: COM DLL: False Company Name: Oracle Corporation ISAPIExtension: False File Description: Oracle RDBMS Client Libra
#42718 [Com]: FILTER_UNSAFE_RAW not applied when configured as default filter, even with flags
ID: 42718 Comment by: sultant08 at gmail dot com Reported By: arnaud dot lb at gmail dot com Status: Assigned Bug Type: Filter related Operating System: * PHP Version: 5CVS-2008-11-01 Assigned To: pajoye New Comment: ÇáÑÌÇÁ ÊÛíÑ ÇááÛÉ Çáí ÇáÚÑÈíÉ áåÐÇ ÇáÇÕÏÇÑ Previous Comments: [2009-01-09 18:37:04] tarmuli at hotmail dot com Thaks!baybay [2008-12-06 19:20:34] paj...@php.net Yes, revert was the best option for now. I will dig into it on Monday and re read the discussions about that (there was some discussions about this whole thing when we added filter to core). [2008-12-06 19:17:09] lbarn...@php.net > That's wrong This is exactly what you said one year ago, just before it was demonstrated that FILTER_UNSAFE_RAW actually does something (according to documentation, code, and examples), and the bug has been assigned to you. That said, I'm not rejecting the fault on anyone, and the important is to revert, which is done. [2008-12-06 18:25:20] paj...@php.net ooch. I did not catch in this bug before, but there is a major misunderstanding in the first comment. "The unsafe_raw filter does nothing by default, but it can "optionally strip or encode special characters", and it is the only filter which is able to do that without doing any other filtering." That's wrong. UNSAFE_RAW, the key word here is RAW. It means that the data is returned unfiltered, without flag, nothing, nada. If this behavior has been changed then please revert it. I did not check if it is present in 5.2.7 (it seems to be, as said in this report or another), that may require a quick fix release (Ilia?). [2008-12-06 17:52:37] lbarn...@php.net All my apologizes for this broken fix. A quick workaround for 5.2.7 users is to add the following in the php.ini: filter.default_flags=0 Scott has reverted this and this bug is not present in CVS. 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/42718 -- Edit this bug report at http://bugs.php.net/?id=42718&edit=1
#47513 [Com]: when using date, H shows 01 instead of 00
ID: 47513 Comment by: shaunspiller at gmail dot com Reported By: usrhlp at yahoo dot com Status: Open Bug Type: Date/time related Operating System: Debian PHP Version: 5.2.8 New Comment: It's the time zone on your machine. The number "5" refers to the time January 1 1970 @ 00:00:05 UTC, which date() will format as something different if you're in CET, etc. Use the format codes 'O' or 'P' to show the timezone offset. If you want it always fixed at UTC, use gmdate() instead of date(). Or use date_default_timezone_set first. E.g., if (version_compare(PHP_VERSION, '5.1.0', '>=')) { date_default_timezone_set('UTC'); } Previous Comments: [2009-02-26 23:07:57] usrhlp at yahoo dot com I just tried it on another server I have with php 5.2.6 and i get this result 18:00.01 18:00.10 18:01.40 18:16.40 20:46.40 21:46.40 07:46.40 12:46.40 That has totally thrown me off. [2009-02-26 22:59:30] usrhlp at yahoo dot com Description: I am probably doing something wrong but I cannot for the life of me figure out what it is. I am trying to convert a small number to 24 hour time format. For example I'm parsing the number 5 through the date function and I am receiving the answer 01:00.05 I checked the PHP documentation and it shows as this for date() H 24-hour format of an hour with leading zeros00 through 23 According to the documentation 00 is a possible output of the H formatting within date and should be what is coming out. Reproduce code: --- echo(date("H:i.s" ,1)); echo(date("H:i.s" ,10)); echo(date("H:i.s" ,100)); echo(date("H:i.s" ,1000)); echo(date("H:i.s" ,1)); echo(date("H:i.s" ,10)); echo(date("H:i.s" ,100)); echo(date("H:i.s" ,1000)); Expected result: time: 00:00.01 time: 00:00.10 time: 00:01.40 time: 00:16.40 time: 03:46.40 time: 04:46.40 time: 14:46.40 time: 18:46.40 Actual result: -- time: 01:00.01 time: 01:00.10 time: 01:01.40 time: 01:16.40 time: 03:46.40 time: 04:46.40 time: 14:46.40 time: 18:46.40 -- Edit this bug report at http://bugs.php.net/?id=47513&edit=1
#47524 [NEW]: register_func_function()
From: shaunspiller at gmail dot com Operating system: Irrelevant PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: register_func_function() Description: Hi developers! I have a little feature suggestion for you... I've been developing a large proxy server-ish thingy using standalone PHP, with a basic "kernel" loop that handles deferred procedure calls and timers, and uses stream_select to handle incoming traffic for the network connections and dispatch them to their watcher objects. (It's co-operative multitasking!) The problem is the server is very, very complicated and difficult to debug. Functions nest very deeply. So I added a function called func_log, which calls PHP's very useful debug_backtrace() and uses it to fill a log file with a list of every single function call everywhere and (a cut-down listing of) their parameters. The log file soon becomes gigantic, but it's a phenomenally helpful and wonderful way to debug problems and get an overview of the code. I can review the entire file to find out exactly what goes wrong, and it helped locate a tricky couple of objects that were spuriously crashing PHP by recursively calling each other's Close functions(). (Running out of stack space is difficult to detect otherwise, since PHP logs no error before crashing.) So what's my suggestion? Well the problem with this type of debugging is the need to manually insert the call to the debugging/logging function at the start of every custom function (which I've done). It's an awkward hacky sort of solution, and the function is still called even when debugging/logging isn't wanted, so it always hurts performance. I thought about using declare(ticks) and register_tick_function() instead, but that can't be tuned to just function calls, so it would have to be called far too many times. So wouldn't it be wonderful to have some way to register a function to fire on every function call? E.g.,: bool register_func_function( callback function, [, int flags] ) "flags" would determine whether it should fire for just user functions, just built-in/extension functions, or both. Obviously it would have to disable as the callback is entered, and re-enable once it exits. Perhaps not the best name for it, but anyway, this would be useful for anyone and everyone trying to debug complex scripts. I'm not familiar with PHP's internals, but having a simple boolean to check if register_func_function is enabled shouldn't hurt performance at all really, right? That's my suggestion. Thanks very much for reading. Apologies if this has already been suggested, but I couldn't find it. -- Edit bug report at http://bugs.php.net/?id=47524&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47524&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47524&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47524&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47524&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47524&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47524&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47524&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47524&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47524&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47524&r=support Expected behavior: http://bugs.php.net/fix.php?id=47524&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47524&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47524&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47524&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47524&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47524&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47524&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47524&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47524&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47524&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47524&r=mysqlcfg
#47467 [Fbk->Bgs]: The crc32b polynomial result has a wrong endianess
ID: 47467 Updated by: paj...@php.net Reported By: php at twinmail dot de -Status: Feedback +Status: Bogus Bug Type: hash related Operating System: * PHP Version: 5.2.8 Assigned To: pajoye New Comment: Not a bug > bogus. Previous Comments: [2009-02-27 20:35:50] php at twinmail dot de You are right: I tested this issue against PHP versions on linux which were below 5.2.8 and therefore affected by #45028. Before posting a new bug I also checked against some online calculators of crc32b, but they were also affected by #45028. So I thought "5dd48a35" is the correct result, but it isn't! "358ad45d" is indeed the correct result, so PHP 5.2.8 is correctly calculating crc32b. This means everything is fine, except that I am an idiot! ;-) Sorry for reporting this "bug". [2009-02-27 14:33:35] paj...@php.net Are you sure you are using the same PHP version on all systems (try 5.2.8 on linux)? I can't reproduce the problem on any of my tests hosts. The only difference is with php version prior to 5.2.6, but that's due to the bug #45028 which is now fixed. [2009-02-20 22:21:03] paj...@php.net Windows has no specific endianess but the processor. However I can reproduce on windows (vc6 and vc9). Weird, needs more analyze. [2009-02-20 21:24:26] php at twinmail dot de Description: The polynomial result of the crc32b hash function has since 5.2.8 a wrong byte endianess on Windows. This also affects the CVS snapshot. I cannot reproduce this error on any linux (debian / debian / gentoo / opensuse) box I have, so I think this bug only affects Windows versions. I tested different versions of PHP on my Windows system: PHP 5.2.9RC4-dev (cli) (built: Feb 20 2009 15:57:39): affected PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23): affected PHP 5.2.6 (cli) (built: May 2 2008 18:02:07): NOT affected The bug #45028 is maybe related to this one. Reproduce code: --- print hash('crc32b', 'Lorem Ipsum'); Expected result: 5dd48a35 Actual result: -- 358ad45d -- Edit this bug report at http://bugs.php.net/?id=47467&edit=1
#47467 [Com]: The crc32b polynomial result has a wrong endianess
ID: 47467 Comment by: php at twinmail dot de Reported By: php at twinmail dot de Status: Feedback Bug Type: hash related Operating System: * PHP Version: 5.2.8 Assigned To: pajoye New Comment: You are right: I tested this issue against PHP versions on linux which were below 5.2.8 and therefore affected by #45028. Before posting a new bug I also checked against some online calculators of crc32b, but they were also affected by #45028. So I thought "5dd48a35" is the correct result, but it isn't! "358ad45d" is indeed the correct result, so PHP 5.2.8 is correctly calculating crc32b. This means everything is fine, except that I am an idiot! ;-) Sorry for reporting this "bug". Previous Comments: [2009-02-27 14:33:35] paj...@php.net Are you sure you are using the same PHP version on all systems (try 5.2.8 on linux)? I can't reproduce the problem on any of my tests hosts. The only difference is with php version prior to 5.2.6, but that's due to the bug #45028 which is now fixed. [2009-02-20 22:21:03] paj...@php.net Windows has no specific endianess but the processor. However I can reproduce on windows (vc6 and vc9). Weird, needs more analyze. [2009-02-20 21:24:26] php at twinmail dot de Description: The polynomial result of the crc32b hash function has since 5.2.8 a wrong byte endianess on Windows. This also affects the CVS snapshot. I cannot reproduce this error on any linux (debian / debian / gentoo / opensuse) box I have, so I think this bug only affects Windows versions. I tested different versions of PHP on my Windows system: PHP 5.2.9RC4-dev (cli) (built: Feb 20 2009 15:57:39): affected PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23): affected PHP 5.2.6 (cli) (built: May 2 2008 18:02:07): NOT affected The bug #45028 is maybe related to this one. Reproduce code: --- print hash('crc32b', 'Lorem Ipsum'); Expected result: 5dd48a35 Actual result: -- 358ad45d -- Edit this bug report at http://bugs.php.net/?id=47467&edit=1
#46025 [Com]: zend_bailout can deadlock APC
ID: 46025 Comment by: pierre at archlinux dot de Reported By: askalski at gmail dot com Status: Suspended Bug Type: Reproducible crash Operating System: redhat PHP Version: 5.2.6 New Comment: This problem is still reproducable with version 5.2.9. The cgi version is affected, too (as expected). Previous Comments: [2009-02-15 00:01:20] dan at archlinux dot org Any progress here? This is definitely reproducible and we have seen it on archlinux.org about once every 3 or 4 days- it kind of stinks. Is there any current workaround besides increasing the timeout value and hoping for the best? Running: Apache 2.2.11 PHP 5.2.8 APC 3.0.19 [2008-09-09 00:46:09] scott...@php.net This is essentially what http://wiki.php.net/rfc/zendsignals is for, it was considered for PHP 5.3 but has been deferred for the moment. [2008-09-08 23:56:04] askalski at gmail dot com Reproduced with latest checkouts from both the PHP_5_2 and PHP_5_3 tags. X-Powered-By: PHP/5.2.7-dev X-Powered-By: PHP/5.3.0alpha3-dev [2008-09-08 21:16:43] j...@php.net Can you reproduce this with latest CVS checkout of PHP_5_2 (and preferrably PHP_5_3) ?? [2008-09-08 20:50:12] askalski at gmail dot com To assist with implementing a fix: I wrote up a local fix that uses two executor globals: /* HANDLE_BLOCK_INTERRUPTIONS nesting depth */ zend_uint blocking_interruptions; /* true if a bailout was deferred while interruptions were blocked */ zend_bool deferred_bailout; In my testing, I quickly realized that APC in conjunction with Zend was making nested calls to HANDLE_BLOCK_INTERRUPTIONS(), so to keep from unblocking prematurely, it was necessary to track nesting depth. Example from my debugging: Block 0 /tmp/APC-3.0.19/php_apc.c:559 Block 1 /tmp/php-5.2.6/Zend/zend_alloc.c:1876 Unblock 1 /tmp/php-5.2.6/Zend/zend_alloc.c:1913 Unblock 0 /tmp/APC-3.0.19/php_apc.c:592 My updated macros: #define HANDLE_BLOCK_INTERRUPTIONS()if (!EG(blocking_interruptions)++) { if (zend_block_interruptions) { zend_block_interruptions(); } } #define HANDLE_UNBLOCK_INTERRUPTIONS() if (EG(blocking_interruptions) && !--EG(blocking_interruptions)) { if (zend_unblock_interruptions) { zend_unblock_interruptions(); } if (EG(deferred_bailout)) { zend_bailout(); } } And my mod to _zend_bailout: if (EG(blocking_interruptions)) { EG(deferred_bailout) = 1; return; } EG(deferred_bailout) = 0; 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/46025 -- Edit this bug report at http://bugs.php.net/?id=46025&edit=1
#47520 [Bgs]: PHP segfaulted in preg_replace on processing long string
ID: 47520 User updated by: pahan at hubbitus dot spb dot su Reported By: pahan at hubbitus dot spb dot su Status: Bogus Bug Type: PCRE related Operating System: Linux PHP Version: 5.3.0beta1 New Comment: I'm thrice check the previous reports about this issue. And what? All closed as bogus, but segmentatoin fault still here! Where solution/fix??? Even common workaraund of problem is absent. Why it is bogus but not bug??? And also, please again read note: I use "Once-only subpattern", so, this should prevent recursion as I can understand. Or not? Previous Comments: [2009-02-27 19:37:00] fel...@php.net Please, check the previous reports about this issue: http://bugs.php.net/search.php?search_for=&boolean=1&limit=10&order_by=id&direction=DESC&cmd=display&status=Bogus&bug_type%5B%5D=PCRE+related&php_os=&phpver=&assign=&author_email=&bug_age=0 http://docs.php.net/manual/en/pcre.configuration.php [2009-02-27 11:13:58] pahan at hubbitus dot spb dot su Description: PHP segfaulted when I try replace in long string by next regexp: '((?>(?:[^']|(?<=\\\)')*))' Some comments to reproduce code comments to case 1 and 2 is clearly. In case 3 and 4 I just run script several times, like (assume file named test.php): for (( i=100; i>0; i-- )) ; do echo -n $i: ; ./test.php ; done Sample results of its run you may see here: http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by length of tested string), and for 4 - http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log Coredump may be downloaded here: http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135 Also, please note, I add construction (?> ... ) to speedup and dissallow recursion, so, it is must be different from bugs http://bugs.php.net/bug.php?id=27492 , http://bugs.php.net/bug.php?id=47376 , http://bugs.php.net/bug.php?id=47376 and http://bugs.php.net/bug.php?id=27310 . Reproduce code: --- //1: Always "segmantation fault" //$cont = "'" . str_pad('', 4000, '-');>//2: "Never" (Is I can see in 1000 iterations) "segmantation fault" //$cont = "'" . str_pad('', 4965, '-');>//3: Segfaulted from times to times ~ 1-2 times from 100 executions //$cont = "'" . str_pad('', 4967, '-');>//4: Segfaulted 50/50% $reg = "#'((?>(?:[^']|(?<=\\\)')*))'#"; preg_replace($reg, '', $cont); echo "OK\n"; ?> Expected result: OK Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=47520&edit=1
#47520 [Opn->Bgs]: PHP segfaulted in preg_replace on processing long string
ID: 47520 Updated by: fel...@php.net Reported By: pahan at hubbitus dot spb dot su -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: Linux PHP Version: 5.3.0beta1 New Comment: Please, check the previous reports about this issue: http://bugs.php.net/search.php?search_for=&boolean=1&limit=10&order_by=id&direction=DESC&cmd=display&status=Bogus&bug_type%5B%5D=PCRE+related&php_os=&phpver=&assign=&author_email=&bug_age=0 http://docs.php.net/manual/en/pcre.configuration.php Previous Comments: [2009-02-27 11:13:58] pahan at hubbitus dot spb dot su Description: PHP segfaulted when I try replace in long string by next regexp: '((?>(?:[^']|(?<=\\\)')*))' Some comments to reproduce code comments to case 1 and 2 is clearly. In case 3 and 4 I just run script several times, like (assume file named test.php): for (( i=100; i>0; i-- )) ; do echo -n $i: ; ./test.php ; done Sample results of its run you may see here: http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by length of tested string), and for 4 - http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log Coredump may be downloaded here: http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135 Also, please note, I add construction (?> ... ) to speedup and dissallow recursion, so, it is must be different from bugs http://bugs.php.net/bug.php?id=27492 , http://bugs.php.net/bug.php?id=47376 , http://bugs.php.net/bug.php?id=47376 and http://bugs.php.net/bug.php?id=27310 . Reproduce code: --- //1: Always "segmantation fault" //$cont = "'" . str_pad('', 4000, '-');>//2: "Never" (Is I can see in 1000 iterations) "segmantation fault" //$cont = "'" . str_pad('', 4965, '-');>//3: Segfaulted from times to times ~ 1-2 times from 100 executions //$cont = "'" . str_pad('', 4967, '-');>//4: Segfaulted 50/50% $reg = "#'((?>(?:[^']|(?<=\\\)')*))'#"; preg_replace($reg, '', $cont); echo "OK\n"; ?> Expected result: OK Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=47520&edit=1
#47522 [Opn->Fbk]: __toString() segfault
ID: 47522 Updated by: fel...@php.net Reported By: ms419 at freezone dot co dot uk -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Debian PHP Version: 5.2CVS-2009-02-27 (snap) New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2009-02-27 18:52:36] ms419 at freezone dot co dot uk Description: http://cgi.sfu.ca/~jdbates/tmp/php/200902270/core I am experiencing a reproducible segfault. I experience it with PHP 5.2.4 and 5.2.6. The segfault occurs at this expression: strlen($repository) where $repository is an object with a __toString() method. By substituting this expression, the segfault does not occur: strlen($repository->__toString()) To try to debug this segfault, I compiled a recent 5.2 snapshot with --enable-debug. It produced the above linked core file, which I opened with gdb to print a backtrace: http://cgi.sfu.ca/~jdbates/tmp/php/200902270/screenlog I am not sure what should be my next steps to help fix this segfault? -- Edit this bug report at http://bugs.php.net/?id=47522&edit=1
#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994 Comment by: alex at alexi dot ch Reported By: dbarrett at vistaprint dot com Status: Assigned Bug Type: Program Execution Operating System: win32 only - 2003 Server, 64-bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: Hi all, I can fully confirm the above behaviour on the Windows platform. We are using Apache FOP to create PDF-Files out of PHP, so we are invoking exec() to start the command line FOP processor. With several versions of PHP 5.2.x (5.2.4, 5.2.6, 5.2.8), this problem occurs soon as more than one user is invoking the exec(). Luckily we could not reproduce this behaviour using PHP 5.1.x, so downgrading to a 5.1.x version might also be an option for you. Regards alex Previous Comments: [2009-01-16 17:17:44] schreiber at cs-itc dot de Same problems on w2k3 server x64 SP2 with apache 2.2.8 + 2.2.11 and php 5.2.0 up to 5.2.8 -> using exec() the shellproc cmd.exe hangs and httpd is blocked for further ops, can just be cured by restart of apache services. Workaround with COM object helps, but thats no lucky solution... [2009-01-13 18:44:15] irdev at rogers dot com I have been experiencing this issue as well. The server is Windows 2003 with all patches up to date running IIS. PHP version is 5.2.5. I am running a commandline process using exec(). I have also tried passthru and shell_exec with the same results. Problem is intermittent and can not be replicated on demand. The processes themselves can not be killed until the IIS worker process is killed first although they do complete all the work they are supposed to. The commands do not die on script timeout. [2008-12-02 14:34:25] brem at martinbreton dot com If that's any help, I'm using a COM object as a workaround for this bug, and while it makes this bug appear less frequently, it still happens, randomly, from time to time. Here's what i did as a workaround using the exec() function call: $WshShell = new COM("WScript.Shell"); $OutputFile = "C:\\Temp\\output.txt"; $Command = "cmd /C MyApp.exe > $OutputFile"; $WshShell->Run( $Command, 0, true ); file_get_contents( $OutputFile ) ); unlink( $OutputFile ); [2008-11-18 08:46:34] bernd dot ebert at gmx dot net Same Problem here with an commandline-script calling other php-commandline-scripts. It seems to happen more frequently if you have a lot of exec-calls. [2008-08-19 02:58:37] jkflash at gmail dot com Sorry, I take that last comment back, it still hangs annoyingly intermittently with shell_exec as well. It's a killer :( The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/44994 -- Edit this bug report at http://bugs.php.net/?id=44994&edit=1
#47522 [NEW]: __toString() segfault
From: ms419 at freezone dot co dot uk Operating system: Debian PHP version: 5.2CVS-2009-02-27 (snap) PHP Bug Type: Reproducible crash Bug description: __toString() segfault Description: http://cgi.sfu.ca/~jdbates/tmp/php/200902270/core I am experiencing a reproducible segfault. I experience it with PHP 5.2.4 and 5.2.6. The segfault occurs at this expression: strlen($repository) where $repository is an object with a __toString() method. By substituting this expression, the segfault does not occur: strlen($repository->__toString()) To try to debug this segfault, I compiled a recent 5.2 snapshot with --enable-debug. It produced the above linked core file, which I opened with gdb to print a backtrace: http://cgi.sfu.ca/~jdbates/tmp/php/200902270/screenlog I am not sure what should be my next steps to help fix this segfault? -- Edit bug report at http://bugs.php.net/?id=47522&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47522&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47522&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47522&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47522&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47522&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47522&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47522&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47522&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47522&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47522&r=support Expected behavior: http://bugs.php.net/fix.php?id=47522&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47522&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47522&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47522&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47522&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47522&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47522&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47522&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47522&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47522&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47522&r=mysqlcfg
#47521 [NEW]: In jquery ajax. When I send variables thru 'get' it works but not on 'post'
From: mandar dot dhotre at yahoo dot co dot in Operating system: Windows PHP version: 5.2CVS-2009-02-27 (snap) PHP Bug Type: Unknown/Other Function Bug description: In jquery ajax. When I send variables thru 'get' it works but not on 'post' Description: I am using jquery ajax. When I send the variables thru get method it works but wen I send them thru POST and try to catch them using REQUEST or POST it doesnt work. I need to use POST only as m using it for username-password. -- Edit bug report at http://bugs.php.net/?id=47521&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47521&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47521&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47521&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47521&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47521&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47521&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47521&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47521&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47521&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47521&r=support Expected behavior: http://bugs.php.net/fix.php?id=47521&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47521&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47521&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47521&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47521&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47521&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47521&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47521&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47521&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47521&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47521&r=mysqlcfg
#47519 [Opn->Bgs]: array key access reports notice
ID: 47519 Updated by: ka...@php.net Reported By: markus dot staab at redaxo dot de -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Vista Business PHP Version: 5.2.9 New Comment: Its because your overridding the $params array by assigning a new value, and since the [] operator also can be used for string offsets then that notice is produced, not a bug. Previous Comments: [2009-02-27 10:37:13] markus dot staab at redaxo dot de Description: access a array key results in a undefined string offset notice. When swapping lines $params = $params['params']; $divider = $params['divider']; to $divider = $params['divider']; $params = $params['params']; no notice is reported.. PS: Appears in PHP4 and also PHP5.2.8 (5.2.9 not yet tested) Reproduce code: --- $params = array ( 'id' => 1, 'name' => 'Home', 'clang' => 0, 'params' => '', 'divider' => '&', 'extension_point' => 'URL_REWRITE', 'subject' => '', ); $id = $params['id']; $name= $params['name']; $clang = $params['clang']; $params = $params['params']; $divider = $params['divider']; // line reports notice Expected result: no notices at all Actual result: -- Notice: Uninitialized string offset: 0 -- Edit this bug report at http://bugs.php.net/?id=47519&edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285 Comment by: maarten at vivesta dot com 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: Same here. I've added a date_default_timezone_set() before using strtotime() and it removed the error but not the leak. Previous Comments: [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 [2009-02-23 08:59:23] danger at FreeBSD dot org Any news on this? I checked the box and it seems like you logged only once for a few seconds almost a week ago 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=47285&edit=1
#47467 [Asn->Fbk]: The crc32b polynomial result has a wrong endianess
ID: 47467 Updated by: paj...@php.net Reported By: php at twinmail dot de -Status: Assigned +Status: Feedback Bug Type: hash related -Operating System: Windows XP SP2 +Operating System: * PHP Version: 5.2.8 Assigned To: pajoye New Comment: Are you sure you are using the same PHP version on all systems (try 5.2.8 on linux)? I can't reproduce the problem on any of my tests hosts. The only difference is with php version prior to 5.2.6, but that's due to the bug #45028 which is now fixed. Previous Comments: [2009-02-20 22:21:03] paj...@php.net Windows has no specific endianess but the processor. However I can reproduce on windows (vc6 and vc9). Weird, needs more analyze. [2009-02-20 21:24:26] php at twinmail dot de Description: The polynomial result of the crc32b hash function has since 5.2.8 a wrong byte endianess on Windows. This also affects the CVS snapshot. I cannot reproduce this error on any linux (debian / debian / gentoo / opensuse) box I have, so I think this bug only affects Windows versions. I tested different versions of PHP on my Windows system: PHP 5.2.9RC4-dev (cli) (built: Feb 20 2009 15:57:39): affected PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23): affected PHP 5.2.6 (cli) (built: May 2 2008 18:02:07): NOT affected The bug #45028 is maybe related to this one. Reproduce code: --- print hash('crc32b', 'Lorem Ipsum'); Expected result: 5dd48a35 Actual result: -- 358ad45d -- Edit this bug report at http://bugs.php.net/?id=47467&edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285 Comment by: danger at FreeBSD dot org 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: 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 Previous Comments: [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 [2009-02-23 08:59:23] danger at FreeBSD dot org Any news on this? I checked the box and it seems like you logged only once for a few seconds almost a week ago [2009-02-18 01:10:43] alex dot franks at soletechnology dot com I'm also experiencing this bug on FreeBSD 7. FreeBSD version: FreeBSD 7.0-STABLE #1: Mon Jul 14 16:07:29 PDT 2008 i386 PHP version: PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Feb 7 2009 11:09:59) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 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=47285&edit=1
#47285 [Com]: strtotime() still leaks memory
ID: 47285 Comment by: danger at FreeBSD dot org 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: 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. Previous Comments: [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 [2009-02-23 08:59:23] danger at FreeBSD dot org Any news on this? I checked the box and it seems like you logged only once for a few seconds almost a week ago [2009-02-18 01:10:43] alex dot franks at soletechnology dot com I'm also experiencing this bug on FreeBSD 7. FreeBSD version: FreeBSD 7.0-STABLE #1: Mon Jul 14 16:07:29 PDT 2008 i386 PHP version: PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Feb 7 2009 11:09:59) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [2009-02-17 15:45:07] danger at FreeBSD dot org I did so yesterday as well... 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=47285&edit=1
#47285 [Asn]: strtotime() still leaks memory
ID: 47285 Updated by: der...@php.net 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: 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? Previous Comments: [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 [2009-02-23 08:59:23] danger at FreeBSD dot org Any news on this? I checked the box and it seems like you logged only once for a few seconds almost a week ago [2009-02-18 01:10:43] alex dot franks at soletechnology dot com I'm also experiencing this bug on FreeBSD 7. FreeBSD version: FreeBSD 7.0-STABLE #1: Mon Jul 14 16:07:29 PDT 2008 i386 PHP version: PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Feb 7 2009 11:09:59) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [2009-02-17 15:45:07] danger at FreeBSD dot org I did so yesterday as well... [2009-02-17 14:47:21] maarten at vivesta dot com Ok, I've sent you login details to a testmachine by e-mail. 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=47285&edit=1
#47520 [NEW]: PHP segfaulted in preg_replace on processing long string
From: pahan at hubbitus dot spb dot su Operating system: Linux PHP version: 5.3.0beta1 PHP Bug Type: PCRE related Bug description: PHP segfaulted in preg_replace on processing long string Description: PHP segfaulted when I try replace in long string by next regexp: '((?>(?:[^']|(?<=\\\)')*))' Some comments to reproduce code comments to case 1 and 2 is clearly. In case 3 and 4 I just run script several times, like (assume file named test.php): for (( i=100; i>0; i-- )) ; do echo -n $i: ; ./test.php ; done Sample results of its run you may see here: http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by length of tested string), and for 4 - http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log Coredump may be downloaded here: http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135 Also, please note, I add construction (?> ... ) to speedup and dissallow recursion, so, it is must be different from bugs http://bugs.php.net/bug.php?id=27492 , http://bugs.php.net/bug.php?id=47376 , http://bugs.php.net/bug.php?id=47376 and http://bugs.php.net/bug.php?id=27310 . Reproduce code: --- //1: Always "segmantation fault" //$cont = "'" . str_pad('', 4000, '-');>//2: "Never" (Is I can see in 1000 iterations) "segmantation fault" //$cont = "'" . str_pad('', 4965, '-');>//3: Segfaulted from times to times ~ 1-2 times from 100 executions //$cont = "'" . str_pad('', 4967, '-');>//4: Segfaulted 50/50% $reg = "#'((?>(?:[^']|(?<=\\\)')*))'#"; preg_replace($reg, '', $cont); echo "OK\n"; ?> Expected result: OK Actual result: -- Segmentation fault -- Edit bug report at http://bugs.php.net/?id=47520&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47520&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47520&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47520&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47520&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47520&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47520&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47520&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47520&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47520&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47520&r=support Expected behavior: http://bugs.php.net/fix.php?id=47520&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47520&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47520&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47520&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47520&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47520&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47520&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47520&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47520&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47520&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47520&r=mysqlcfg
#47285 [Com]: strtotime() still leaks memory
ID: 47285 Comment by: danger at FreeBSD dot org 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: 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 Previous Comments: [2009-02-23 08:59:23] danger at FreeBSD dot org Any news on this? I checked the box and it seems like you logged only once for a few seconds almost a week ago [2009-02-18 01:10:43] alex dot franks at soletechnology dot com I'm also experiencing this bug on FreeBSD 7. FreeBSD version: FreeBSD 7.0-STABLE #1: Mon Jul 14 16:07:29 PDT 2008 i386 PHP version: PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Feb 7 2009 11:09:59) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies [2009-02-17 15:45:07] danger at FreeBSD dot org I did so yesterday as well... [2009-02-17 14:47:21] maarten at vivesta dot com Ok, I've sent you login details to a testmachine by e-mail. [2009-02-15 12:54:34] der...@php.net Please send me account details (by email), as I still can't reproduce this. 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=47285&edit=1
#47519 [NEW]: array key access reports notice
From: markus dot staab at redaxo dot de Operating system: Vista Business PHP version: 5.2.9 PHP Bug Type: Arrays related Bug description: array key access reports notice Description: access a array key results in a undefined string offset notice. When swapping lines $params = $params['params']; $divider = $params['divider']; to $divider = $params['divider']; $params = $params['params']; no notice is reported.. PS: Appears in PHP4 and also PHP5.2.8 (5.2.9 not yet tested) Reproduce code: --- $params = array ( 'id' => 1, 'name' => 'Home', 'clang' => 0, 'params' => '', 'divider' => '&', 'extension_point' => 'URL_REWRITE', 'subject' => '', ); $id = $params['id']; $name= $params['name']; $clang = $params['clang']; $params = $params['params']; $divider = $params['divider']; // line reports notice Expected result: no notices at all Actual result: -- Notice: Uninitialized string offset: 0 -- Edit bug report at http://bugs.php.net/?id=47519&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47519&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47519&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47519&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47519&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47519&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47519&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47519&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47519&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47519&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47519&r=support Expected behavior: http://bugs.php.net/fix.php?id=47519&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47519&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47519&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47519&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47519&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47519&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47519&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47519&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47519&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47519&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47519&r=mysqlcfg
#44578 [Com]: Strange Behavior of PHP using COM Object
ID: 44578 Comment by: hargael at gmail dot com Reported By: hargael at gmail dot com Status: Open Bug Type: COM related Operating System: Windows XP PHP Version: 5.2.5 New Comment: Is there a way I can help in order to make this bug evolve ? I can provide any requested logs and can perform tests to help to solve this problem because I really need this feature. I'm not really keen on using an ASP page to make this single function. Regards. Previous Comments: [2008-07-08 12:46:07] spijoel at gmail dot com I have the same problem (Fatal error: Can't use method return value in write context in ...), with PHP 5.2.6 , Apache 2.2.9 , and Windows 2003 Server. I'm not able to do this: $obj->Attribute('data1') = "test"; This is also not working like this: $obj->Attribute['data1'] = "test"; and it's working in VBS so I know it should work here also. [2008-03-31 12:39:49] hargael at gmail dot com Description: I've a problem with COM objects. It's very similar to the bug #33734. In fact, I think that it is the same problem but the bug is supposed to be fixed since 5.1.0. I use the 5.2.5 and have the same problem. Excuse me for my clumsy english, I hope that my report will be readable. Reproduce code: --- Here is the code : Applications->Add($path); $obj_unite = $obj_appli->Units->Add("foo"); $obj_instance = $obj_unite->objects->add($nom_instance); $sous_objet = $obj_instance->collection("Objects"); $propriete = $sous_objet->Item("alm"); echo "Label Value : " . $propriete->Value("Label",0); //Returns the good Value // Test 1 $propriete->Value("Label",0) = "New Label"; // Fatal Error //Test 2 $propriete->Value["Label",0] = "New Label"; // Invalid number of parameters. Expected result: I've tried many ways of writing the $propriete->Value["Label",0]. With (), [], mix of both. I cannot write on the value. I though it was a read-only value but when I tried with VBa, it worked perfectly. Here is the code. Dim SsObjs as PrsCollObjects Set SsObjs = MyInst.Collection("Objects") Set MyObject = SsObjs.Item("Fault") MyObject.Value("Label", 0) = "Défaut pompe 1" Actual result: -- Result of TEST 1 with () : Fatal error: Can't use method return value in write context in C:\wamp\www\Test COM\index.php on line 71 Result of TEST 2 with [] : Fatal error: Uncaught exception 'com_exception' with message 'Error [0x8002000e] Nombre de param?tres non valide. ' in C:\wamp\www\Test COM\index.php:69 Stack trace: #0 C:\wamp\www\Test COM\index.php(69): unknown() #1 {main} thrown in C:\wamp\www\Test COM\index.php on line 69 Depending on the way I write with [], I also have an "Unexpected ','" error. -- Edit this bug report at http://bugs.php.net/?id=44578&edit=1
#47517 [Opn->Fbk]: php-cgi.exe missing UAC manifest
ID: 47517 Updated by: paj...@php.net Reported By: louis at steelbytes dot com -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: Win32 PHP Version: 5.2.9 New Comment: Why do you need one? php can be used in any situations and inherits (or is set by) the UAC from the caller (in case of fcgi or another SAPI for example). Previous Comments: [2009-02-27 06:23:35] louis at steelbytes dot com reason: so that UAC won't virtualize file read/writes. [2009-02-27 03:51:48] louis at steelbytes dot com Description: php-cgi.exe (and I guess other php .exe's) should have a UAC manifest stating "asInvoker" Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=47517&edit=1
#26545 [Com]: Cannot extract() variables into class scope
ID: 26545 Comment by: james dot relyea at zifiniti dot com Reported By: kmsluder at optonline dot net Status: Open Bug Type: Feature/Change Request Operating System: Linux 2.4.2 PHP Version: 4.3.4 New Comment: Adding in ability to specifiy scope would be highly useful for Objects. Previous Comments: [2004-01-10 10:41:10] and...@php.net What's the deal to use extract() to add dynamically member variables to the object? [2003-12-06 16:53:27] der...@php.net It's still not a bug as extract() was never meant to do this. Making it a feature-request. [2003-12-06 16:20:21] kmsluder at optonline dot net Note to anyone that says that the extra two lines aren't a big deal: it's a lot more than two if you need to emulate some of the more sophisticated (and rather useful) features of extract(). [2003-12-06 16:11:31] kmsluder at optonline dot net Description: extract() cannot be used inside an object member function to set object var's. Using extract normally brings the variables into the scope of the function (as expected), but there is no way to bring array key/value pairs to object scope without a foreach statement. It would be nice to specify what scope the variables should be created in, or even create a different function specifically to set the member variables of an object. Reproduce code: --- class MyClass { var $m1; // Imagine a class with fifty variables, var $m2; // Not all of which must be set. var $m3; // This is why you would want to use extract(). function Init($info) { extract($info, EXTR_OVERWRITE); // Doesn't work; extracted to function scope extract($info, EXTR_PREFIX_ALL, "$this->"); // Stupid idea; not a valid variable name foreach($info as $key => $value) { $this->$key = $value; // Works, but ugly } } } -- Edit this bug report at http://bugs.php.net/?id=26545&edit=1