Bug #54269 [Opn]: Segmentation Filed
Edit report at http://bugs.php.net/bug.php?id=54269&edit=1 ID: 54269 User updated by:eav at mobil-soft dot ru Reported by:eav at mobil-soft dot ru Summary:Segmentation Filed Status: Open Type: Bug Package:InterBase related -Operating System: +Operating System: All PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Add OS Previous Comments: [2011-03-16 06:42:59] eav at mobil-soft dot ru Description: >From FB 2.0 release notes Size limit for exception messages increased V. Horsun Maximum size of exception messages raised from 78 to 1021 bytes. -- Edit this bug report at http://bugs.php.net/bug.php?id=54269&edit=1
[PHP-BUG] Bug #54269 [NEW]: Segmentation Filed
From: Operating system: PHP version: 5.3.5 Package: InterBase related Bug Type: Bug Bug description:Segmentation Filed Description: >From FB 2.0 release notes Size limit for exception messages increased V. Horsun Maximum size of exception messages raised from 78 to 1021 bytes. -- Edit bug report at http://bugs.php.net/bug.php?id=54269&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54269&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54269&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54269&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54269&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54269&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54269&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54269&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54269&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54269&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54269&r=support Expected behavior: http://bugs.php.net/fix.php?id=54269&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54269&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54269&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54269&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54269&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54269&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54269&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54269&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54269&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54269&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54269&r=mysqlcfg
Bug #54267 [Opn->Bgs]: Receiving notice "Uninitialized string offset" as fatal error under Zend
Edit report at http://bugs.php.net/bug.php?id=54267&edit=1 ID: 54267 Updated by: ras...@php.net Reported by:jbarbuto at gmail dot com Summary:Receiving notice "Uninitialized string offset" as fatal error under Zend -Status: Open +Status: Bogus Type: Bug Package:Strings related Operating System: Ubuntu 10.04 PHP Version:5.2SVN-2011-03-16 (SVN) Block user comment: N Private report: N New Comment: We can't support non-PHP extensions here. If you can reproduce the bug in a clean PHP script against PHP 5.3.x, feel free to re-open the bug. Previous Comments: [2011-03-16 05:23:58] jbarbuto at gmail dot com Description: Hi, Despite having "error_reporting = E_ALL & ~E_NOTICE" in php.ini, we found the following notice was being reported as a fatal error with a ZendGuard-encoded script we were running under php 5.2.14: Fatal error in line 111 of file/foo.php - Uninitialized string offset: 35918 We found the error didn't appear with php < 5.2.10. Further investigation found the change introduced in SVN revision 278340 was the cause; reverting it in the 5.2 branch fixed the problem for us. Perhaps there's something in this patch that needs tweaking? Thanks, John -- Edit this bug report at http://bugs.php.net/bug.php?id=54267&edit=1
[PHP-BUG] Bug #54268 [NEW]: Double free when destroy_zend_class fails
From: stas
Operating system: MacOS X 10.6.6
PHP version: 5.3SVN-2011-03-16 (snap)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Double free when destroy_zend_class fails
Description:
Reported by Christian Holler on mailing list, the example code produces
double
free on module shutdown, because of the fact that it fail to clean up the
class
table and remove the class from it, but the memory under the class is freed
by
memory manager shutdown.
Test script:
---
test = new DestructableObject;
}
}
class Test
{
public static $mystatic;
}
$x = new Test();
Test::$mystatic = new DestructorCreator();
Actual result:
--
==83356== Invalid read of size 4
==83356==at 0x505250: destroy_zend_class (zend_opcode.c:182)
==83356==by 0x51D7B6: zend_hash_destroy (zend_hash.c:529)
==83356==by 0x50F8DA: zend_shutdown (zend.c:762)
==83356==by 0x49CD73: php_module_shutdown (main.c:2146)
==83356==by 0x5D3604: main (php_cli.c:1388)
==83356== Address 0x38f58a8 is 65,640 bytes inside a block of size 262,144
free'd
==83356==at 0xC87F18: free (vg_replace_malloc.c:366)
==83356==by 0x4EABAD: zend_mm_mem_malloc_free (zend_alloc.c:297)
==83356==by 0x4EB96C: zend_mm_shutdown (zend_alloc.c:1648)
==83356==by 0x4ED494: shutdown_memory_manager (zend_alloc.c:2562)
==83356==by 0x49C029: php_request_shutdown (main.c:1654)
==83356==by 0x5D359E: main (php_cli.c:1374)
==83356==
--
Edit bug report at http://bugs.php.net/bug.php?id=54268&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54268&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54268&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54268&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54268&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54268&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54268&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54268&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54268&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54268&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54268&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54268&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54268&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54268&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54268&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54268&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54268&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54268&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54268&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54268&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54268&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54268&r=mysqlcfg
[PHP-BUG] Bug #54267 [NEW]: Receiving notice "Uninitialized string offset" as fatal error under Zend
From: Operating system: Ubuntu 10.04 PHP version: 5.2SVN-2011-03-16 (SVN) Package: Strings related Bug Type: Bug Bug description:Receiving notice "Uninitialized string offset" as fatal error under Zend Description: Hi, Despite having "error_reporting = E_ALL & ~E_NOTICE" in php.ini, we found the following notice was being reported as a fatal error with a ZendGuard-encoded script we were running under php 5.2.14: Fatal error in line 111 of file/foo.php - Uninitialized string offset: 35918 We found the error didn't appear with php < 5.2.10. Further investigation found the change introduced in SVN revision 278340 was the cause; reverting it in the 5.2 branch fixed the problem for us. Perhaps there's something in this patch that needs tweaking? Thanks, John -- Edit bug report at http://bugs.php.net/bug.php?id=54267&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54267&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54267&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54267&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54267&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54267&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54267&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54267&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54267&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54267&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54267&r=support Expected behavior: http://bugs.php.net/fix.php?id=54267&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54267&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54267&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54267&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54267&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54267&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54267&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54267&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54267&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54267&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54267&r=mysqlcfg
[PHP-BUG] Bug #54266 [NEW]: crash on shutdown when destroying circular references in object
From: stas
Operating system: MacOS X 10.6.6
PHP version: 5.3SVN-2011-03-16 (snap)
Package: Reproducible crash
Bug Type: Bug
Bug description:crash on shutdown when destroying circular references in object
Description:
Reported by Christian Holler on mailing list, the example code produces
crash on
engine shutdown.
Test script:
---
dad = null; /* no segfault if this is commented out
*/
}
}
class Dad extends Person {
public $son;
public function __construct() {
$this->son = new Person;
$this->son->dad = $this; /* no segfault if this is
commented out */
}
public function __destruct() {
$dad = new dad;
parent::__destruct(); /* segfault here */
}
}
$o = new Dad;
unset($o);
echo "ok\n";
Actual result:
--
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004
0x005310bd in gc_remove_from_buffer [inlined] () at /Users/smalyshev/php-
src/branches/PHP_5_3/Zend/zend_gc.h:265
265 GC_REMOVE_FROM_BUFFER(root_buffer);
(gdb) bt
#0 0x005310bd in gc_remove_from_buffer [inlined] () at
/Users/smalyshev/php-
src/branches/PHP_5_3/Zend/zend_gc.h:265
#1 0x005310bd in gc_remove_zval_from_buffer (zv=0x2424dd8) at
/Users/smalyshev/php-5.3/Zend/zend_gc.c:265
#2 0x004ffe56 in _zval_ptr_dtor (zval_ptr=0x2425154) at
/Users/smalyshev/php-
5.3/Zend/zend_execute_API.c:442
#3 0x0051d7b7 in zend_hash_destroy (ht=0x24250f0) at
/Users/smalyshev/php-
5.3/Zend/zend_hash.c:529
#4 0x00533700 in zend_object_std_dtor (object=0x24250c0) at
/Users/smalyshev/php-5.3/Zend/zend_objects.c:45
#5 0x00533af0 in zend_objects_free_object_storage (object=0x24250c0) at
/Users/smalyshev/php-5.3/Zend/zend_objects.c:126
#6 0x00538002 in zend_objects_store_free_object_storage (objects=0xa97d90)
at
/Users/smalyshev/php-5.3/Zend/zend_objects_API.c:92
#7 0x004ff84b in shutdown_executor () at /Users/smalyshev/php-
5.3/Zend/zend_execute_API.c:302
#8 0x0050fdf9 in zend_deactivate () at
/Users/smalyshev/php-5.3/Zend/zend.c:890
#9 0x0049bea7 in php_request_shutdown (dummy=0x0) at
/Users/smalyshev/php-
5.3/main/main.c:1635
#10 0x005d359f in main (argc=2, argv=0xb864) at /Users/smalyshev/php-
5.3/sapi/cli/php_cli.c:1374
--
Edit bug report at http://bugs.php.net/bug.php?id=54266&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54266&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54266&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54266&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54266&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54266&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54266&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54266&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54266&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54266&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54266&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54266&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54266&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54266&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54266&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54266&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54266&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54266&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54266&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54266&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54266&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54266&r=mysqlcfg
Bug #53696 [Com]: erroneous automatic entry into httpd.conf
Edit report at http://bugs.php.net/bug.php?id=53696&edit=1 ID: 53696 Comment by: masikwha at yahoo dot com Reported by:helge dot rowold at datendrexler dot de Summary:erroneous automatic entry into httpd.conf Status: Closed Type: Bug Package:Apache2 related Operating System: Windows 7 PHP Version:5.3.5 Assigned To:jmertic Block user comment: N Private report: N New Comment: the problems discussed here for windows 7 seems to be far different than what I am experincing on Vista. After successful installatioin of Apache 2.2.17 on Vista, php-5.3.5-Win32-VC9-x86 (Thread safe) installer seems to add following lines on httpd.conf file, #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL ScriptAlias /php/ "" Action application/x-httpd-php "php-cgi.exe" #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL (Note there is no PHPIniDir ) On restarting the apache it gives error saying, ScriptAlias takes two names, fake name and real name... I tried commenting #CriptAlias /php/ "" , Apache runs ok but it doesn't php is not working. For proper installation of PHP 5.3.5 is that all the changes necessary ?? (which however is not working )? Previous Comments: [2011-01-19 21:57:49] jmer...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2011-01-10 11:18:51] alvaro at demogracia dot com Same symptoms here under Windows XP. Apache cannot find php5apache2_2.dll even if at default location: The Apache service named reported the following error: >>> httpd.exe: Syntax error on line 516 of C:/Archivos de programa/Apache Software Foundation/Apache2.2/conf/httpd.conf: Cannot load C:/Archivos de programa/Apache Software Foundation/Apache2.2/php5apache2_2.dll into server: No se puede encontrar el m\xf3dulo . Copying settings from PHP/5.3.4 fixes the issue: #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir "C:/Archivos de programa/PHP/" LoadModule php5_module "C:/Archivos de programa/PHP/php5apache2_2.dll" #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL [2011-01-08 14:57:09] paj...@php.net hi John, Something went wrong in the last installer update. [2011-01-08 14:53:42] helge dot rowold at datendrexler dot de Description: After having installed httpd-2.2.17-win32-x86-openssl-0.9.8o.msi successfully, but NOT at the default path but at a separate HDD partition with a non-default root directory, I was able to install the php-5.3.5-Win32-VC6-x86.msi at the same partition in a non-default directory, too. The installer echoed that everything would have been done well. But the Apache Service did not start, then! At the end I was able to fix the issue: In httpd.conf, the PHP installer had tried to add the default linkage from HTTPD to PHP by adding the lines #BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL PHPIniDir "" LoadModule php5_module "php5apache2_2.dll" #END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL - i. e., PHP was NOT able to set the correct (non-default) path to its own directory (which would have been, by the way, "D:/Programme/PHP535/"). Test script: --- Please see above - addition of the correct path in httpd.conf did fix the error. -- Edit this bug report at http://bugs.php.net/bug.php?id=53696&edit=1
[PHP-BUG] Bug #54265 [NEW]: crash when variable gets reassigned in error handler
From: stas
Operating system: MacOS X 10.6.6
PHP version: 5.3SVN-2011-03-16 (snap)
Package: Reproducible crash
Bug Type: Bug
Bug description:crash when variable gets reassigned in error handler
Description:
Reported by Christian Holler on mailing list, the code below produces
invalid
memory access due to the fact that the line:
if (!Z_OBJ_HT_P(object)->write_property) {
tries to access handler table of the object variable while it's not an
object and
is not initialized.
Test script:
---
errormsg = "xyz");
Actual result:
--
==81019== Invalid read of size 4
==81019==at 0x563FE7: zend_assign_to_object (in /Users/smalyshev/mphp)
==81019==by 0x563C0A: ZEND_ASSIGN_OBJ_SPEC_VAR_CONST_HANDLER (in
/Users/smalyshev/mphp)
==81019==by 0x53AACF: execute (in /Users/smalyshev/mphp)
==81019==by 0x510740: zend_execute_scripts (in /Users/smalyshev/mphp)
==81019==by 0x49D190: php_execute_script (in /Users/smalyshev/mphp)
==81019==by 0x5D2C35: main (in /Users/smalyshev/mphp)
==81019== Address 0x10 is not stack'd, malloc'd or (recently) free'd
==81019==
--
Edit bug report at http://bugs.php.net/bug.php?id=54265&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54265&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54265&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54265&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54265&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54265&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54265&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54265&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54265&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54265&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54265&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54265&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54265&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54265&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54265&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54265&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54265&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54265&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54265&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54265&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54265&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54265&r=mysqlcfg
[PHP-BUG] Bug #54264 [NEW]: race condition in error_handler+zend_timeout
From: stas
Operating system: MacOS X 10.6.6
PHP version: 5.3SVN-2011-03-16 (SVN)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:race condition in error_handler+zend_timeout
Description:
Reported by Christian Holler on mailing list, the example code produces
double
free with following backtrace:
#0 0x955d3f82 in malloc_error_break ()
#1 0x954e3b63 in free ()
#2 0x0049a4b4 in php_error_cb (type=1, error_filename=0x2422a0c
"/Users/smalyshev/Desktop/crash-reports1/crashPhpErrorCbDoubleFree/min.php",
error_lineno=7, format=0x628d28 "Maximum execution time of %d second%s
exceeded", args=0xbfffe638 "\001") at
/Users/smalyshev/php-5.3/main/main.c:910
#3 0x002de81b in soap_error_handler (error_num=1, error_filename=0x2422a0c
"/Users/smalyshev/Desktop/crash-reports1/crashPhpErrorCbDoubleFree/min.php",
error_lineno=7, format=0x628d28 "Maximum execution time of %d second%s
exceeded", args=0xbfffe638 "\001") at /Users/smalyshev/php-
5.3/ext/soap/soap.c:2286
#4 0x00510205 in zend_error (type=1, format=0x628d28 "Maximum execution
time of
%d second%s exceeded") at /Users/smalyshev/php-5.3/Zend/zend.c:1020
#5 0x00503361 in zend_timeout (dummy=27) at /Users/smalyshev/php-
5.3/Zend/zend_execute_API.c:1332
#6
#7 0x954e12e1 in szone_malloc_should_clear ()
#8 0x954e11a8 in malloc_zone_malloc ()
#9 0x954df278 in malloc ()
#10 0x954e753c in strdup ()
#11 0x0049a507 in php_error_cb (type=8, error_filename=0x2422a0c
"/Users/smalyshev/Desktop/crash-reports1/crashPhpErrorCbDoubleFree/min.php",
error_lineno=7, format=0x62b238 "Undefined variable: %s", args=0xb158
"?
RB\002ÎQ") at /Users/smalyshev/php-5.3/main/main.c:919
The reason seems to be that when this code in php_error_cb is run:
if (display) {
if (PG(last_error_message)) {
free(PG(last_error_message));
}
if (PG(last_error_file)) {
free(PG(last_error_file));
}
if (!error_filename) {
error_filename = "Unknown";
}
PG(last_error_type) = type;
PG(last_error_message) = strdup(buffer);
PG(last_error_file) = strdup(error_filename);
PG(last_error_lineno) = error_lineno;
}
The timeout happens between freeing and reassigning last_error_message or
last_error_file, and thus it is freed second time when timeout is going to
process the error.
Test script:
---
2) {
break;
}
}
}
plop();
--
Edit bug report at http://bugs.php.net/bug.php?id=54264&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54264&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54264&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54264&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54264&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54264&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54264&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54264&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54264&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54264&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54264&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54264&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54264&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54264&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54264&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54264&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54264&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54264&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54264&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54264&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54264&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54264&r=mysqlcfg
Bug #54262 [Com]: Crash when assigning value to a dimension in a non-array
Edit report at http://bugs.php.net/bug.php?id=54262&edit=1
ID: 54262
Comment by: s...@php.net
Reported by:s...@php.net
Summary:Crash when assigning value to a dimension in a
non-array
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: MacOS X 10.6.6
PHP Version:5.3SVN-2011-03-16 (SVN)
Block user comment: N
Private report: N
New Comment:
Looks like SEND_REF in preg_match() line makes error_zval_ptr not point
to
error_zval, which may be the source of the problem...
Previous Comments:
[2011-03-16 01:48:50] s...@php.net
Description:
Reported by Christian Holler on mailing list, test named
'crashMemCorruptionZvalDtorFunc', produces the following on valgrind:
==71892== Invalid read of size 4
==71892==at 0x51D7EA: zend_hash_destroy (in /Users/smalyshev/mphp)
==71892==by 0x50DFCC: _zval_dtor_func (in /Users/smalyshev/mphp)
==71892==by 0x4FFB62: _zval_dtor (in /Users/smalyshev/mphp)
==71892==by 0x4FFEB6: _zval_ptr_dtor (in /Users/smalyshev/mphp)
==71892==by 0x5B0982: ZEND_ASSIGN_DIM_SPEC_CV_CONST_HANDLER (in
/Users/smalyshev/mphp)
==71892==by 0x53AB23: execute (in /Users/smalyshev/mphp)
==71892==by 0x510794: zend_execute_scripts (in
/Users/smalyshev/mphp)
==71892==by 0x49D228: php_execute_script (in /Users/smalyshev/mphp)
==71892==by 0x5D2CDD: main (in /Users/smalyshev/mphp)
==71892== Address 0x5c is not stack'd, malloc'd or (recently) free'd
The bug seems to be because in ZEND_ASSIGN_DIM_SPEC_CV_CONST_HANDLER,
error_zval_ptr is used to assign to it as if it were array, which seems
to lead
to unexpected consequences.
Test script:
---
$a = '0';
var_dump(isset($a['b']));
$simpleString = preg_match('//', '', $a->a);
$simpleString["wrong"] = "f";
--
Edit this bug report at http://bugs.php.net/bug.php?id=54262&edit=1
[PHP-BUG] Bug #54262 [NEW]: Crash when assigning value to a dimension in a non-array
From:
Operating system: MacOS X 10.6.6
PHP version: 5.3SVN-2011-03-16 (SVN)
Package: Reproducible crash
Bug Type: Bug
Bug description:Crash when assigning value to a dimension in a non-array
Description:
Reported by Christian Holler on mailing list, test named
'crashMemCorruptionZvalDtorFunc', produces the following on valgrind:
==71892== Invalid read of size 4
==71892==at 0x51D7EA: zend_hash_destroy (in /Users/smalyshev/mphp)
==71892==by 0x50DFCC: _zval_dtor_func (in /Users/smalyshev/mphp)
==71892==by 0x4FFB62: _zval_dtor (in /Users/smalyshev/mphp)
==71892==by 0x4FFEB6: _zval_ptr_dtor (in /Users/smalyshev/mphp)
==71892==by 0x5B0982: ZEND_ASSIGN_DIM_SPEC_CV_CONST_HANDLER (in
/Users/smalyshev/mphp)
==71892==by 0x53AB23: execute (in /Users/smalyshev/mphp)
==71892==by 0x510794: zend_execute_scripts (in /Users/smalyshev/mphp)
==71892==by 0x49D228: php_execute_script (in /Users/smalyshev/mphp)
==71892==by 0x5D2CDD: main (in /Users/smalyshev/mphp)
==71892== Address 0x5c is not stack'd, malloc'd or (recently) free'd
The bug seems to be because in ZEND_ASSIGN_DIM_SPEC_CV_CONST_HANDLER,
error_zval_ptr is used to assign to it as if it were array, which seems to
lead
to unexpected consequences.
Test script:
---
$a = '0';
var_dump(isset($a['b']));
$simpleString = preg_match('//', '', $a->a);
$simpleString["wrong"] = "f";
--
Edit bug report at http://bugs.php.net/bug.php?id=54262&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54262&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54262&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54262&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54262&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54262&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54262&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54262&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54262&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54262&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54262&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54262&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54262&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54262&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54262&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54262&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54262&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54262&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54262&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54262&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54262&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54262&r=mysqlcfg
[PHP-BUG] Bug #54261 [NEW]: Crash when assigning value to a dimension in a non-array
From:
Operating system: MacOS X 10.6.6
PHP version: 5.3SVN-2011-03-16 (SVN)
Package: Reproducible crash
Bug Type: Bug
Bug description:Crash when assigning value to a dimension in a non-array
Description:
Reported by Christian Holler on mailing list, test named
'crashMemCorruptionZvalDtorFunc', produces the following on valgrind:
==71892== Invalid read of size 4
==71892==at 0x51D7EA: zend_hash_destroy (in /Users/smalyshev/mphp)
==71892==by 0x50DFCC: _zval_dtor_func (in /Users/smalyshev/mphp)
==71892==by 0x4FFB62: _zval_dtor (in /Users/smalyshev/mphp)
==71892==by 0x4FFEB6: _zval_ptr_dtor (in /Users/smalyshev/mphp)
==71892==by 0x5B0982: ZEND_ASSIGN_DIM_SPEC_CV_CONST_HANDLER (in
/Users/smalyshev/mphp)
==71892==by 0x53AB23: execute (in /Users/smalyshev/mphp)
==71892==by 0x510794: zend_execute_scripts (in /Users/smalyshev/mphp)
==71892==by 0x49D228: php_execute_script (in /Users/smalyshev/mphp)
==71892==by 0x5D2CDD: main (in /Users/smalyshev/mphp)
==71892== Address 0x5c is not stack'd, malloc'd or (recently) free'd
The bug seems to be because in ZEND_ASSIGN_DIM_SPEC_CV_CONST_HANDLER,
error_zval_ptr is used to assign to it as if it were array, which seems to
lead
to unexpected consequences.
Test script:
---
$a = '0';
var_dump(isset($a['b']));
$simpleString = preg_match('//', '', $a->a);
$simpleString["wrong"] = "f";
--
Edit bug report at http://bugs.php.net/bug.php?id=54261&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54261&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54261&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54261&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54261&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54261&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54261&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54261&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54261&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54261&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54261&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54261&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54261&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54261&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54261&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54261&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54261&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54261&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54261&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54261&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54261&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54261&r=mysqlcfg
[PHP-BUG] Bug #54260 [NEW]: 7+SP1 shows as unknown os
From: Operating system: Windows 7 PHP version: 5.3.6RC3 Package: Win32API related Bug Type: Bug Bug description:7+SP1 shows as unknown os Description: Directly from phpinfo(): System Windows NT BIG-PC 6.1 build 7601 (Unknow Windows version Ultimate Edition Service Pack 1) i586 Build Date Mar 10 2011 13:15:16 CompilerMSVC9 (Visual C++ 2008) Test script: --- -- Edit bug report at http://bugs.php.net/bug.php?id=54260&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54260&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54260&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54260&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54260&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54260&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54260&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54260&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54260&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54260&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54260&r=support Expected behavior: http://bugs.php.net/fix.php?id=54260&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54260&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54260&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54260&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54260&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54260&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54260&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54260&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54260&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54260&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54260&r=mysqlcfg
Bug #54255 [Fbk]: FILTER_VALIDATE_URL does not allow - in domain name
Edit report at http://bugs.php.net/bug.php?id=54255&edit=1
ID: 54255
Updated by: paj...@php.net
Reported by:nm at web dot am
Summary:FILTER_VALIDATE_URL does not allow - in domain name
Status: Feedback
Type: Bug
Package:Filter related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
As in try using php.net's sources. Then bogus it again :)
Previous Comments:
[2011-03-15 23:05:34] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2011-03-15 23:00:52] nm at web dot am
What the f...bug!
changed http to hxxp to prevent spam detection :) change back while
testing.
Let's compare the results:
Ubuntu 10.10, Linux eniac 2.6.36-020636-generic #201010210905 SMP Thu
Oct 21 09:08:58 UTC 2010 x86_64 GNU/Linux, PHP 5.3.3-1ubuntu9.3 with
Suhosin-Patch (cli) (built: Jan 12 2011 16:07:38) , package: php5
5.3.3-1ubuntu9.3
works as expected.
@eniac ~> php -r 'var_dump(filter_var("hxxp://asd_asd.de",
FILTER_VALIDATE_URL));'
bool(false)
@eniac ~> php -r 'var_dump(filter_var("hxxp://asd-asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd-asd.de";
@eniac ~>
CentOS 5, 2.6.18-194.8.1.el5.028stab070.5 , PHP 5.2.9
@www1 ~> php -r 'var_dump(filter_var("hxxp://asd_asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd_asd.de";
@www1 ~> php -r 'var_dump(filter_var("hxxp://asd-asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd-asd.de";
well, this is the bug, but fixed in upstream.
FreeBSD 8.0-RELEASE-p4, PHP 5.3.5 with Suhosin-Patch (cli) (built: Mar
14 2011 17:47:34), package php5-5.3.5 (compiled from ports)
@www-backup ...db/pkg> php -r 'var_dump(filter_var("hxxp://asd_asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd_asd.de";
@www-backup ...db/pkg> php -r 'var_dump(filter_var("hxxp://asd-asd.de",
FILTER_VALIDATE_URL));'
bool(false)
@www-backup ...db/pkg>
What is wrong with it on FreeBSD ?
Seems that it is more build or OS related problem, than php itself.
[2011-03-15 15:39:25] ras...@php.net
Oh, and:
# php -r 'var_dump(filter_var("http://ea_sd.com";,
FILTER_VALIDATE_URL));'
bool(false)
[2011-03-15 15:38:21] ras...@php.net
# php -v
PHP 5.3.5 (cli) (built: Mar 15 2011 07:36:59)
# php -r 'var_dump(filter_var("http://ea-sd.com";,
FILTER_VALIDATE_URL));'
string(16) "http://ea-sd.com";
[2011-03-15 09:56:49] nm at web dot am
Description:
FILTER_VALIDATE_URL documentatin says that it does filtering according
to rfc2396, but in fact filter_var fails to conform RFC.
Hostname definition in rfc is as follows:
hostport = host [ ":" port ]
host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
so it should allow "-" dash symbol in domainnames (both domain name and
TLD name).
In other hand it SHOULD NOT allow "_" symbol in the domain name, as it
is against specification (right now it allows).
Test script:
---
first case also should validate successfully
php -r 'var_dump(filter_var("http://ea-sd.com";, FILTER_VALIDATE_URL));'
bool(false)
php -r 'var_dump(filter_var("http://easd.com";, FILTER_VALIDATE_URL));'
string(15) "http://easd.com";
--
Edit this bug report at http://bugs.php.net/bug.php?id=54255&edit=1
Bug #54255 [Bgs->Fbk]: FILTER_VALIDATE_URL does not allow - in domain name
Edit report at http://bugs.php.net/bug.php?id=54255&edit=1
ID: 54255
Updated by: paj...@php.net
Reported by:nm at web dot am
Summary:FILTER_VALIDATE_URL does not allow - in domain name
-Status: Bogus
+Status: Feedback
Type: Bug
Package:Filter related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2011-03-15 23:00:52] nm at web dot am
What the f...bug!
changed http to hxxp to prevent spam detection :) change back while
testing.
Let's compare the results:
Ubuntu 10.10, Linux eniac 2.6.36-020636-generic #201010210905 SMP Thu
Oct 21 09:08:58 UTC 2010 x86_64 GNU/Linux, PHP 5.3.3-1ubuntu9.3 with
Suhosin-Patch (cli) (built: Jan 12 2011 16:07:38) , package: php5
5.3.3-1ubuntu9.3
works as expected.
@eniac ~> php -r 'var_dump(filter_var("hxxp://asd_asd.de",
FILTER_VALIDATE_URL));'
bool(false)
@eniac ~> php -r 'var_dump(filter_var("hxxp://asd-asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd-asd.de";
@eniac ~>
CentOS 5, 2.6.18-194.8.1.el5.028stab070.5 , PHP 5.2.9
@www1 ~> php -r 'var_dump(filter_var("hxxp://asd_asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd_asd.de";
@www1 ~> php -r 'var_dump(filter_var("hxxp://asd-asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd-asd.de";
well, this is the bug, but fixed in upstream.
FreeBSD 8.0-RELEASE-p4, PHP 5.3.5 with Suhosin-Patch (cli) (built: Mar
14 2011 17:47:34), package php5-5.3.5 (compiled from ports)
@www-backup ...db/pkg> php -r 'var_dump(filter_var("hxxp://asd_asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd_asd.de";
@www-backup ...db/pkg> php -r 'var_dump(filter_var("hxxp://asd-asd.de",
FILTER_VALIDATE_URL));'
bool(false)
@www-backup ...db/pkg>
What is wrong with it on FreeBSD ?
Seems that it is more build or OS related problem, than php itself.
[2011-03-15 15:39:25] ras...@php.net
Oh, and:
# php -r 'var_dump(filter_var("http://ea_sd.com";,
FILTER_VALIDATE_URL));'
bool(false)
[2011-03-15 15:38:21] ras...@php.net
# php -v
PHP 5.3.5 (cli) (built: Mar 15 2011 07:36:59)
# php -r 'var_dump(filter_var("http://ea-sd.com";,
FILTER_VALIDATE_URL));'
string(16) "http://ea-sd.com";
[2011-03-15 09:56:49] nm at web dot am
Description:
FILTER_VALIDATE_URL documentatin says that it does filtering according
to rfc2396, but in fact filter_var fails to conform RFC.
Hostname definition in rfc is as follows:
hostport = host [ ":" port ]
host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
so it should allow "-" dash symbol in domainnames (both domain name and
TLD name).
In other hand it SHOULD NOT allow "_" symbol in the domain name, as it
is against specification (right now it allows).
Test script:
---
first case also should validate successfully
php -r 'var_dump(filter_var("http://ea-sd.com";, FILTER_VALIDATE_URL));'
bool(false)
php -r 'var_dump(filter_var("http://easd.com";, FILTER_VALIDATE_URL));'
string(15) "http://easd.com";
--
Edit this bug report at http://bugs.php.net/bug.php?id=54255&edit=1
Bug #54255 [Com]: FILTER_VALIDATE_URL does not allow - in domain name
Edit report at http://bugs.php.net/bug.php?id=54255&edit=1
ID: 54255
Comment by: nm at web dot am
Reported by:nm at web dot am
Summary:FILTER_VALIDATE_URL does not allow - in domain name
Status: Bogus
Type: Bug
Package:Filter related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
What the f...bug!
changed http to hxxp to prevent spam detection :) change back while
testing.
Let's compare the results:
Ubuntu 10.10, Linux eniac 2.6.36-020636-generic #201010210905 SMP Thu
Oct 21 09:08:58 UTC 2010 x86_64 GNU/Linux, PHP 5.3.3-1ubuntu9.3 with
Suhosin-Patch (cli) (built: Jan 12 2011 16:07:38) , package: php5
5.3.3-1ubuntu9.3
works as expected.
@eniac ~> php -r 'var_dump(filter_var("hxxp://asd_asd.de",
FILTER_VALIDATE_URL));'
bool(false)
@eniac ~> php -r 'var_dump(filter_var("hxxp://asd-asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd-asd.de";
@eniac ~>
CentOS 5, 2.6.18-194.8.1.el5.028stab070.5 , PHP 5.2.9
@www1 ~> php -r 'var_dump(filter_var("hxxp://asd_asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd_asd.de";
@www1 ~> php -r 'var_dump(filter_var("hxxp://asd-asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd-asd.de";
well, this is the bug, but fixed in upstream.
FreeBSD 8.0-RELEASE-p4, PHP 5.3.5 with Suhosin-Patch (cli) (built: Mar
14 2011 17:47:34), package php5-5.3.5 (compiled from ports)
@www-backup ...db/pkg> php -r 'var_dump(filter_var("hxxp://asd_asd.de",
FILTER_VALIDATE_URL));'
string(17) "http://asd_asd.de";
@www-backup ...db/pkg> php -r 'var_dump(filter_var("hxxp://asd-asd.de",
FILTER_VALIDATE_URL));'
bool(false)
@www-backup ...db/pkg>
What is wrong with it on FreeBSD ?
Seems that it is more build or OS related problem, than php itself.
Previous Comments:
[2011-03-15 15:39:25] ras...@php.net
Oh, and:
# php -r 'var_dump(filter_var("http://ea_sd.com";,
FILTER_VALIDATE_URL));'
bool(false)
[2011-03-15 15:38:21] ras...@php.net
# php -v
PHP 5.3.5 (cli) (built: Mar 15 2011 07:36:59)
# php -r 'var_dump(filter_var("http://ea-sd.com";,
FILTER_VALIDATE_URL));'
string(16) "http://ea-sd.com";
[2011-03-15 09:56:49] nm at web dot am
Description:
FILTER_VALIDATE_URL documentatin says that it does filtering according
to rfc2396, but in fact filter_var fails to conform RFC.
Hostname definition in rfc is as follows:
hostport = host [ ":" port ]
host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
so it should allow "-" dash symbol in domainnames (both domain name and
TLD name).
In other hand it SHOULD NOT allow "_" symbol in the domain name, as it
is against specification (right now it allows).
Test script:
---
first case also should validate successfully
php -r 'var_dump(filter_var("http://ea-sd.com";, FILTER_VALIDATE_URL));'
bool(false)
php -r 'var_dump(filter_var("http://easd.com";, FILTER_VALIDATE_URL));'
string(15) "http://easd.com";
--
Edit this bug report at http://bugs.php.net/bug.php?id=54255&edit=1
Bug #54257 [Opn->Fbk]: Internal Server Error
Edit report at http://bugs.php.net/bug.php?id=54257&edit=1
ID: 54257
Updated by: fel...@php.net
Reported by:dorin dot marcoci at gmail dot com
Summary:Internal Server Error
-Status: Open
+Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Debian 6.0
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
[2011-03-15 15:35:46] dorin dot marcoci at gmail dot com
Description:
Run test script.
Test script:
---
Get('cart');
?>
Expected result:
Report an error message.
Actual result:
--
Eroare HTTP 500 (Internal Server Error): Când serverul a încercat sÄ
îndeplineascÄ
solicitarea, a apÄrut o situaÅ£ie neaÅteptatÄ.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54257&edit=1
[PHP-BUG] Req #54259 [NEW]: Add SORT_NONE type to array_mulitsort
From:
Operating system: OS X 10.6
PHP version: 5.3.5
Package: Arrays related
Bug Type: Feature/Change Request
Bug description:Add SORT_NONE type to array_mulitsort
Description:
It'd be useful to have a SORT_NONE option in the array_multisort function.
This
would allow users to specify that they do not care to sort along a
particular
index.
In the sample code below, I've attached one possible use arising in Drupal.
(See
http://drupal.org/node/972536). Generically, we want to sort some array
($menu)
before inserting it into the database. To do so, we first compute the
desired
sort order ($sort) and then call the array_multisort function as
array_multisort($sort, SORT_NUMERIC, $menu);
This works great, sorting $menu according to the sort order in $sort,
however if
$menu contains any objects the array_multisort function throws an error
(Notice:
Object of class stdClass could not be converted to int in ...).
I'm proposing the addition of a SORT_NONE option so that the function call
could
instead be
array_multisort($sort, SORT_NUMERIC, $menu, SORT_NONE);
This would not throw an error since no comparisons would be done with the
attributes of $menu.
Implementing this should be relatively straightforward, I would imagine.
Test script:
---
$sort = array(
'A' => 2,
'A' => 1,
'B' => 1,
);
$menu['A'] = array(
'access' => array(1),
);
$menu['B'] = array(
'access' => array((object) array('a', 'b')),
);
$menu['C'] = array(
'access' => array(0),
);
array_multisort($sort, SORT_NUMERIC, $menu, SORT_NONE);
Expected result:
$sort =
Array
(
[C] => 1
[B] => 1
[A] => 2
)
$menu =
Array
(
[C] => Array
(
[access] => Array
(
[0] => 0
)
)
[B] => Array
(
[access] => Array
(
[0] => stdClass Object
(
[0] => a
[1] => b
)
)
)
[A] => Array
(
[access] => Array
(
[0] => 1
)
)
)
Actual result:
--
(Not applicable, since this is a feature request).
--
Edit bug report at http://bugs.php.net/bug.php?id=54259&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54259&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54259&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54259&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54259&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54259&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54259&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54259&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54259&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54259&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54259&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54259&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54259&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54259&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54259&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54259&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54259&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54259&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54259&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54259&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54259&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54259&r=mysqlcfg
Bug #54250 [Com]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250&edit=1
ID: 54250
Comment by: seanius at debian dot org
Reported by:maciej at wiercinski dot net
Summary:date_default_timezone_set stat()'s whole
/usr/share/zoneinfo upon first call
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Linux 2.6
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Hi guys,
We'll take up further discussion on the bug over there, but thought I
would cut/paste the (slightly amended) initial response here just for
posterity's sake.
===
Hi Maciej,
Does this actually cause a quantifiable and significant performance
regression? This possibility of performance issues was discussed some
time ago but it was decided that the stat calls would just hit the
kernel
fs cache and not cause any serious problems.
If there are indeed problems, there are certainly ways this could be
worked around, but it would add even further complexity
to the patch which we'd all prefer to avoid if possible.
To give you some extra background, since the PHP authors certainly have
their own take on the situation: EVERY serious linux distribution
ships this patch in some form. Redhat, Fedora, Debian, Ubuntu, SLES,
Opensuse (okay, maybe not Gentoo, but anyway...) all ship with this
patch.
So please keep that in mind when you here both sides of this argument
:)
The problem is that when the OS distributors release a timezone update,
they don't want to *also* have to go package by package updating
individual and "customized" timezone databases that might be embedded
in a given application. Neither do they want to continuously update
the
version of PHP in their "stable" releases and have to deal with the
numerous
regressions that would result. The PHP tzdata changes are mixed in with
the
mainline development, and sometimes depend on other changes within the
engine, so it's not really feasible to cherry pick out the changes into
a stable release, even if we wanted to.
This is a point of disagreement with the PHP authors, who want to have
control over this aspect of the engine themselves (and they certainly
have
their justifications, such as systems with outdated or nonexistant
tzdata,
plus they add some extra TZ annotations in their private copy).
Unfortunately they are not interested in providing any other way to
work
around this issue, despite the periodic overture from us or RedHat.
The invitation is still open to try and find a reasonable technical
solution for this, but I have been led to beleive that Derick has
really
dug in his heels on the issue and it's not worth any of our time to
raise a big stink about it.
Previous Comments:
[2011-03-15 13:01:55] maciej at wiercinski dot net
Thanks for the update, it's indeed Debian's fault.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618462
[2011-03-14 19:36:38] 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.
Complain at your distribution for messing it up.
[2011-03-14 19:27:58] ras...@php.net
I think this is going to make Derick's head explode :)
This is likely due to the fact that Ubuntu patches PHP to use the system
timezone
info as opposed to the default bundled data. If you build a clean
version of PHP
on Ubuntu using the code we actually distribute, I think you will find
that the
problem goes away.
[2011-03-14 19:11:29] maciej at wiercinski dot net
Description:
Upon first call to date_default_timezone_set, PHP syscalls stat() on all
the
files in /usr/share/zoneinfo.
It can be easily checked by running:
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 |
grep
zoneinfo
On average Debian/Ubuntu system it accounts for little over 600
syscalls.
Reproduced on:
PHP 5.3.5-1 with Suhosin-Patch (cli) (built: Feb 19 2011 01:57:59)
Copyright (c) 1997-2009 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
with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH
PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4 20
[PHP-BUG] Bug #54258 [NEW]: MySQL: Silent ignorance of binds inside comments causes other to be wrong bound
From:
Operating system: Linux
PHP version: 5.3.5
Package: PDO related
Bug Type: Bug
Bug description:MySQL: Silent ignorance of binds inside comments causes other
to be wrong bound
Description:
See test script.
Test script:
---
$statement = $DB->prepare("UPDATE t SET /*field1 = :field1, */field2 =
:field2");
$field1 = 1;
$field2 = 2;
$statement->bindParam(":field1", $field1, PDO::PARAM_INT);
$statement->bindParam(":field2", $field2, PDO::PARAM_INT);
$statement->execute();
Expected result:
Query "UPDATE t SET /*field1 = 1, */field2 = 2" or error message like
"wrong param count".
Actual result:
--
Silently running query "UPDATE t SET /*field1 = ?, */field2 = 1".
--
Edit bug report at http://bugs.php.net/bug.php?id=54258&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54258&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54258&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54258&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54258&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54258&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54258&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54258&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54258&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54258&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54258&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54258&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54258&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54258&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54258&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54258&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54258&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54258&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54258&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54258&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54258&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54258&r=mysqlcfg
Bug #54255 [Bgs]: FILTER_VALIDATE_URL does not allow - in domain name
Edit report at http://bugs.php.net/bug.php?id=54255&edit=1
ID: 54255
Updated by: ras...@php.net
Reported by:nm at web dot am
Summary:FILTER_VALIDATE_URL does not allow - in domain name
Status: Bogus
Type: Bug
Package:Filter related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Oh, and:
# php -r 'var_dump(filter_var("http://ea_sd.com";,
FILTER_VALIDATE_URL));'
bool(false)
Previous Comments:
[2011-03-15 15:38:21] ras...@php.net
# php -v
PHP 5.3.5 (cli) (built: Mar 15 2011 07:36:59)
# php -r 'var_dump(filter_var("http://ea-sd.com";,
FILTER_VALIDATE_URL));'
string(16) "http://ea-sd.com";
[2011-03-15 09:56:49] nm at web dot am
Description:
FILTER_VALIDATE_URL documentatin says that it does filtering according
to rfc2396, but in fact filter_var fails to conform RFC.
Hostname definition in rfc is as follows:
hostport = host [ ":" port ]
host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
so it should allow "-" dash symbol in domainnames (both domain name and
TLD name).
In other hand it SHOULD NOT allow "_" symbol in the domain name, as it
is against specification (right now it allows).
Test script:
---
first case also should validate successfully
php -r 'var_dump(filter_var("http://ea-sd.com";, FILTER_VALIDATE_URL));'
bool(false)
php -r 'var_dump(filter_var("http://easd.com";, FILTER_VALIDATE_URL));'
string(15) "http://easd.com";
--
Edit this bug report at http://bugs.php.net/bug.php?id=54255&edit=1
Bug #54255 [Opn->Bgs]: FILTER_VALIDATE_URL does not allow - in domain name
Edit report at http://bugs.php.net/bug.php?id=54255&edit=1
ID: 54255
Updated by: ras...@php.net
Reported by:nm at web dot am
Summary:FILTER_VALIDATE_URL does not allow - in domain name
-Status: Open
+Status: Bogus
Type: Bug
Package:Filter related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
# php -v
PHP 5.3.5 (cli) (built: Mar 15 2011 07:36:59)
# php -r 'var_dump(filter_var("http://ea-sd.com";,
FILTER_VALIDATE_URL));'
string(16) "http://ea-sd.com";
Previous Comments:
[2011-03-15 09:56:49] nm at web dot am
Description:
FILTER_VALIDATE_URL documentatin says that it does filtering according
to rfc2396, but in fact filter_var fails to conform RFC.
Hostname definition in rfc is as follows:
hostport = host [ ":" port ]
host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
so it should allow "-" dash symbol in domainnames (both domain name and
TLD name).
In other hand it SHOULD NOT allow "_" symbol in the domain name, as it
is against specification (right now it allows).
Test script:
---
first case also should validate successfully
php -r 'var_dump(filter_var("http://ea-sd.com";, FILTER_VALIDATE_URL));'
bool(false)
php -r 'var_dump(filter_var("http://easd.com";, FILTER_VALIDATE_URL));'
string(15) "http://easd.com";
--
Edit this bug report at http://bugs.php.net/bug.php?id=54255&edit=1
[PHP-BUG] Bug #54257 [NEW]: Internal Server Error
From:
Operating system: Debian 6.0
PHP version: 5.3.5
Package: Reproducible crash
Bug Type: Bug
Bug description:Internal Server Error
Description:
Run test script.
Test script:
---
Get('cart');
?>
Expected result:
Report an error message.
Actual result:
--
Eroare HTTP 500 (Internal Server Error): Când serverul a încercat sÄ
îndeplineascÄ
solicitarea, a apÄrut o situaÅ£ie neaÅteptatÄ.
--
Edit bug report at http://bugs.php.net/bug.php?id=54257&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54257&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54257&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54257&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54257&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54257&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54257&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54257&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54257&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54257&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54257&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54257&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54257&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54257&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54257&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54257&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54257&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54257&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54257&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54257&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54257&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54257&r=mysqlcfg
[PHP-BUG] Bug #54256 [NEW]: DirectoryIterator isn't iterable with a foreach
From:
Operating system: Debian unstable
PHP version: 5.3.5
Package: SPL related
Bug Type: Bug
Bug description:DirectoryIterator isn't iterable with a foreach
Description:
Hello,
DirectoryIterator is iterable in a while but not in a foreach.
This bug is reproductible only on a vboxsf filesystem. I run this script on
Debian sid hosted on Windows XP (NTFS formated hd).
I have no problem when I execute this script on Windows or on a virtual
disk.
Test script:
---
valid()) {
$files[] = (string)$dir->current();
$dir->next();
}
return $files;
}
function test_iterator_bug($dirname) {
$files = array();
$dir = new DirectoryIterator($dirname);
foreach($dir as $file) {
$files[] = (string)$file;
}
return $files;
}
echo 'PHP version: ' . phpversion() . "\n\n";
$dirname = dirname(__FILE__);
foreach (array('iterator', 'iterator_bug') as $test_name) {
echo "--- {$test_name} ---\n";
$foo = "test_{$test_name}";
var_dump($foo($dirname));
echo "\n";
}
Expected result:
PHP version: 5.3.5-1
--- iterator ---
array(3) {
[0]=>
string(1) "."
[1]=>
string(2) ".."
[2]=>
string(9) "index.php"
}
--- iterator_bug ---
array(3) {
[0]=>
string(1) "."
[1]=>
string(2) ".."
[2]=>
string(9) "index.php"
}
Actual result:
--
PHP version: 5.3.5-1
--- iterator ---
array(3) {
[0]=>
string(1) "."
[1]=>
string(2) ".."
[2]=>
string(9) "index.php"
}
--- iterator_bug ---
array(0) {
}
--
Edit bug report at http://bugs.php.net/bug.php?id=54256&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54256&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54256&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54256&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54256&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54256&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54256&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54256&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54256&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54256&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54256&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54256&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54256&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54256&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54256&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54256&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54256&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54256&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54256&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54256&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54256&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54256&r=mysqlcfg
Bug #54250 [Com]: date_default_timezone_set stat()'s whole /usr/share/zoneinfo upon first call
Edit report at http://bugs.php.net/bug.php?id=54250&edit=1
ID: 54250
Comment by: maciej at wiercinski dot net
Reported by:maciej at wiercinski dot net
Summary:date_default_timezone_set stat()'s whole
/usr/share/zoneinfo upon first call
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Linux 2.6
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Thanks for the update, it's indeed Debian's fault.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618462
Previous Comments:
[2011-03-14 19:36:38] 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.
Complain at your distribution for messing it up.
[2011-03-14 19:27:58] ras...@php.net
I think this is going to make Derick's head explode :)
This is likely due to the fact that Ubuntu patches PHP to use the system
timezone
info as opposed to the default bundled data. If you build a clean
version of PHP
on Ubuntu using the code we actually distribute, I think you will find
that the
problem goes away.
[2011-03-14 19:11:29] maciej at wiercinski dot net
Description:
Upon first call to date_default_timezone_set, PHP syscalls stat() on all
the
files in /usr/share/zoneinfo.
It can be easily checked by running:
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 |
grep
zoneinfo
On average Debian/Ubuntu system it accounts for little over 600
syscalls.
Reproduced on:
PHP 5.3.5-1 with Suhosin-Patch (cli) (built: Feb 19 2011 01:57:59)
Copyright (c) 1997-2009 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
with Suhosin v0.9.29, Copyright (c) 2007, by SektionEins GmbH
PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4 2010
03:25:57)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans
PHP 5.3.2-1ubuntu4.7 with Suhosin-Patch (cli) (built: Jan 12 2011
18:36:08)
Copyright (c) 1997-2009 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
*Not* reproduced on:
PHP 5.3.3-0.dotdeb.1 with Suhosin-Patch (cli) (built: Oct 1 2010
08:49:29)
Copyright (c) 1997-2009 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
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins
GmbH
Test script:
---
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 |
grep zoneinfo | head -10
0.000190 open("/usr/share/zoneinfo/",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
0.46 stat64("/usr/share/zoneinfo//localtime",
{st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
0.000112 stat64("/usr/share/zoneinfo//Zulu", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
0.000101 stat64("/usr/share/zoneinfo//WET", {st_mode=S_IFREG|0644,
st_size=1873, ...}) = 0
0.000100 stat64("/usr/share/zoneinfo//W-SU", {st_mode=S_IFREG|0644,
st_size=2194, ...}) = 0
0.98 stat64("/usr/share/zoneinfo//Universal",
{st_mode=S_IFREG|0644, st_size=118, ...}) = 0
0.000101 stat64("/usr/share/zoneinfo//UTC", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
0.99 stat64("/usr/share/zoneinfo//US", {st_mode=S_IFDIR|0755,
st_size=352, ...}) = 0
0.97 stat64("/usr/share/zoneinfo//UCT", {st_mode=S_IFREG|0644,
st_size=118, ...}) = 0
0.99 stat64("/usr/share/zoneinfo//Turkey",
{st_mode=S_IFREG|0644, st_size=2721, ...}) = 0
$ strace -s 100 -r php -n -r"date_default_timezone_set('GMT');" 2>&1 |
grep zoneinfo | wc -l
626
--
Edit this bug report at http://bugs.php.net/bug.php?id=54250&edit=1
Bug #53851 [Opn->Asn]: socket_create protocol int (IPv6)
Edit report at http://bugs.php.net/bug.php?id=53851&edit=1
ID: 53851
Updated by: cataphr...@php.net
Reported by:spandit at stealth dot net
Summary:socket_create protocol int (IPv6)
-Status: Open
+Status: Assigned
Type: Bug
Package:Sockets related
Operating System: FreeBSD 8.x
PHP Version:5.3.5
-Assigned To:
+Assigned To:cataphract
Block user comment: N
Private report: N
Previous Comments:
[2011-01-28 00:36:04] ahar...@php.net
I don't think there's any great need to put specific IPv6 protocol
information into the manual page, but someone familiar with ICMP
should have a look at the other potential bug.
[2011-01-27 18:45:05] spandit at stealth dot net
I'd also like to add that the full IPv6 packet is not passed to
socket_read() in
this particular test.
socket_read() sees:
800046e2486f776479
810045e2486f776479
tcpdump sees:
12:44:30.720191 IP6 (hlim 64, next-header ICMPv6 (58) payload length:
13) ::1 >
::1: [icmp6 sum ok] ICMP6, echo request, length 13, seq 0
0x: 6000 000d 3a40 `.:@
0x0010: 0001
0x0020: 0001 8000 46e2 ..F.
0x0030: 486f 7764 79 Howdy
12:44:30.720227 IP6 (hlim 64, next-header ICMPv6 (58) payload length:
13) ::1 >
::1: [icmp6 sum ok] ICMP6, echo reply, length 13, seq 0
0x: 6000 000d 3a40 `.:@
0x0010: 0001
0x0020: 0001 8100 45e2 ..E.
0x0030: 486f 7764 79 Howdy
[2011-01-26 23:39:29] spandit at stealth dot net
Discard; Perhaps the doc should just be updated to include some IPv6
protocols
(e.g. ipv6-icmp)
[2011-01-26 23:36:22] spandit at stealth dot net
Description:
---
>From manual page: http://www.php.net/function.socket-create#Parameters
---
The protocol section needs to be updated to account for the IPv6
protocol numbers.
For example, calling getprotobyname('icmp') returns 1; or users would
enter '1'
for ICMP. For IPv6, this would be '58'. To open a raw socket for a
ICMPv6, the
command would be: socket_create(AF_INET6, SOCK_RAW, '58');
Test script:
---
http://bugs.php.net/bug.php?id=53851&edit=1
[PHP-BUG] Bug #54255 [NEW]: FILTER_VALIDATE_URL does not allow - in domain name
From:
Operating system: Linux
PHP version: 5.3.5
Package: Filter related
Bug Type: Bug
Bug description:FILTER_VALIDATE_URL does not allow - in domain name
Description:
FILTER_VALIDATE_URL documentatin says that it does filtering according to
rfc2396, but in fact filter_var fails to conform RFC.
Hostname definition in rfc is as follows:
hostport = host [ ":" port ]
host = hostname | IPv4address
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel = alpha | alpha *( alphanum | "-" ) alphanum
so it should allow "-" dash symbol in domainnames (both domain name and TLD
name).
In other hand it SHOULD NOT allow "_" symbol in the domain name, as it is
against specification (right now it allows).
Test script:
---
first case also should validate successfully
php -r 'var_dump(filter_var("http://ea-sd.com";, FILTER_VALIDATE_URL));'
bool(false)
php -r 'var_dump(filter_var("http://easd.com";, FILTER_VALIDATE_URL));'
string(15) "http://easd.com";
--
Edit bug report at http://bugs.php.net/bug.php?id=54255&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54255&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54255&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54255&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54255&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54255&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54255&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54255&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54255&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54255&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54255&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54255&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54255&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54255&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54255&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54255&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54255&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54255&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54255&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54255&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54255&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54255&r=mysqlcfg
[PHP-BUG] Bug #54254 [NEW]: cal_from_jd returns month = 6 when there is only one Adar
From: Operating system: PHP version: 5.3.5 Package: Calendar related Bug Type: Bug Bug description:cal_from_jd returns month = 6 when there is only one Adar Description: cal_from_jd() returns 6 for Adar when there is only one Adar, (it should return 7, since if there is only one Adar it's AdarII). It also says "AdarI", which is wrong (it should be either "Adar" or at least "AdarII"). Furthermore the cal_days_in_month() (correctly) only works with month 7, and not 6 as returned by cal_from_jd. Test script: --- Expected result: The month in cal_from_jd should be 7. The second two lines demonstrate how cal_days_in_month also expects the month to be 7. Actual result: -- Array ( [date] => 6/24/5772 [month] => 6 [day] => 24 [year] => 5772 [dow] => 0 [abbrevdayname] => Sun [dayname] => Sunday [abbrevmonth] => AdarI [monthname] => AdarI ) 0 29 -- Edit bug report at http://bugs.php.net/bug.php?id=54254&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54254&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54254&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54254&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54254&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54254&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54254&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54254&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54254&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54254&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54254&r=support Expected behavior: http://bugs.php.net/fix.php?id=54254&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54254&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54254&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54254&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54254&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54254&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54254&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54254&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54254&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54254&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54254&r=mysqlcfg
Bug #49948 [Com]: stream_select() / _get_osfhandle
Edit report at http://bugs.php.net/bug.php?id=49948&edit=1
ID: 49948
Comment by: ivan dot enderlin at hoa-project dot net
Reported by:u...@php.net
Summary:stream_select() / _get_osfhandle
Status: Assigned
Type: Bug
Package:Streams related
Operating System: win32 only - Windows
PHP Version:5.3SVN-2009-10-21 (snap)
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I got the same problem with PHP5.3.4 on Windows7 (6.1.7600).
Previous Comments:
[2011-03-15 08:35:03] ivan dot enderlin at hoa-project dot net
I got the same problem with PHP5.3.3 on Windows7 (6.1.7600) and maybe
with 5.3.2 too. Problem comes from stream_select and produces a warning:
invalid CRT.
[2010-08-23 19:03:38] the...@php.net
Same on with VC9 binaries from 5.3.3-RELEASE using the non-threadsafe
version. So basically anything with VC9.
The warning I get (both Windows XP and Windows Vista) is:
"Invalid CRT parameters detected"
I'm using the second example (w/ fsockopen("www.google.com"[...])).
[2010-06-21 19:45:38] will at flourishlib dot com
I am getting the same bug with the PHP 5.3.3RC1 VC9 x86 Thread Safe
build. The
server is a Windows 2008 R2 x64 machine. The code that is producing the
error
for me is:
The error is:
Warning: Invalid CRT parameters detected in C:\tmp\stream_select.php on
line 10
I can probably provide access to the machine if need be.
[2009-10-21 18:13:26] u...@php.net
Description:
Hi,
I am getting "Invalid parameter detected in CRT function
'_get_osfhandle'" when running the below code.
I have compiled a source code snapshot version of PHP 5.3.2-dev on
Windows. I used VC9 Express and SDK 6.1 . OS is XP Prof. I've run PHP
from within the build tree in the hope it will pick the binaries (dlls,
resource files, whatever there is) I have compiled myself.
However, I have also seen this warning with yesterdays VC9 non TS
binaries from the windows.php.net on another box. A couple of ext/mysqli
tests fail because of the warning. The affected mysqli API calls is
mysqli_poll(). It makes use of [php_]select() just like the below code.
Reproduce code:
---
$stream = stream_socket_client("tcp://193.99.144.80:80", $errno, $error,
$whatever, STREAM_CLIENT_ASYNC_CONNECT | STREAM_CLIENT_CONNECT);
var_dump($stream);
$read = $write = $except = array($stream);
var_dump(stream_select($read, $write, $except, 1));
Expected result:
No warning.
Actual result:
--
resource(5) of type (stream)
Warning: Invalid parameter detected in CRT function '_get_osfhandle'
(f:\dd\vctools\crt_bld\self_x86\crt\src\osfinfo.c:314) in
E:\php-sdk\php53dev\vc9\x86\php5.
3-200910211230\Debug_TS\select.php on line 5
int(1)
--
Edit this bug report at http://bugs.php.net/bug.php?id=49948&edit=1
Bug #49948 [Com]: stream_select() / _get_osfhandle
Edit report at http://bugs.php.net/bug.php?id=49948&edit=1
ID: 49948
Comment by: ivan dot enderlin at hoa-project dot net
Reported by:u...@php.net
Summary:stream_select() / _get_osfhandle
Status: Assigned
Type: Bug
Package:Streams related
Operating System: win32 only - Windows
PHP Version:5.3SVN-2009-10-21 (snap)
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I got the same problem with PHP5.3.3 on Windows7 (6.1.7600) and maybe
with 5.3.2 too. Problem comes from stream_select and produces a warning:
invalid CRT.
Previous Comments:
[2010-08-23 19:03:38] the...@php.net
Same on with VC9 binaries from 5.3.3-RELEASE using the non-threadsafe
version. So basically anything with VC9.
The warning I get (both Windows XP and Windows Vista) is:
"Invalid CRT parameters detected"
I'm using the second example (w/ fsockopen("www.google.com"[...])).
[2010-06-21 19:45:38] will at flourishlib dot com
I am getting the same bug with the PHP 5.3.3RC1 VC9 x86 Thread Safe
build. The
server is a Windows 2008 R2 x64 machine. The code that is producing the
error
for me is:
The error is:
Warning: Invalid CRT parameters detected in C:\tmp\stream_select.php on
line 10
I can probably provide access to the machine if need be.
[2009-10-21 18:13:26] u...@php.net
Description:
Hi,
I am getting "Invalid parameter detected in CRT function
'_get_osfhandle'" when running the below code.
I have compiled a source code snapshot version of PHP 5.3.2-dev on
Windows. I used VC9 Express and SDK 6.1 . OS is XP Prof. I've run PHP
from within the build tree in the hope it will pick the binaries (dlls,
resource files, whatever there is) I have compiled myself.
However, I have also seen this warning with yesterdays VC9 non TS
binaries from the windows.php.net on another box. A couple of ext/mysqli
tests fail because of the warning. The affected mysqli API calls is
mysqli_poll(). It makes use of [php_]select() just like the below code.
Reproduce code:
---
$stream = stream_socket_client("tcp://193.99.144.80:80", $errno, $error,
$whatever, STREAM_CLIENT_ASYNC_CONNECT | STREAM_CLIENT_CONNECT);
var_dump($stream);
$read = $write = $except = array($stream);
var_dump(stream_select($read, $write, $except, 1));
Expected result:
No warning.
Actual result:
--
resource(5) of type (stream)
Warning: Invalid parameter detected in CRT function '_get_osfhandle'
(f:\dd\vctools\crt_bld\self_x86\crt\src\osfinfo.c:314) in
E:\php-sdk\php53dev\vc9\x86\php5.
3-200910211230\Debug_TS\select.php on line 5
int(1)
--
Edit this bug report at http://bugs.php.net/bug.php?id=49948&edit=1
