[PHP-BUG] Bug #64906 [NEW]: occassional crashes in accel_startup
From: mattficken Operating system: Windows PHP version: 5.5Git-2013-05-23 (snap) Package: opcache Bug Type: Bug Bug description:occassional crashes in accel_startup Description: Running multiple PHPT tests on CLI I occassionally get these crashes (see below). I do this using PFTT, which for this is equivalent to run-test.php except that it runs multiple php processes at a time, instead of just one. This is an updated copy of this issue: https://github.com/zendtech/ZendOptimizerPlus/issues/59 Expected result: PHPT tests pass Actual result: -- 009df904 6f5fc2ef php_opcache!accel_startup+0x119 [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\ext\opcache\zendaccelerator.c @ 2565] (issue 59?) 009df910 6f73ab0a php5!zend_extension_startup+0xf [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\zend\zend_extensions.c @ 154] 009df928 6f4ab016 php5!zend_llist_apply_with_del+0x28f3aa [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\zend\zend_llist.c @ 178] 009dfc0c 000f14be php5!php_module_startup+0x646 [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\main\main.c @ 2207] 009dfc1c 000f2cb8 php!php_cli_startup+0xe [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\sapi\cli\php_cli.c @ 417] 009dfcb4 000f9a0e php!main+0x418 [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\sapi\cli\php_cli.c @ 1357] 009dfcf4 767d3677 php!__tmainCRTStartup+0xfd [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 536] 009dfd00 77a69d72 kernel32!BaseThreadInitThunk+0x12 009dfd40 77a69d45 ntdll!RtlInitializeExceptionChain+0x63 009dfd58 ntdll!RtlInitializeExceptionChain+0x36 00adf7d4 6f5fc2ef php_opcache!accel_startup+0x5705 [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\ext\opcache\zendaccelerator.c @ 2525] 00adf7e0 6f73ab0a php5!zend_extension_startup+0xf [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\zend\zend_extensions.c @ 154] 00adf7f8 6f4ab016 php5!zend_llist_apply_with_del+0x28f3aa [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\zend\zend_llist.c @ 178] 00adfadc 000f14be php5!php_module_startup+0x646 [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\main\main.c @ 2207] 00adfaec 000f2cb8 php!php_cli_startup+0xe [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\sapi\cli\php_cli.c @ 417] 00adfb84 000f9a0e php!main+0x418 [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\sapi\cli\php_cli.c @ 1357] 00adfbc4 767d3677 php!__tmainCRTStartup+0xfd [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 536] 00adfbd0 77a69d72 kernel32!BaseThreadInitThunk+0x12 00adfc10 77a69d45 ntdll!RtlInitializeExceptionChain+0x63 00adfc28 ntdll!RtlInitializeExceptionChain+0x36 00abfb28 744a9a55 php_opcache!accel_new_interned_string+0x130 [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\ext\opcache\zendaccelerator.c @ 325] 00abfb38 744b0cfe php_opcache!accel_use_shm_interned_strings+0x25 [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\ext\opcache\zendaccelerator.c @ 394] 00abfb54 6f5fc2ef php_opcache!accel_startup+0x572e [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\ext\opcache\zendaccelerator.c @ 2535] 00abfb60 6f73ab0a php5!zend_extension_startup+0xf [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\zend\zend_extensions.c @ 154] 00abfb78 6f4ab016 php5!zend_llist_apply_with_del+0x28f3aa [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\zend\zend_llist.c @ 178] 00abfe5c 000f14be php5!php_module_startup+0x646 [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\main\main.c @ 2207] 00abfe6c 000f2cb8 php!php_cli_startup+0xe [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\sapi\cli\php_cli.c @ 417] 00abff04 000f9a0e php!main+0x418 [c:\php-sdk\snap_5_5\vc11\x86\nts-windows-vc11-x86\sapi\cli\php_cli.c @ 1357] 00abff44 767d3677 php!__tmainCRTStartup+0xfd [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 536] WARNING: Stack unwind information not available. Following frames may be wrong. 00abff50 77a69d72 kernel32!BaseThreadInitThunk+0x12 00abff90 77a69d45 ntdll!RtlInitializeExceptionChain+0x63 00abffa8 ntdll!RtlInitializeExceptionChain+0x36 -- Edit bug report at https://bugs.php.net/bug.php?id=64906edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64906r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64906r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64906r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64906r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64906r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64906r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64906r=needscript Try newer version: https://bugs.php.net/fix.php?id=64906r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64906r=support Expected behavior: https://bugs.php.net/fix.php?id=64906r=notwrong Not enough info:
Bug #64720 [Asn-Csd]: SegFault on zend_deactivate
Edit report at https://bugs.php.net/bug.php?id=64720edit=1
ID: 64720
Updated by: dmi...@php.net
Reported by:d dot ananyev at gmail dot com
Summary:SegFault on zend_deactivate
-Status: Assigned
+Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: CentOS release 6.4 (Final)
PHP Version:5.4.10
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2013-05-21 06:35:24] dmi...@php.net
The fix for this bug has been committed.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
[2013-05-21 06:34:09] dmi...@php.net
Automatic comment on behalf of dmi...@zend.com
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=77f15762137e2d8173df9b733b4cb70fc996
Log: Fixed bug #64720 (SegFault on zend_deactivate)
[2013-05-21 05:09:53] dmi...@php.net
Script to Reproduce
---
?php
class Stat {
private static $requests;
public static function getInstance() {
if (!isset(self::$requests[1])) {
self::$requests[1] = new self();
}
return self::$requests[1];
}
public function __destruct() {
unset(self::$requests[1]);
}
}
class Foo {
public function __construct() {
Stat::getInstance();
}
}
class Error {
private $trace;
public function __construct() {
$this-trace = debug_backtrace(1);
}
}
class Bar {
public function __destruct() {
Stat::getInstance();
new Error();
}
public function test() {
new Error();
}
}
$foo = new Foo();
$bar = new Bar();
$bar-test();
?
The crash occurs because PHP tries to access static properties of class Stat
after they are destroyed.
==22607== Invalid read of size 4
==22607==at 0x84EA438: _zval_dtor_func (zend_variables.c:46)
==22607==by 0x84DAA42: _zval_dtor (zend_variables.h:35)
==22607==by 0x84DAAEF: i_zval_ptr_dtor (zend_execute.h:81)
==22607==by 0x84DB851: _zval_ptr_dtor (zend_execute_API.c:428)
==22607==by 0x84E032A: cleanup_user_class_data (zend_opcode.c:169)
==22607==by 0x84E0419: zend_cleanup_user_class_data (zend_opcode.c:202)
==22607==by 0x84FC771: zend_hash_reverse_apply (zend_hash.c:799)
==22607==by 0x84DB4BE: shutdown_executor (zend_execute_API.c:289)
==22607==by 0x84EC528: zend_deactivate (zend.c:939)
==22607==by 0x84744D6: php_request_shutdown (main.c:1800)
==22607==by 0x8585386: do_cli (php_cli.c:1176)
==22607==by 0x8585B2F: main (php_cli.c:1377)
==22607== Address 0x4949fa8 is 0 bytes inside a block of size 20 free'd
==22607==at 0x4007F0F: free (vg_replace_malloc.c:446)
==22607==by 0x84BFEA5: _efree (zend_alloc.c:2437)
==22607==by 0x851CDEB: i_zval_ptr_dtor (zend_execute.h:82)
==22607==by 0x8541EA6: ZEND_UNSET_DIM_SPEC_VAR_CONST_HANDLER
(zend_vm_execute.h:15900)
==22607==by 0x8521499: execute_ex (zend_vm_execute.h:356)
==22607==by 0x85214FD: zend_execute (zend_vm_execute.h:381)
==22607==by 0x84DD3D5: zend_call_function (zend_execute_API.c:941)
==22607==by 0x85080A9: zend_call_method (zend_interfaces.c:97)
==22607==by 0x8515232: zend_objects_destroy_object (zend_objects.c:123)
==22607==by 0x851B546: zend_objects_store_del_ref_by_handle_ex
(zend_objects_API.c:207)
==22607==by 0x851B426: zend_objects_store_del_ref (zend_objects_API.c:173)
==22607==by 0x84EA474: _zval_dtor_func (zend_variables.c:54)
[2013-04-29 09:14:46] d dot ananyev at gmail dot com
It's not opcache related
[2013-04-29 09:01:31] d dot ananyev at gmail dot com
We've got the same segfault trace without any opcode cache.
Core was generated by `php-fpm: pool www
'.
Program terminated with signal 11, Segmentation fault.
#0 _zend_mm_free_int (heap=0x1177330, p=0x17926c0) at /usr/build/php-
5.4.10/php-5.4.10/Zend/zend_alloc.c:2100
2100if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
Missing separate debuginfos, use: debuginfo-install
[PHP-BUG] Bug #64908 [NEW]: DateTime's constructor accepts time that not exists because of DST
From: istvan dot dani at gmail dot com
Operating system: OS X 10.8
PHP version: Irrelevant
Package: Date/time related
Bug Type: Bug
Bug description:DateTime's constructor accepts time that not exists because of
DST
Description:
Europe/Budapest timezone offset is +1, and +2 in DST.
Transition to DST is at 2013-03-31 01:00:00 UTC/GMT.
According to this, locale time should not exists between 02:00:00 and
03:00:00,
and must not be accepted as valid time.
Test script:
---
try {
$wrong_date = new DateTime(2013-03-31 02:30:00, new
DateTimeZone(Europe/Budapest));
} catch (Exception $e) {
echo $e-getMessage();
}
print Wrong date in local timezone: . $wrong_date-format(Y-m-d
H:i:s);
$wrong_date-setTimezone(new DateTimeZone(UTC));
print br /Converting to UTC: . $wrong_date-format(Y-m-d H:i:s);
$wrong_date-setTimezone(new DateTimeZone(Europe/Budapest));
print br /Converting back to locale timezone: .
$wrong_date-format(Y-m-d H:i:s);
Expected result:
Get an exception.
Actual result:
--
Wrong date in local timezone: 2013-03-31 02:30:00
Converting to UTC: 2013-03-31 01:30:00
Converting back to locale timezone: 2013-03-31 03:30:00
--
Edit bug report at https://bugs.php.net/bug.php?id=64908edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64908r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64908r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64908r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64908r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64908r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64908r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64908r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64908r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64908r=support
Expected behavior: https://bugs.php.net/fix.php?id=64908r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64908r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64908r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64908r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64908r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64908r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64908r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64908r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64908r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64908r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64908r=mysqlcfg
Bug #62292 [Com]: Casting object to array brokes isset on numerical keys
Edit report at https://bugs.php.net/bug.php?id=62292edit=1
ID: 62292
Comment by: p dot scheit at ps-webforge dot com
Reported by:hosiplan at gmail dot com
Summary:Casting object to array brokes isset on numerical
keys
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Linux
PHP Version:5.3.13
Block user comment: N
Private report: N
New Comment:
this seems to be a possible duplicate of https://bugs.php.net/bug.php?id=45959
Previous Comments:
[2012-06-11 13:56:18] hosiplan at gmail dot com
Description:
Casting object to array brokes isset on numerical keys
Test script:
---
$obj = json_decode('{100:[10],120:[20]}');
$map = (array)$obj;
var_dump(
isset($obj-{100}),
isset($obj-{100}),
isset($map[100]),
isset($map[100])
);
Expected result:
bool(false)
bool(true)
bool(false)
bool(true)
Actual result:
--
bool(true)
bool(true)
bool(false)
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62292edit=1
Bug #60231 [Com]: child process exited with status 3221225725
Edit report at https://bugs.php.net/bug.php?id=60231edit=1 ID: 60231 Comment by: frank dot ralf at comm-press dot de Reported by:mausglov at yandex dot ru Summary:child process exited with status 3221225725 Status: Open Type: Bug Package:Reproducible crash Operating System: Windows 7 Ultimate PHP Version:5.3.8 Block user comment: N Private report: N New Comment: There's a thorough investigation into the string length problem mentioned in the bug report at http://www.apachefriends.org/f/viewtopic.php?f=16t=48914p=207571#p201370 Previous Comments: [2011-11-17 19:24:04] mausglov at yandex dot ru For Windows XP SP3 ( the debug report was made in this OS ) exit statuses are different: 4294967295 - with DebugDiag; 3221225477 - without [2011-11-17 19:18:43] mausglov at yandex dot ru Full call stack here: http://pastebin.com/HC5Gcthu short version: Function Arg 1 Arg 2 Arg 3 Arg 4 Source php5ts!match+23 0288d97b 01eb2270 0288d740 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\pcre\pcrelib\pcre_exec.c @ 649 php5ts!match+881a 0288d97b 01eb226d 0288d740 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\pcre\pcrelib\pcre_exec.c @ 886 + 35 php5ts!match+899e 0288d979 01eb2294 0288d740 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\pcre\pcrelib\pcre_exec.c @ 1654 + 2a - previuos 2 lines repeated 308 times php5ts!match+881a 0288d740 01eb226d 0288d740 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\pcre\pcrelib\pcre_exec.c @ 886 + 35 php5ts!match+aee 0288d740 01eb2268 0288d740 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\pcre\pcrelib\pcre_exec.c @ 1515 + 2f php5ts!php_pcre_exec+afb 01eb2240 027ff814 0288d740 02c7 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\pcre\pcrelib\pcre_exec.c @ 6099 + 3f php5ts!php_pcre_match_impl+239 01eb2710 0288d740 02c7 0288d370 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\pcre\php_pcre.c @ 629 php5ts!php_do_pcre_match+a8 0002 0002 028925e8 028c0988 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\pcre\php_pcre.c @ 520 + 2b php5ts!zif_preg_match+17 0002 0288d370 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\pcre\php_pcre.c @ 771 + 17 php5ts!zend_do_fcall_common_helper_SPEC+920 028c0988 01dfba00 01dfbae8 028c0988 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\zend\zend_vm_execute.h @ 320 + 41 php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+11a 01e80618 01dfbae8 0288e630 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\zend\zend_vm_execute.h @ 1640 + e php5ts!execute+2e8 0288ecd0 01dfba01 027ffac8 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\zend\zend_vm_execute.h @ 107 + a php5ts!zend_call_function+8c9 01e8063c 028c0370 027ffaa4 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\zend\zend_execute_api.c @ 968 + 1b php5ts!php_array_walk+2e2 0288e138 027ffac8 0001 01dfbae8 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\standard\array.c @ 1115 + 1f php5ts!php_array_walk+1d0 0288d0d0 027ffac8 0001 01dfbae8 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\standard\array.c @ 1094 php5ts!zif_array_walk_recursive+101 0003 0288d2e8 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\ext\standard\array.c @ 1186 php5ts!zend_do_fcall_common_helper_SPEC+920 028c0370 01dfba00 01dfbae8 028c0370 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\zend\zend_vm_execute.h @ 320 + 41 php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+11a 01dfbae8 027ffbe4 027ffe70 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\zend\zend_vm_execute.h @ 1640 + e php5ts!execute+2e8 0288c2a8 01dfba00 01dfbae8 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\zend\zend_vm_execute.h @ 107 + a php5ts!zend_execute_scripts+fe 0008 01dfbae8 0003 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\zend\zend.c @ 1237 php5ts!php_execute_script+24c 027ffe70 01dfbae8 0004 013510a8 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\main\main.c @ 2284 + 12 php5apache2_2!php_handler+634 01df3b28 01df3b28 0090f628 6eecd540 d:\php-sdk\snap_5_3\vc9\x86\php-5.3.8\sapi\apache2handler\sapi_apache2.c @ 669 + e libhttpd!ap_run_handler+25 [2011-11-16 11:33:33] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how
Bug #64837 [Com]: Configure script fails during the check whether build with IMAP works
Edit report at https://bugs.php.net/bug.php?id=64837edit=1 ID: 64837 Comment by: romain at quarkstudio dot fr Reported by:romain at quarkstudio dot fr Summary:Configure script fails during the check whether build with IMAP works Status: Open Type: Bug Package:IMAP related Operating System: Linux PHP Version:5.3.25 Block user comment: N Private report: N New Comment: Note that the error doesn't occur with php-5.4.15 Previous Comments: [2013-05-14 17:00:59] romain at quarkstudio dot fr Description: When executing the configure script, I get a fatal error during the check whether build with IMAP works. c-client : 2007f openssl : 1.0.1e Test script: --- ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --enable-fast-install --libdir=/usr/lib64 --libdir=/usr/share/php --localstatedir=/var --enable-bcmath --enable-calendar --enable-cli --enable-ctype --enable-dba --enable-flatfile --enable-hash --enable-inifile --enable-intl --enable-json --enable-magic-quotes --enable-mbstring --enable-mbregex --enable-mbregex-backtrack --enable-pcntl --enable-phar --enable-posix --enable-session --enable-shmop --enable-sockets --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-tokenizer --enable-zend-multibyte --enable-zip --disable-embed --disable-embedded-mysqli --disable-safe-mode --with-bz2 --with-config-file-path=/etc/php --with-config-file-scan-dir=/etc/php --with-exec-dir=/usr/bin --with-gettext --with-gmp --with-iconv --with-icu-dir=/usr --with-layout=GNU --with-zlib --with-zlib-dir=/usr --without-adabas --without-aolserver --without-apache-hooks --without-apache-hooks-static --without-apxs --without-birdstep --without-caudium --without-cdb --without-continuity --without-custom-odbc --without-dbmaker --without-empress --without-empress-bcs --without-enchant --without-esoob --without-mhash --without-ibm-db2 --without-interbase --without-iodbc --without-isapi --without-milter --without-mm --without-ndbm --without-nsapi --without-ODBCRouter --without-oci8 --without-pdo-firebird --without-pdo-oci --without-phttpd --without-pi3web --without-qdbm --without-roxen --without-sapdb --without-snmp --without-solid --without-sybase-ct --without-thttpd --without-tux --without-webjames --disable-debug --enable-fpm --enable-ipv6 --enable-exif --enable-fileinfo --enable-filter --enable-ftp --enable-gd-native-ttf --enable-sqlite-utf8 --enable-dom --enable-libxml --enable-simplexml --enable-soap --enable-wddx --enable-xml --enable-xmlreader --enable-xmlwriter --without-apxs2 --with-pear --with-curl --without-curlwrappers --without-db4 --with-gd=/usr --with-jpeg-dir=/usr --with-freetype-dir=/usr --with-png-dir=/usr --with-t1lib=/usr --with-xpm-dir=/usr --with-imap --without-gdbm --without-kerberos --without-ldap --without-ldap-sasl --without-libedit --with-mcrypt --without-mssql --without-mysql --without-mysql-sock --with-mysqli=mysqlnd --with-mysql-sock=/run/mysqld/mysqld.sock --with-pcre-dir=/usr --with-pcre-regex=/usr --with-pdo-mysql=mysqlnd --with-mysql-sock=/run/mysqld/mysqld.sock --without-pdo-dblib --without-pdo-odbc --with-pdo-pgsql=/usr --with-pdo-sqlite=/usr --with-sqlite3=/usr --with-pgsql=/usr --without-pspell --without-readline --without-recode --with-imap-ssl --with-openssl --without-tidy --without-unixODBC --without-xmlrpc --without-xsl Expected result: (Configure script successfully executed) Actual result: -- checking whether build with IMAP works... no configure: error: build test failed. Please check the config.log for details. The relevant part in the config.log : configure:51119: checking whether build with IMAP works configure:51163: x86_64-pc-linux-gnu-gcc -o conftest -I/usr/include - march=native -pipe -O2 -L/usr/lib conftest.c -lc-client -lcrypt -lpam -lgmp -lgd -lt1 -lfreetype -lX11 -lXpm -lpng -lz -ljpeg -lcurl -lbz2 -lz -lsqlite3 - lpcre -lrt -lm -ldl -lnsl -lxml2 -lz -lm -ldl -lcurl -lxml2 -lz -lm -ldl 15 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libc-client.a(osdep.o): undefined reference to symbol 'SSL_state' /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: note: 'SSL_state' is defined in DSO /usr/lib64/libssl.so.1.0.0 so try adding it to the linker command line /usr/lib64/libssl.so.1.0.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status -- Edit this bug report at
Bug #64836 [Fbk-Asn]: segfault in softmagic.c
Edit report at https://bugs.php.net/bug.php?id=64836edit=1
ID: 64836
User updated by:r dot biegel at gmx dot at
Reported by:r dot biegel at gmx dot at
Summary:segfault in softmagic.c
-Status: Feedback
+Status: Assigned
Type: Bug
Package:Unknown/Other Function
Operating System: Gentoo Linux
PHP Version:5.4.15
Assigned To:ab
Block user comment: N
Private report: N
New Comment:
OK, in short: I can't reproduce the segfault behaviour anymore.
Longer version:
- updated kernel from gentoo-hardened 3.8.12 to 3.9.2
- updated gcc to 4.7.3
- compiled php 5.4.13 and 5.4.14 and both work fine
- compiled php 5.4.15 again which now works fine too
- downgraded kernel and gcc to previous versions
- compiled php 5.4.15, still works
I just don't get it... I already had re-compiled php and apache before
reporting as bug.
With -D SVN I meant the startup-arguments for apache on the command line.
Don't know if this is Gentoo specific, but it controls the loading of the svn
DAV module.
At last I'd like to link these two bugs on gentoo bugzilla, which might be
related:
https://bugs.gentoo.org/show_bug.cgi?id=467756
https://bugs.gentoo.org/show_bug.cgi?id=470828
Thanks for your help!
Previous Comments:
[2013-05-21 08:00:47] a...@php.net
I've just compiled apache 2.4 with subversion 1.7.x module plus PHP-5.5, TS
build. But it still doesn't crash for me. Note that the libmagic is the same in
5.4 and 5.5 and was upgraded in 5.4.15 and 5.5.0 beta4.
To diagnose it further, is it possible you to check if the behavior is the same
with the earlier php versions? May be 5.4.14 or 5.5.0 beta3. Also i think this
behaviour is TS specific, svn might be even not the cause, too.
btw what do you mean not using -D SVN? As i've experienced the mod_dav_svn.so
has to be built from the subversion sources and is not contained in the apache
source tree.
Thanks.
[2013-05-19 15:31:46] r dot biegel at gmx dot at
I used this little script to test the finfo_file function on its own. Crashes
in apache (if the file $fn exists, filetype doesn't matter), but it works on
cli:
?php
$finfo = finfo_open();
$fn = index.html;
echo File .$fn. is of type .finfo_file($finfo,$fn);
finfo_close($finfo);
?
So it has something to do with apache i thought and it turned out that
disabling SVN DAV in apache (not using -D SVN) fixes the problem. How can I
investigate further? Btw, I already upgraded from apache 2.2 to 2.4 before my
first report.
Here another (more detailed) bt:
Thread 28 (Thread 0x7fffd9feb700 (LWP 24821)):
#0 0x7fffeeec2e6b in mget (ms=0x7fffd411c5f0, s=0x7fffd8896030 GIF89a,
m=0x7fffd8a69268, nbytes=1218, o=0, cont_level=0, mode=32, text=0, flip=0,
recursion_level=1, printed_something=0x7fffd9fe7dd4,
need_separator=0x7fffd9fe7dd8, returnval=0x7fffd9fe7d24)
at ext/fileinfo/libmagic/softmagic.c:1610
off = 0
soffset = 410814606
offset = 0
count = 0
rv = -207172457
oneed_separator = 994741513
sbuf = 0x5cb76acd3615aac9 Address 0x5cb76acd3615aac9 out of bounds
rbuf = 0x8efc10f4e7cb6d6d Address 0x8efc10f4e7cb6d6d out of bounds
p = 0x7fffd411c660
ml = {magic = 0x180ffedff931d7c7, nmagic = 1473718312, map =
0xd8c865c8, next = 0x7fffd411c5f0, prev = 0x1a09a2a9d9c97089}
#1 0x7fffeeebede8 in match (ms=0x7fffd411c5f0, magic=0x7fffd89170e8,
nmagic=9629, s=0x7fffd8896030 GIF89a, nbytes=1218, offset=0, mode=32, text=0,
flip=0, recursion_level=0, printed_something=0x7fffd9fe7dd4,
need_separator=0x7fffd9fe7dd8, returnval=0x7fffd9fe7d24)
at ext/fileinfo/libmagic/softmagic.c:157
flush = 0
m = 0x7fffd8a69268
magindex = 5584
cont_level = 0
returnvalv = 0
e = -647236122
firstline = 1
print = 0
#2 0x7fffeeebeb19 in file_softmagic (ms=0x7fffd411c5f0, buf=0x7fffd8896030
GIF89a, nbytes=1218, mode=32, text=0)
at ext/fileinfo/libmagic/softmagic.c:82
ml = 0x7fffd40efb50
rv = 32767
printed_something = 0
need_separator = 0
#3 0x7fffeeebc3a5 in file_buffer (ms=0x7fffd411c5f0,
stream=0x7fffd8d70388, inname=0x0, buf=0x7fffd8896030, nb=1218)
at ext/fileinfo/libmagic/funcs.c:238
m = 0
rv = 0
looks_text = 0
mime = 16
ubuf = 0x7fffd8896030 GIF89a
u8buf = 0x7fffd4255aa0
ulen = 3
code = 0x0
code_mime = 0x7fffef6f618f binary
type = 0x7fffef6f5f84 binary
#4 0x7fffeeebd698 in file_or_stream (ms=0x7fffd411c5f0, inname=0x0,
stream=0x7fffd8d70388)
at ext/fileinfo/libmagic/magic.c:413
rv = -1
buf = 0x7fffd8896030 GIF89a
sb = {st_dev = 2058, st_ino = 105911862, st_nlink
Bug #61558 [Com]: Runaway spawning of children after pipe error
Edit report at https://bugs.php.net/bug.php?id=61558edit=1
ID: 61558
Comment by: pavel at stack dot ee
Reported by:phpbug2012 at tgabber dot mine dot nu
Summary:Runaway spawning of children after pipe error
Status: Assigned
Type: Bug
Package:FPM related
Operating System: Debian Linux
PHP Version:5.3.10
Assigned To:fat
Block user comment: N
Private report: N
New Comment:
PHP 5.3.23 with Suhosin-Patch (cli) (built: Mar 26 2013 14:07:09)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies
FPM POOL CONFIG:
[storage]
listen = /tmp/fpm_storage.sock
listen.owner = storage
listen.group = storage
listen.mode = 0666
user = storage
group = storage
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 35
NGINX:
location ~ \.php$ {
fastcgi_pass unix:/tmp/fpm_storage.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param DEVENV on;
fastcgi_intercept_errors on;
fastcgi_ignore_client_abortoff;
fastcgi_connect_timeout60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
}
~/.ssh/config:
Host *
ConnectTimeout 2
TCPKeepAlive yes
Port 22
Identityfile ~/.ssh/server1000
ControlMaster no
ControlPath ~/.ssh/master-%r@%h:%p
Host server1000
Hostname 192.168.2.2
Creating connection to remote server:
# ssh -o ServerAliveInterval 15 -o ServerAliveCountMax 1 -MN user@server1000
# ls -la ~/.ssh/
srw--- 1 storage storage0 Mar 26 15:46 master-root@192.168.2.2:22
# ssh server1000 whoami
root
and this simple script for which was run from browser and i'm getting same
behaviour in Debian and FreeBSD
?php
for ($i = 0; $i 100; ++$i) {
echo exec(ssh root@192.168.2.2 ls -la);
}
?
[26-Mar-2013 15:57:00] NOTICE: configuration file /etc/php5/fpm/php-fpm.conf
test is successful
[26-Mar-2013 15:57:00] NOTICE: fpm is running, pid 20053
[26-Mar-2013 15:57:00] NOTICE: ready to handle connections
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20054 exited with code 0
after 92.745193 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20324 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20324 exited with code 0
after 0.005245 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20325 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20325 exited with code 0
after 0.005121 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20326 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20326 exited with code 0
after 0.005202 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20327 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20327 exited with code 0
after 0.005543 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20328 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20328 exited with code 0
after 0.004935 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20329 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20329 exited with code 0
after 0.005255 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20330 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20330 exited with code 0
after 0.005239 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20331 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20331 exited with code 0
after 0.005134 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20332 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20332 exited with code 0
after 0.005162 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20333 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20333 exited with code 0
after 0.004950 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20334 started
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20334 exited with code 0
after 0.005066 seconds from start
[26-Mar-2013 15:58:33] NOTICE: [pool storage] child 20335 started
Previous Comments:
[2012-10-25 13:57:40] adrian dot siminiceanu at gmail dot com
Hello,
I have the same behavior on my test machine using Red Hat Enterprise Linux
Server release 5.3 (Tikanga) Update 3 using the following:
- nginx-1.2.4-1.ngx.x86_64
- php-fpm-5.3.10-2.x86_64 (built from the github php-src tag 5.1.30 -
https://github.com/php/php-src/tree/php-5.3.10)
The php-fpm configuration is the following:
[PHP-BUG] Bug #64910 [NEW]: Line number of $e = new Exception vs. line number of throw $e
From: sebastian
Operating system: Irrelevant
PHP version: 5.5Git-2013-05-23 (Git)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Line number of $e = new Exception vs. line number of throw $e
Description:
The error message that is created for an uncaught exception as well as the
stacktrace of an exception list the number of the line on which the
exception object was created. I would expect this to be number of the line
on which the exception is raised using the throw statement.
Also note that the documentation on this is inconsistent: the
Exception::getLine() method is documented with Gets the line in which the
exception occurred whereas the Exception::$line attribute is documented
with The line where the exception was created.
Test script:
---
?php
$e = new Exception;
throw $e;
Expected result:
Fatal error: Uncaught exception 'Exception' in /home/sb/test.php:3
Stack trace:
#0 {main}
thrown in /home/sb/test.php on line 3
Actual result:
--
Fatal error: Uncaught exception 'Exception' in /home/sb/test.php:2
Stack trace:
#0 {main}
thrown in /home/sb/test.php on line 2
--
Edit bug report at https://bugs.php.net/bug.php?id=64910edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64910r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64910r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64910r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64910r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64910r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64910r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64910r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64910r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64910r=support
Expected behavior: https://bugs.php.net/fix.php?id=64910r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64910r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64910r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64910r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64910r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64910r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64910r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64910r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64910r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64910r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64910r=mysqlcfg
Bug #64910 [Opn]: Line number of $e = new Exception vs. line number of throw $e
Edit report at https://bugs.php.net/bug.php?id=64910edit=1
ID: 64910
Updated by: der...@php.net
Reported by:sebast...@php.net
Summary:Line number of $e = new Exception vs. line number of
throw $e
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.5Git-2013-05-23 (Git)
Block user comment: N
Private report: N
New Comment:
I'd agree with this. Seems like a fix could be to update the file and line
properties of the exception in
zend_throw_exception_internal/zend_throw_exception. Right now, it's set in the
object init of the Exception class only.
Previous Comments:
[2013-05-23 16:07:15] sebast...@php.net
Description:
The error message that is created for an uncaught exception as well as the
stacktrace of an exception list the number of the line on which the exception
object was created. I would expect this to be number of the line on which the
exception is raised using the throw statement.
Also note that the documentation on this is inconsistent: the
Exception::getLine() method is documented with Gets the line in which the
exception occurred whereas the Exception::$line attribute is documented with
The line where the exception was created.
Test script:
---
?php
$e = new Exception;
throw $e;
Expected result:
Fatal error: Uncaught exception 'Exception' in /home/sb/test.php:3
Stack trace:
#0 {main}
thrown in /home/sb/test.php on line 3
Actual result:
--
Fatal error: Uncaught exception 'Exception' in /home/sb/test.php:2
Stack trace:
#0 {main}
thrown in /home/sb/test.php on line 2
--
Edit this bug report at https://bugs.php.net/bug.php?id=64910edit=1
Bug #64908 [Opn-Nab]: DateTime's constructor accepts time that not exists because of DST
Edit report at https://bugs.php.net/bug.php?id=64908edit=1
ID: 64908
Updated by: der...@php.net
Reported by:istvan dot dani at gmail dot com
Summary:DateTime's constructor accepts time that not exists
because of DST
-Status: Open
+Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: OS X 10.8
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
PHP's date time handling auto-corrects wrong date/time values. This is similar
to doing:
?php
$n = new DateTime(2013-04-31);
var_dump( $n );
?
class DateTime#1 (3) {
public $date =
string(19) 2013-05-01 00:00:00
public $timezone_type =
int(3)
public $timezone =
string(13) Europe/London
}
Previous Comments:
[2013-05-23 08:30:06] istvan dot dani at gmail dot com
Description:
Europe/Budapest timezone offset is +1, and +2 in DST.
Transition to DST is at 2013-03-31 01:00:00 UTC/GMT.
According to this, locale time should not exists between 02:00:00 and 03:00:00,
and must not be accepted as valid time.
Test script:
---
try {
$wrong_date = new DateTime(2013-03-31 02:30:00, new
DateTimeZone(Europe/Budapest));
} catch (Exception $e) {
echo $e-getMessage();
}
print Wrong date in local timezone: . $wrong_date-format(Y-m-d H:i:s);
$wrong_date-setTimezone(new DateTimeZone(UTC));
print br /Converting to UTC: . $wrong_date-format(Y-m-d H:i:s);
$wrong_date-setTimezone(new DateTimeZone(Europe/Budapest));
print br /Converting back to locale timezone: . $wrong_date-format(Y-m-d
H:i:s);
Expected result:
Get an exception.
Actual result:
--
Wrong date in local timezone: 2013-03-31 02:30:00
Converting to UTC: 2013-03-31 01:30:00
Converting back to locale timezone: 2013-03-31 03:30:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=64908edit=1
[PHP-BUG] Bug #64912 [NEW]: Unexpected output when parsing PHP files containing NUL characters
From: alexander dot stehlik at gmail dot com Operating system: Linux (Ubuntu and CentOS) PHP version: 5.4.15 Package: mbstring related Bug Type: Bug Bug description:Unexpected output when parsing PHP files containing NUL characters Description: When this setting is used: zend.multibyte = On and I parse a PHP file that contains a NUL character (this one here: http://en.wikipedia.org/wiki/Null_character) I get some weird output. When I do not use the mbstring.internal_encoding setting I get a lot of question marks (?). When I use mbstring.internal_encoding = utf-8 I get some characters that look like Chinese to me. Test script: --- ?php // I can not insert the NUL character here. // To put it in a PHP file you can use the console: // // echo -e here is \0 null test.php $var = 'here is InsertNULCharacterHere null'; ? Expected result: When I run the given example with php test.php I expect no output, even when this setting is active: zend.multibyte = On Actual result: -- With the setting zend.multibyte = On I get some weird output (depending on the configured internal encoding): With the setting mbstring.internal_encoding = utf-8 I get an output that looks like this: ã°¿ç¨çâ¶æ ²â½â§æ¡¥ç©â³æ¤ 湵汬â»à¨¿ã¸ Without the setting the output looks like this: ??? ? -- Edit bug report at https://bugs.php.net/bug.php?id=64912edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64912r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64912r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64912r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64912r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64912r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64912r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64912r=needscript Try newer version: https://bugs.php.net/fix.php?id=64912r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64912r=support Expected behavior: https://bugs.php.net/fix.php?id=64912r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64912r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64912r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64912r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64912r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64912r=dst IIS Stability: https://bugs.php.net/fix.php?id=64912r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64912r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64912r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64912r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64912r=mysqlcfg
Bug #64908 [Nab]: DateTime's constructor accepts time that not exists because of DST
Edit report at https://bugs.php.net/bug.php?id=64908edit=1
ID: 64908
User updated by:istvan dot dani at gmail dot com
Reported by:istvan dot dani at gmail dot com
Summary:DateTime's constructor accepts time that not exists
because of DST
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: OS X 10.8
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Yep. Manual at http://hu1.php.net/manual/en/datetime.construct.php says:
If an invalid date is specified, then an exception is now thrown. Previously
an
error was emitted.
Previous Comments:
[2013-05-23 17:22:23] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
PHP's date time handling auto-corrects wrong date/time values. This is similar
to doing:
?php
$n = new DateTime(2013-04-31);
var_dump( $n );
?
class DateTime#1 (3) {
public $date =
string(19) 2013-05-01 00:00:00
public $timezone_type =
int(3)
public $timezone =
string(13) Europe/London
}
[2013-05-23 08:30:06] istvan dot dani at gmail dot com
Description:
Europe/Budapest timezone offset is +1, and +2 in DST.
Transition to DST is at 2013-03-31 01:00:00 UTC/GMT.
According to this, locale time should not exists between 02:00:00 and 03:00:00,
and must not be accepted as valid time.
Test script:
---
try {
$wrong_date = new DateTime(2013-03-31 02:30:00, new
DateTimeZone(Europe/Budapest));
} catch (Exception $e) {
echo $e-getMessage();
}
print Wrong date in local timezone: . $wrong_date-format(Y-m-d H:i:s);
$wrong_date-setTimezone(new DateTimeZone(UTC));
print br /Converting to UTC: . $wrong_date-format(Y-m-d H:i:s);
$wrong_date-setTimezone(new DateTimeZone(Europe/Budapest));
print br /Converting back to locale timezone: . $wrong_date-format(Y-m-d
H:i:s);
Expected result:
Get an exception.
Actual result:
--
Wrong date in local timezone: 2013-03-31 02:30:00
Converting to UTC: 2013-03-31 01:30:00
Converting back to locale timezone: 2013-03-31 03:30:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=64908edit=1
Sec Bug-Bug #64911 [Opn]: Looped forward_static_call causes segfault
Edit report at https://bugs.php.net/bug.php?id=64911edit=1 ID: 64911 Updated by: s...@php.net Reported by:jutaky at ee dot oulu dot fi Summary:Looped forward_static_call causes segfault Status: Open -Type: Security +Type: Bug Package:Reproducible crash Operating System: ArchLinux PHP Version:5.4.15 Block user comment: N Private report: Y New Comment: Does not seem to be a security issue. Previous Comments: [2013-05-23 17:13:45] jutaky at ee dot oulu dot fi Description: Looped forward_static_call causes segfault on PHP 5.4.15, 5.5.0RC2 and on trunk (20130523). Configure for PHP 5.5.0RC2 and trunk: ./configure --enable-debug Worth noting: xdebug extension prevented crash and exited PHP cleanly. Backtrace is extremely long, here are ten first entries: #0 0x007896d1 in _zend_mm_alloc_int (heap=error reading variable: Cannot access memory at address 0x7f7fefe8, size=error reading variable: Cannot access memory at address 0x7f7fefe0, __zend_filename=error reading variable: Cannot access memory at address 0x7f7fefd8, __zend_lineno=error reading variable: Cannot access memory at address 0x7f7fefd4, __zend_orig_filename=error reading variable: Cannot access memory at address 0x7f7fefc8, __zend_orig_lineno=error reading variable: Cannot access memory at address 0x7f7fefd0) at removed/Zend/zend_alloc.c:1881 #1 0x0078b3f3 in _emalloc (size=4, __zend_filename=0xbd7e38 removed/Zend/zend_operators.c, __zend_lineno=1979, __zend_orig_filename=0x0, __zend_orig_lineno=0) at removed/Zend/zend_alloc.c:2429 #2 0x007bec56 in zend_str_tolower_dup (source=0x77e95ac0 foo::bar, length=3) at removed/Zend/zend_operators.c:1979 #3 0x007ce357 in zend_is_callable_check_class (name=0x77e95ac0 foo::bar, name_len=3, fcc=0x7f7ff720, strict_class=0x7f7ff168, error=0x7f7ff368) at removed/Zend/zend_API.c:2673 #4 0x007cea6e in zend_is_callable_check_func (check_flags=0, callable=0x75b4dbc8, fcc=0x7f7ff720, strict_class=0, error=0x7f7ff368) at removed/Zend/zend_API.c:2795 #5 0x007cfc75 in zend_is_callable_ex (callable=0x75b4dbc8, object_ptr=0x0, check_flags=0, callable_name=0x0, callable_name_len=0x7f7ff294, fcc=0x7f7ff720, error=0x7f7ff368) at removed/Zend/zend_API.c:3059 #6 0x007d0710 in zend_fcall_info_init (callable=0x75b4dbc8, check_flags=0, fci=0x7f7ff750, fcc=0x7f7ff720, callable_name=0x0, error=0x7f7ff368) at removed/Zend/zend_API.c:3235 #7 0x007c6d89 in zend_parse_arg_impl (arg_num=1, arg=0x75bab758, va=0x7f7ff610, spec=0x7f7ff540, error=0x7f7ff4e8, severity=0x7f7ff4e4) at removed/Zend/zend_API.c:632 #8 0x007c7061 in zend_parse_arg (arg_num=1, arg=0x75bab758, va=0x7f7ff610, spec=0x7f7ff540, quiet=0) at removed/Zend/zend_API.c:691 #9 0x007c787c in zend_parse_va_args (num_args=0, type_spec=0xbaabcb f*, va=0x7f7ff610, flags=0) at removed/Zend/zend_API.c:873 #10 0x007c7b4f in zend_parse_parameters (num_args=1, type_spec=0xbaabcb f*) at removed/Zend/zend_API.c:924 Test script: --- Example case: http://jutaky.com/fuzzing/loopz.html Expected result: Possibly looping until killed, reaching max_execution_time or other PHP set limit is reached? Actual result: -- Segmentation fault. -- Edit this bug report at https://bugs.php.net/bug.php?id=64911edit=1
Bug #64882 [Opn-Fbk]: 'Could not open input file' error message goes to STDOUT
Edit report at https://bugs.php.net/bug.php?id=64882edit=1 ID: 64882 Updated by: ahar...@php.net Reported by:weirdan at gmail dot com Summary:'Could not open input file' error message goes to STDOUT -Status: Open +Status: Feedback Type: Bug Package:CGI/CLI related Operating System: Debian GNU/Linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: This is controlled by the display_errors and error_log configuration variables: what do you get on each version if you run php -i | egrep '(display_errors|error_log)' ? For example, I get: adamh@swiftdesk7:/tmp$ php -i | egrep '(display_errors|error_log)' display_errors = STDOUT = STDOUT error_log = no value = no value And as you'd expect, errors are output to stdout. Previous Comments: [2013-05-20 14:13:49] weirdan at gmail dot com Those folders contain vanilla PHP code, with NO Debian patches applied. [2013-05-20 14:08:21] weirdan at gmail dot com Description: Error messages in CLI should go to STDERR. This was the case with 5.3.x, but it doesn't seem to be the case with 5.4.* Test script: --- #!/bin/bash for dir in `ls -d php-5*|grep -v tar`; do echo -n $dir: ; # the following line should output nothing $dir/sapi/cli/php -n $(tempfile).php 2/dev/null; echo; done Expected result: php-5.3.25: php-5.4.0: php-5.4.15: php-5.4.7: Actual result: -- php-5.3.25: php-5.4.0: Could not open input file: /tmp/filelm8WcG.php php-5.4.15: Could not open input file: /tmp/filehmMkOG.php php-5.4.7: Could not open input file: /tmp/fileSfJZ4E.php -- Edit this bug report at https://bugs.php.net/bug.php?id=64882edit=1
Bug #64891 [Nab-ReO]: POST values in Google Chrome XHR.
Edit report at https://bugs.php.net/bug.php?id=64891edit=1
ID: 64891
Updated by: ahar...@php.net
Reported by:marc at kryn dot org
Summary:POST values in Google Chrome XHR.
-Status: Not a bug
+Status: Re-Opened
Type: Bug
Package:Built-in web server
Operating System: OS X 10.8.2
PHP Version:5.4.15
Block user comment: N
Private report: N
New Comment:
Really, whatever the spec says, Apache and lighttpd both deal OK with this, so
it would be nice if the CLI server did too.
Previous Comments:
[2013-05-21 23:56:31] marc at kryn dot org
First of all: You've copypasted a not existing paragraph/mixed sentences
to a complete new paragraph. Your quote does not exist in that RFC!
The correct one is:
Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean recipient should guess.
Senders wishing to defeat this behavior MAY include a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when
it is known that it will not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have
a provision to guess a charset MUST use the charset from the
content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document. See
section 3.7.1.
And here again: it says 'MAY' and 'SHOULD', and not 'MUST',
thus the charset is optional (MAY) and max recommended (SHOULD)
IF we know the charset. All as already mentioned in
http://tools.ietf.org/html/rfc2616#section-3.7.
The only sentence with a MUST ...
and those user agents that have
a provision to guess a charset MUST use the charset from the
content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document.
... is not important here, since it's about the Response header.
We're talking about the opposite.
And here is what PHP should probably do:
http://tools.ietf.org/html/rfc2616#section-3.7.1
When no explicit charset
parameter is provided by the sender, media subtypes of the text
type are defined to have a default charset value of ISO-8859-1 when
received via HTTP.
I know now that other browsers add the Charset part to the Content-Type,
but that's however not important, since it's not a MUST regarding the RFC.
The PHP built-in web server should handle also requests without a charset
and assume that the text body of request without a defined charset is a
ISO-8859-1.
The strange behaviour is that PHP _does_ parse the Request infrequently
correct, but mostly not.
[2013-05-21 22:59:47] google...@php.net
Well, first of all you're linking to the wrong part of the RFC when you're
referring
to the character encoding of the HTTP request header. There is undefined
behavior
according to the spec and you can see that here
http://tools.ietf.org/html/rfc2616#section-3.4.1
where it clearly says:
Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean recipient should guess.
Senders wishing to defeat this behavior MAY include a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when
it is known that it will not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have
a provision to guess a charset MUST use the charset from the
Content coding values indicate an encoding transformation that has
been or can be applied to an entity. Content codings are primarily
used to allow a document to be compressed or otherwise usefully
transformed without losing the identity of its underlying media type
and without loss of information. Frequently, the entity is stored in
coded form, transmitted directly, and only decoded by the recipient.
So with that said if I go ahead and add the charset to the request header in
your
script I get the expected result.
?php
if (isset($_GET['test'])) {
echo 'received values: br/';
var_dump($_POST);
exit;
}
?
div id=response/div
script
var xhr = new XMLHttpRequest();
xhr.open('POST', '?= $_SERVER['SCRIPT_NAME'] ??test=1', true);
xhr.setRequestHeader(Content-type, application/x-www-form-urlencoded;
charset=UTF-
8);
xhr.onload = function(){ document.getElementById('response').innerHTML =
this.responseText;
Bug #53626 [Ver]: SQLite3 - Segmentation Fault on shutdown
Edit report at https://bugs.php.net/bug.php?id=53626edit=1 ID: 53626 User updated by:bion at drewcrawfordapps dot com Reported by:bion at drewcrawfordapps dot com Summary:SQLite3 - Segmentation Fault on shutdown Status: Verified Type: Bug Package:Reproducible crash Operating System: Mac OS X 10.7.1 -PHP Version:5.3.8 +PHP Version:5.5.0RC2 Block user comment: N Private report: N New Comment: This continues to haunt me Previous Comments: [2012-04-23 17:11:55] bugman at mailinator dot com I was having the same problem. Apparently it is due to the sqlite3 extension being threaded, but php not being compiled with the pthread library. I was able to fix it in FreeBSD by recompiling php with the following option: LINKTHRLink thread lib (for threaded extensions) [2011-12-02 12:12:08] sb at litepc dot com Additional Info: reducing extensions.ini to only sqlite3.so (no other modules loaded) also gave the Segmentation fault when executing /usr/local/bin/php-cgi -v [2011-12-02 08:33:23] sb at litepc dot com I get a segfault whenever php-cgi exits even without using sqlite functions. FreeBSD. Latest Ports as of 1/12/2011 php5-5.3.8 php5-pdo_sqlite-5.3.8 php5-sqlite-5.3.8 php5-sqlite3-5.3.8 sqlite3-3.7.9 # /usr/local/bin/php-cgi -v PHP 5.3.8 with Suhosin-Patch (cgi-fcgi) (built: Dec 1 2011 22:33:51) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies Segmentation fault # Editing extensions.ini to comment out sqlite3.so *and* pdo_sqlite.so eliminates the Segmentation fault error. With respect to: This is due the destructor order. I have tried many permutations of ordering in extensions.ini but found no case where enabling sqlite3.so or pdo_sqlite.so worked in any position. Can not recompile with debug yet as this is a production machine... but will attempt to reproduce in test scenario and update. [2011-09-23 04:55:13] bion at drewcrawfordapps dot com This bug is still reproducible, and in fact has regressed, since I no longer get a helpful console error message, but a generic crash report. What are the chances of getting this fixed? [2011-06-05 20:28:48] fel...@php.net This is due the destructor order. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=53626 -- Edit this bug report at https://bugs.php.net/bug.php?id=53626edit=1
Bug #62059 [Com]: ArrayObject and isset are not friends.
Edit report at https://bugs.php.net/bug.php?id=62059edit=1
ID: 62059
Comment by: spneacy at gmail dot com
Reported by:julien at palard dot fr
Summary:ArrayObject and isset are not friends.
Status: Open
Type: Bug
Package:SPL related
Operating System: Linux 2.6.32-5-amd64
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Confirmed in version 5.4.6
When using version 5.4.9, it appears to have been incidentally (or silently)
fixed.
Previous Comments:
[2012-10-23 23:05:33] roberts at x0 dot lv
Confirmed present in 5.3.3-7 and 5.4.7-7, and 5.4.8-1
[2012-05-18 15:22:30] julien at palard dot fr
Description:
The doc state that isset() is not a function, so that it can do weird things
like deep inspection, without raising a NOTICE about 'b' being undefined :
$a = array();
isset($a['b']['c']);
But if $a is an ArrayObject, the deep inspection does not work and a Undefined
index 'b' NOTICE is triggered.
But I found a __isset() in the documentation,
(http://www.php.net/manual/en/language.oop5.overloading.php#object.isset) it
have a very concise documentation but it seems a sufficient convention to make
this work :
I think that isset should call __isset() from left to right returning FALSE at
the 1st non set member, like this :
$a = SomeObject();
isset($a['b']['c']['d']['e']);
should call :
$a-__isset('b'), that should return FALSE, and stop here, wihout NOTICE.
Test script:
---
echo isset on array, work without notice\n;
$array = array();
var_dump(isset($array['a']['b']));
echo isset on arrayobject, should work as ArrayObject implements __isset\n;
$arrayobject = new ArrayObject();
var_dump(isset($arrayobject['a']['b']));
Expected result:
isset on array, work without notice
bool(false)
isset on arrayobject, should work as ArrayObject implements __isset
bool(false)
Actual result:
--
isset on array, work without notice
bool(false)
isset on arrayobject, should work as ArrayObject implements __isset
PHP Notice: Undefined index: a in test.php on line 10
Notice: Undefined index: a in test.php on line 10
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62059edit=1
Bug #64910 [Opn]: Line number of $e = new Exception vs. line number of throw $e
Edit report at https://bugs.php.net/bug.php?id=64910edit=1
ID: 64910
Updated by: s...@php.net
Reported by:sebast...@php.net
Summary:Line number of $e = new Exception vs. line number of
throw $e
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.5Git-2013-05-23 (Git)
Block user comment: N
Private report: N
New Comment:
Consider however this:
try {
//stuff
} catch(Exception $e) {
$logger-log(Oops, exception!);
throw $e;
}
If we update file/line here, we lose original exception information and
file/line in the exception becomes useless. Right now, since 99.99% of
the code does throw new, it is always useful.
So how would you propose to solve this?
Previous Comments:
[2013-05-23 17:20:49] der...@php.net
I'd agree with this. Seems like a fix could be to update the file and line
properties of the exception in
zend_throw_exception_internal/zend_throw_exception. Right now, it's set in the
object init of the Exception class only.
[2013-05-23 16:07:15] sebast...@php.net
Description:
The error message that is created for an uncaught exception as well as the
stacktrace of an exception list the number of the line on which the exception
object was created. I would expect this to be number of the line on which the
exception is raised using the throw statement.
Also note that the documentation on this is inconsistent: the
Exception::getLine() method is documented with Gets the line in which the
exception occurred whereas the Exception::$line attribute is documented with
The line where the exception was created.
Test script:
---
?php
$e = new Exception;
throw $e;
Expected result:
Fatal error: Uncaught exception 'Exception' in /home/sb/test.php:3
Stack trace:
#0 {main}
thrown in /home/sb/test.php on line 3
Actual result:
--
Fatal error: Uncaught exception 'Exception' in /home/sb/test.php:2
Stack trace:
#0 {main}
thrown in /home/sb/test.php on line 2
--
Edit this bug report at https://bugs.php.net/bug.php?id=64910edit=1
Bug #64910 [Com]: Line number of $e = new Exception vs. line number of throw $e
Edit report at https://bugs.php.net/bug.php?id=64910edit=1
ID: 64910
Comment by: thes...@php.net
Reported by:sebast...@php.net
Summary:Line number of $e = new Exception vs. line number of
throw $e
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.5Git-2013-05-23 (Git)
Block user comment: N
Private report: N
New Comment:
Why would instantiating set a line/file info to begin with? I cannot come up
with any usecase where I'd expect to get meaningful values from getLine() and
getFile() merely upon instantiating an exception.
If neither would be set upon instantiating though, the first throw could
simply check whether they are still NULL and if so, set them.
That way, there won't be any overriding and imho the expected behavior would be
implemented?
Previous Comments:
[2013-05-23 20:34:28] s...@php.net
Consider however this:
try {
//stuff
} catch(Exception $e) {
$logger-log(Oops, exception!);
throw $e;
}
If we update file/line here, we lose original exception information and
file/line in the exception becomes useless. Right now, since 99.99% of
the code does throw new, it is always useful.
So how would you propose to solve this?
[2013-05-23 17:20:49] der...@php.net
I'd agree with this. Seems like a fix could be to update the file and line
properties of the exception in
zend_throw_exception_internal/zend_throw_exception. Right now, it's set in the
object init of the Exception class only.
[2013-05-23 16:07:15] sebast...@php.net
Description:
The error message that is created for an uncaught exception as well as the
stacktrace of an exception list the number of the line on which the exception
object was created. I would expect this to be number of the line on which the
exception is raised using the throw statement.
Also note that the documentation on this is inconsistent: the
Exception::getLine() method is documented with Gets the line in which the
exception occurred whereas the Exception::$line attribute is documented with
The line where the exception was created.
Test script:
---
?php
$e = new Exception;
throw $e;
Expected result:
Fatal error: Uncaught exception 'Exception' in /home/sb/test.php:3
Stack trace:
#0 {main}
thrown in /home/sb/test.php on line 3
Actual result:
--
Fatal error: Uncaught exception 'Exception' in /home/sb/test.php:2
Stack trace:
#0 {main}
thrown in /home/sb/test.php on line 2
--
Edit this bug report at https://bugs.php.net/bug.php?id=64910edit=1
Bug #64882 [Fbk-Opn]: 'Could not open input file' error message goes to STDOUT
Edit report at https://bugs.php.net/bug.php?id=64882edit=1 ID: 64882 User updated by:weirdan at gmail dot com Reported by:weirdan at gmail dot com Summary:'Could not open input file' error message goes to STDOUT -Status: Feedback +Status: Open Type: Bug Package:CGI/CLI related Operating System: Debian GNU/Linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Even though display_errors is set to STDOUT by default in php 5.3.25: weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -i -n | grep display_errors display_errors = STDOUT = STDOUT (and display_startup_errors are off): weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -i -n | grep display_startup display_startup_errors = Off = Off weirdan@367-dsividov:~/Downloads$ the following weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -n $(tempfile).php 2/dev/null weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -n $(tempfile).php Could not open input file: /tmp/fileLHIKSE.php weirdan@367-dsividov:~/Downloads$ clearly shows that startup errors are actually going to STDERR But even I specify errors should go to STDERR, they go to STDOUT in php = 5.4.0: weirdan@367-dsividov:~/Downloads$ for dir in `ls -d php-5* | grep -v tar`; do echo -n $dir: ; $dir/sapi/cli/php -ddisplay_errors=STDERR - ddisplay_startup_errors=0 -n $(tempfile).php 2/dev/null; echo; done; php-5.3.25: php-5.4.0: Could not open input file: /tmp/filedhceXV.php php-5.4.15: Could not open input file: /tmp/fileUv3FxW.php php-5.4.7: Could not open input file: /tmp/fileBH6TsZ.php weirdan@367-dsividov:~/Downloads$ to me it seems that startup errors started to go to STDOUT (regardless of display_errors and display_startup_errors value) in php-5.4.x and you can't really control it through either display_errors or display_startup_errors: weirdan@367-dsividov:~/Downloads$ php-5.4.0/sapi/cli/php - ddisplay_startup_errors=STDERR -ddisplay_errors=STDERR -i | egrep '(display_errors|display_startup_errors|error_log)' display_errors = STDERR = STDERR display_startup_errors = Off = Off error_log = no value = no value weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php - ddisplay_startup_errors=STDERR -ddisplay_errors=STDERR -i | egrep '(display_errors|display_startup_errors|error_log)' display_errors = STDERR = STDERR display_startup_errors = Off = Off error_log = no value = no value weirdan@367-dsividov:~/Downloads$ php-5.4.0/sapi/cli/php -n - ddisplay_startup_errors=STDERR -ddisplay_errors=STDERR $(tempfile).php 2/dev/null Could not open input file: /tmp/file7laZhC.php weirdan@367-dsividov:~/Downloads$ php-5.3.25/sapi/cli/php -n - ddisplay_startup_errors=STDERR -ddisplay_errors=STDERR $(tempfile).php 2/dev/null weirdan@367-dsividov:~/Downloads$ Previous Comments: [2013-05-23 18:30:40] ahar...@php.net This is controlled by the display_errors and error_log configuration variables: what do you get on each version if you run php -i | egrep '(display_errors|error_log)' ? For example, I get: adamh@swiftdesk7:/tmp$ php -i | egrep '(display_errors|error_log)' display_errors = STDOUT = STDOUT error_log = no value = no value And as you'd expect, errors are output to stdout. [2013-05-20 14:13:49] weirdan at gmail dot com Those folders contain vanilla PHP code, with NO Debian patches applied. [2013-05-20 14:08:21] weirdan at gmail dot com Description: Error messages in CLI should go to STDERR. This was the case with 5.3.x, but it doesn't seem to be the case with 5.4.* Test script: --- #!/bin/bash for dir in `ls -d php-5*|grep -v tar`; do echo -n $dir: ; # the following line should output nothing $dir/sapi/cli/php -n $(tempfile).php 2/dev/null; echo; done Expected result: php-5.3.25: php-5.4.0: php-5.4.15: php-5.4.7: Actual result: -- php-5.3.25: php-5.4.0: Could not open input file: /tmp/filelm8WcG.php php-5.4.15: Could not open input file: /tmp/filehmMkOG.php php-5.4.7: Could not open input file: /tmp/fileSfJZ4E.php -- Edit this bug report at https://bugs.php.net/bug.php?id=64882edit=1
Bug #64896 [Com]: Segfault with gc_collect_cycles using unserialize on certain objects
Edit report at https://bugs.php.net/bug.php?id=64896edit=1 ID: 64896 Comment by: edward dot savage at dodo dot com Reported by:mark dot chong at acquireap dot com Summary:Segfault with gc_collect_cycles using unserialize on certain objects Status: Open Type: Bug Package:Reproducible crash Operating System: ubuntu PHP Version:5.4.15 Block user comment: N Private report: N New Comment: With the given test case I get the segfault as described (Ubuntu 13.04/PHP 5.4.9-4ubuntu2). I found that I could work around it by adding a function like 'usleep(1);' or '$var = 2;' between global and the $bar operation in the destructor. A simple operation like '6^123;', even repeated at length, wasn't enough to avoid the fault. Once the test case was running without crashing I started looking at the array assignment to $bar. I found that printing the result of $bar after the destructor ran showed that the values of $this-_private were lost from the global $bar. Even more information is lost when gc_collect_cycles is executed. It can be shown to only be the values as an assigned multidimensional array will retain its keys. This loss of data and the segfault can be avoided by moving the $bar assignment into a pseudo destructor or by removing the circular reference. However, for the reported case there is definitely a data integrity issue when assigning an array to a global in a __destruct with a circular reference present. I could not repeat this issue with other types of assignment like string and object. Previous Comments: [2013-05-22 08:42:45] mark dot chong at acquireap dot com I have run the test case on 3 different machines which call caused a segfault, bellow is the bt from one of them #0 _zend_mm_free_int (heap=0xe09290, p=0x77e793a8) at /tmp/buildd/php5- 5.4.15/Zend/zend_alloc.c:2100 #1 0x0068d97a in _zval_dtor (zvalue=optimised out) at /tmp/buildd/php5-5.4.15/Zend/zend_variables.h:35 #2 _zval_ptr_dtor (zval_ptr=0x77e779a0) at /tmp/buildd/php5- 5.4.15/Zend/zend_execute_API.c:438 #3 _zval_ptr_dtor (zval_ptr=0x77e779a0) at /tmp/buildd/php5- 5.4.15/Zend/zend_execute_API.c:427 #4 0x006aab38 in zend_hash_destroy (ht=0x77e778e0) at /tmp/buildd/php5-5.4.15/Zend/zend_hash.c:560 #5 0x0069b8fb in _zval_dtor_func (zvalue=0x7fffa5a0) at /tmp/buildd/php5-5.4.15/Zend/zend_variables.c:45 #6 0x00718e7d in zend_assign_to_variable (value=0x77e776d8, variable_ptr_ptr=0x77e40410) at /tmp/buildd/php5- 5.4.15/Zend/zend_execute.c:937 #7 ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (execute_data=0x77e40378) at /tmp/buildd/php5-5.4.15/Zend/zend_vm_execute.h:33084 #8 0x006feaa7 in execute (op_array=0x77e76af0) at /tmp/buildd/php5- 5.4.15/Zend/zend_vm_execute.h:410 #9 0x7400fa81 in xdebug_execute (op_array=0x77e76af0) at /srv/debian_developer/xdebug/xdebug-2.2.1/build-php5/xdebug.c:1391 #10 0x0068f7e0 in zend_call_function (fci=fci@entry=0x7fffa970, fci_cache=0x77e73bb0, fci_cache@entry=0x7fffa940) at /tmp/buildd/php5-5.4.15/Zend/zend_execute_API.c:958 #11 0x006b4115 in zend_call_method (object_pp=object_pp@entry=0x7fffaa28, obj_ce=optimised out, fn_proxy=fn_proxy@entry=0x7fffaa20, function_name=function_name@entry=0xaa42a0 __destruct, function_name_len=function_name_len@entry=10, retval_ptr_ptr=retval_ptr_ptr@entry=0x0, param_count=param_count@entry=0, arg1=arg1@entry=0x0, arg2=arg2@entry=0x0) at /tmp/buildd/php5-5.4.15/Zend/zend_interfaces.c:97 #12 0x006bdfa2 in zend_objects_destroy_object (object=0x77e775b0, handle=optimised out) at /tmp/buildd/php5-5.4.15/Zend/zend_objects.c:123 #13 0x006bbdf9 in gc_collect_cycles () at /tmp/buildd/php5- 5.4.15/Zend/zend_gc.c:816 #14 0x006ad719 in zif_gc_collect_cycles (ht=optimised out, return_value=0x77e75f48, return_value_ptr=optimised out, this_ptr= optimised out, return_value_used=optimised out) at /tmp/buildd/php5- 5.4.15/Zend/zend_builtin_functions.c:361 #15 0x7400fedc in xdebug_execute_internal (current_execute_data=0x77e40060, return_value_used=0) at /srv/debian_developer/xdebug/xdebug-2.2.1/build-php5/xdebug.c:1483 #16 0x00744d49 in zend_do_fcall_common_helper_SPEC (execute_data=0x77e40060) at /tmp/buildd/php5- 5.4.15/Zend/zend_vm_execute.h:645 #17 0x006feaa7 in execute (op_array=0x77e73bb0) at /tmp/buildd/php5- 5.4.15/Zend/zend_vm_execute.h:410 #18 0x7400fa81 in xdebug_execute (op_array=0x77e73bb0) at /srv/debian_developer/xdebug/xdebug-2.2.1/build-php5/xdebug.c:1391 #19 0x0069e0dc in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3) at /tmp/buildd/php5-
Req #54741 [Com]: PHP 6 DEV TEST OK BUT MISSING SOME THINGS
Edit report at https://bugs.php.net/bug.php?id=54741edit=1 ID: 54741 Comment by: michaela-hartnett at allmail dot net Reported by:nuno dot ribeiro at masterd dot pt Summary:PHP 6 DEV TEST OK BUT MISSING SOME THINGS Status: Not a bug Type: Feature/Change Request Package:IIS related Operating System: WIN2008 SERVER PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I almost never leave remarks, but i did some searching and wound up here PHP :: Request #54741 :: PHP 6 DEV TEST OK BUT MISSING SOME THINGS. And I actually do have a couple of questions for you if it's allright. Is it simply me or does it appear like some of these remarks look like written by brain dead folks? :-P And, if you are writing on additional sites, I'd like to follow everything fresh you have to post. Could you list of the complete urls of all your community sites like your Facebook page, twitter feed, or linkedin profile? Previous Comments: [2013-05-24 02:18:29] michaela-hartnett at allmail dot net Related To: Bug #54741 [2011-05-16 01:53:27] nuno dot ribeiro at masterd dot pt YES IS THE DEV VERSION GOT IT SOME TIME NOW BUT NEVER TESTS IT ON WIN 2008, BUT I USE A LOT ON WIN 2003, DID NOT SEE ANY REASON TO CHANGE TO PHP 5. OK , OK . AGAIN THANK YOU [2011-05-16 01:45:19] paj...@php.net There is no php version 6 (there was a plan to release one but it has been abandoned, that's what you use. notice the -dev in the version). Go for trunk if you want to use the edge version. 5.3.6 is the latest release. [2011-05-16 01:22:25] nuno dot ribeiro at masterd dot pt BUT THANK YOU ANYWAY I WILL TAKE A LOOK TO THE LIKS YOU GIVE ME. THANK YOU, BEST REGARDS [2011-05-16 01:11:36] nuno dot ribeiro at masterd dot pt REALY IS THE PHP 6 LOOK PHP Version 6.0.0-dev System Windows NT PTL03-ST-SIS01 6.1 build 7600 Build Date Nov 4 2006 18:23:01 Configure Command cscript /nologo configure.js --enable-snapshot-build --with-gd=shared Server API CGI/FastCGI Virtual Directory Support enabled Configuration File (php.ini) Path C:\PHP_6.0\php.ini PHP API 20050809 PHP Extension 20060613 Zend Extension 320060519 Debug Build no Thread Safety enabled Zend Memory Manager enabled Unicode Support Based on Copyright (C) 2005, International Business Machines Corporation and others. All Rights Reserved. . ICU Version 3.4. IPv6 Support enabled Registered PHP Streams php, file, data, http, ftp, compress.zlib, compress.bzip2, https, ftps Registered Stream Socket Transports tcp, udp, ssl, sslv3, sslv2, tls Registered Stream Filters unicode.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, zlib.*, bzip2.* This program makes use of the Zend Scripting Language Engine: Zend Engine v3.0.0-dev, Copyright (c) 1998-2006 Zend Technologies allow_url_fopen On On allow_url_include Off Off always_populate_raw_post_data Off Off arg_separator.input arg_separator.output asp_tags Off Off auto_append_file no value no value auto_globals_jit On On auto_prepend_file no value no value browscap no value no value default_charset no value no value default_mimetype text/html text/html define_syslog_variables Off Off disable_classes no value no value disable_functions no value no value display_errors Off Off display_startup_errors Off Off doc_root no value no value docref_ext no value no value docref_root no value no value error_append_string no value no value error_log syslog syslog error_prepend_string no value no value error_reporting 8191 8191 expose_php Off Off extension_dir C:\PHP_6.0\ext\ C:\PHP_6.0\ext\ file_uploads On On highlight.bg #FF #FF highlight.comment #FF8000 #FF8000 highlight.default #BB #BB highlight.html #00 #00 highlight.keyword #007700 #007700 highlight.string #DD #DD html_errors On On ignore_repeated_errors Off Off ignore_repeated_source Off Off ignore_user_abort Off Off implicit_flush Off Off include_path C:\PHP_6.0\extras\ C:\PHP_6.0\extras\ log_errors On On log_errors_max_len 1024 1024 mail.force_extra_parameters no value no value max_execution_time 60 60 max_input_time 90 90 open_basedir no value no value
Req #38508 [Com]: Addition of Magic __toArray() function
Edit report at https://bugs.php.net/bug.php?id=38508edit=1 ID: 38508 Comment by: rich dot remer at gmail dot com Reported by:doublecompile at gmail dot com Summary:Addition of Magic __toArray() function Status: Closed Type: Feature/Change Request Package:Feature/Change Request PHP Version:* Block user comment: N Private report: N New Comment: I think the main benefit it offers is the ability to control what happens during a cast operation. Right now, casting simple scalar values or NULL to an array works as expected. While it's possible to cast an object to an array, the semantics of what should happen in this situation are not nearly as clear. This really should be controlled by the class. Previous Comments: [2013-03-07 12:19:14] ante at caan dot si Hi guys. I'm dragging this out from the History. I think this is a great suggestion as I use a lot of object that implement ArrayAccess so doing this $someArray = (array) $obj; that calls $obj-__toArray() would be a GREAT addition to PHP logic. [2012-03-14 18:55:00] erck0006 at gmail dot com // MY APPLICATION'S INTERIM SOLUTION (**UPDATE**) $customers = new Customers(); $customers = $customers-__toArray(); // THIS LINE IS THE **UPDATED** LINE NEEDED IN ORDER TO AVOID TRIGGERING THE FOLLOWING ERROR ON THE FOLLOWING LINE: Only variables should be passed by reference $lastCustomer = array_pop($customers); // SUCCESS echo $lastCustomer-getName(); // prints the last customer's name since the previous line did not fail since I explicitly called a custom method named __toArray() first [2012-03-14 18:37:23] erck0006 at gmail dot com ?php // AS-IS $customers = new Customers(); $lastCustomer = array_pop($customers); // FAIL: array_pop() expects parameter 1 to be array, object given echo $lastCustomer-getName(); // execution never reaches this line // MY APPLICATION'S INTERIM SOLUTION $customers = new Customers(); $lastCustomer = array_pop($customers-__toArray()); // SUCCESS echo $lastCustomer-getName(); // prints the last customer's name since the previous line did not fail since I explicitly called a custom method named __toArray() first // TO-BE $customers = new Customers(); $lastCustomer = array_pop($customers); // SUCCESS echo $lastCustomer-getName(); // prints the last customer's name since array_pop() calls __toArray() internally before failing [2012-02-27 21:27:32] john at john dot com this magic function would be great to have [2011-05-23 23:32:13] spark at limao dot com dot br Because of the magic __toString I was able to write a String class with the same methods as the Java String class. I was trying to write an Array class to map the one in Adobe AS3, but then I came across the lack of __toArray. I don't want a __toArray, or even a toString I want classes with reasonable methods and not lots of functions with no naming rules nor parameter order standard. I know it may sound rude but that's how I feel when I see a language getting so far and still not following any coding convetion. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=38508 -- Edit this bug report at https://bugs.php.net/bug.php?id=38508edit=1
