Bug #55665 [Opn]: Segmentation fault in gc_mark_roots()
Edit report at https://bugs.php.net/bug.php?id=55665&edit=1
ID: 55665
Updated by: s...@php.net
Reported by:mbecc...@php.net
Summary:Segmentation fault in gc_mark_roots()
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: FreeBSD 6.2
PHP Version:5.3SVN-2011-09-10 (SVN)
Block user comment: N
Private report: N
New Comment:
Any updates?
Previous Comments:
[2011-09-29 06:07:17] mbecc...@php.net
Hi Tyrael,
I've switched the test runs to use php 5.3.8 and I got segmentation faults
again. I will try to investigate during the weekend, but generally speaking it
should be possible to trigger some. The most recent core file shows a SIGSEGV
at:
#0 0x0094a10c in zval_scan (pz=0x0)
at /array1/compile/php-src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:450
450 if (GC_ZVAL_GET_COLOR(pz) == GC_GREY) {
[2011-09-27 00:00:03] tyr...@php.net
is it still reproducible with 5.3.8?
[2011-09-10 11:17:29] mbecc...@php.net
Description:
As usual with bugs related to garbage collection, I don't have a short
reproduce code. The segmentation fault happens when running a pretty heavy
integration test and is currently reproducible on PHP 5.3 (tested 5.3.4,
5.3.6RC3, 5.3.8 and PHP_5_3 svn HEAD). Unfortunately garbage collection is a
bit too much for me to be able to make sense of it and debug the issue.
Interestingly enough I couldn't reproduce it on PHP 5.2 or PHP 5.4.
Happens both with gcc 3.4.6 and 4.2.5 with -O0.
SSH Access to the machine is available for anyone interested in investigating.
Actual result:
--
Here is the relevant portion of backtrace and some other gdb commands:
#0 0x0094a060 in gc_mark_roots () at
/array1/compile/php-src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:434
434 if (GC_ZVAL_GET_COLOR(current->u.pz) ==
GC_PURPLE) {
(gdb) bt full
#0 0x0094a060 in gc_mark_roots () at
/array1/compile/php-src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:434
current = (gc_root_buffer *) 0x11121a0
#1 0x0094a90c in gc_collect_cycles () at
/array1/compile/php-src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:664
p = (zval_gc_info *) 0x1e8fbd0
q = (zval_gc_info *) 0x7fffccd8
orig_free_list = (zval_gc_info *) 0x377c42d8edc99ee
orig_next_to_free = (zval_gc_info *) 0x901e88190
count = 0
#2 0x009495c2 in gc_zval_possible_root (zv=0x3e37620) at
/array1/compile/php-src/php/php-src/branches/PHP_5_3/Zend/zend_gc.c:166
newRoot = (gc_root_buffer *) 0x0
#3 0x009bb104 in ZEND_FETCH_DIM_W_SPEC_VAR_CV_HANDLER
(execute_data=0x1390810) at zend_gc.h:183
opline = (zend_op *) 0x1e8fbf8
free_op1 = {var = 0x0}
dim = (zval *) 0x3e37708
container = (zval **) 0x3057850
#4 0x00953c58 in execute (op_array=0x1e8be08) at zend_vm_execute.h:107
ret = 0
execute_data = (zend_execute_data *) 0x1390810
nested = 1 '\001'
original_in_execution = 0 '\0'
...
(gdb) print current->u.pz
$1 = (zval *) 0x3e9fd38
(gdb) print *current->u.pz
Cannot access memory at address 0x3e9fd38
(gdb) frame 4
#4 0x00953c58 in execute (op_array=0x1e8be08) at zend_vm_execute.h:107
107 if ((ret = EX(opline)->handler(execute_data TSRMLS_CC))
> 0) {
(gdb) dump_bt executor_globals.current_execute_data
[0x01390810] addItem()
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container.php:153
[0x013905c0] addItem()
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container.php:108
[0x01390450] createItem()
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container.php:196
[0x01390008] createDirective()
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container/PHPArray.php:113
[0x0138fbc0] _parseArray()
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container/PHPArray.php:111
[0x0138f5a0] _parseArray()
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config/Container/PHPArray.php:75
[0x0138ef48] parseDatasrc()
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/pear/Config.php:197
[0x0138ebd8] parseConfig()
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/OA/Admin/Settings.php:364
[0x0138b9b0] writeConfigArrayToFile()
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/OA/Admin/Settings.php:173
[0x0138b7a0] writeConfigChange()
/usr/local/bamboo/test-home/xml-data/build-dir/RET-TRUNK-PHPBUG/lib/OX/Plugin/PluginManager.php
Bug #62071 [Opn]: CLI Programs Hang Forever
Edit report at https://bugs.php.net/bug.php?id=62071&edit=1
ID: 62071
Updated by: s...@php.net
Reported by:ewilde at bsmdevelopment dot com
Summary:CLI Programs Hang Forever
Status: Open
Type: Bug
-Package:Reproducible crash
+Package:*General Issues
Operating System: CentOS 5.8
PHP Version:5.4.3
Block user comment: N
Private report: N
New Comment:
May you strace the process?
Previous Comments:
[2012-07-08 13:40:11] ewilde at bsmdevelopment dot com
I tried both exit and die.
When I added "exit(1)" to the test program, it still hung.
When I added "die("The end")" to the test program, I saw the string "The end"
but then the program hung after that.
It seems that the hang is in the program exit/cleanup code of PHP, not the
logic of the program itself.
Any other ideas about what you'd like to test?
[2012-05-31 20:19:21] riptide dot tempora at opinehub dot com
Would I wrong in assuming that exit; or die(); would properly kill the program
in your situation?
[2012-05-21 18:57:43] ewilde at bsmdevelopment dot com
Well, that figures. Its way too simple a test to have slipped through your
regression testing.
I have other programs that are more complicated which fail in exactly the same
way. In all cases, absolutely all of the work, whatever it is, gets done to
completion. All that happens is they hang on exit or when the code falls
through the end of the script.
It sounds like one of those exec/wait problems whereby the wait in a mother
task fails to complete when the daughter task, that's doing all of the work,
ends. This could easily be OS-dependent or build-dependent and, hence, hard for
you to reproduce.
If you want to contact me offline about where to look, I'll try to debug the
problem on the test system where its failing.
[2012-05-20 21:55:00] fel...@php.net
I can't reproduce it.
[2012-05-19 14:44:36] ewilde at bsmdevelopment dot com
Description:
Scripts executed under the CLI never end. For example, the following test
script will run as long as you let it, until it is killed. It doesn't appear
to be looping, as it consumes no resources. Rather, it appears to be blocked
waiting for some signal that never happens.
Note that this may explain why the 5.4.3 build cannot be built with
"--enable-phar" and why "make install" hangs forever at the end.
Build parms: ./configure --with-apxs2=/usr/share/httpd-2.4/bin/apxs --with-curl
--with-gd --with-ldap --with-libxml-dir=/usr/local --with-mcrypt
--with-mysql=/usr/local/mysql --with-mysqli=/usr/bin/mysql_config
--with-openssl --with-pspell --with-unixODBC=/usr/local/unixODBC
--enable-bcmath --disable-phar --enable-sockets
Test script:
---
#!/usr/bin/php
fwrite(STDOUT, "This is a test\n");
Expected result:
The CLI program exits.
Actual result:
--
The CLI program never exits.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62071&edit=1
Bug #65000 [Opn]: use after free (double free) caused by emalloc in _zval_copy_ctor_func
Edit report at https://bugs.php.net/bug.php?id=65000&edit=1
ID: 65000
Updated by: s...@php.net
Reported by:s...@php.net
Summary:use after free (double free) caused by emalloc in
_zval_copy_ctor_func
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:5.4.16
Block user comment: N
Private report: N
New Comment:
Are you going to commit this patch?
Previous Comments:
[2013-06-11 12:50:55] larue...@php.net
here is the replay I wrote to security, just for the record:
A fix could be, set the zval type to be NULL, then doing the
estrndup, then set it back to IS_STRING:
@@ -118,10 +118,12 @@ ZEND_API void _zval_copy_ctor_func(zval *zvalue
ZEND_FILE_LINE_DC)
break;
case IS_CONSTANT:
case IS_STRING:
+ZVAL_NULL(zvalue);
CHECK_ZVAL_STRING_REL(zvalue);
if (!IS_INTERNED(zvalue->value.str.val)) {
zvalue->value.str.val = (char *) estrndup_rel(zvalue->value.str.val,
zvalue->value.str.l
en);
}
+ Z_TYPE_P(zvalue) = IS_STRING;
break;
but it definitly will brings performance slow down...
[2013-06-09 16:05:18] s...@php.net
Description:
$ ./php --version
PHP 5.4.16 (cli) (built: Jun 9 2013 17:56:24) (DEBUG)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
---
(gdb) r ~shm/php1.php
Starting program: /home/fuzzphp/php-5.4.16/sapi/cli/php ~shm/php1.php
Fatal error: Allowed memory size of 33554432 bytes exhausted at
/home/fuzzphp/php-5.4.16/Zend/zend_vm_execute.h:27134 (tried to allocate
3001 bytes) in /home/shm/php1.php on line 11
Program received signal SIGSEGV, Segmentation fault.
0x008ebc07 in _zval_dtor_func (zvalue=0x77fdb4d8,
__zend_filename=0xeac8e8 "/home/fuzzphp/php-5.4.16/Zend/zend_execute_API.c",
__zend_lineno=438)
at /home/fuzzphp/php-5.4.16/Zend/zend_variables.c:35
35 CHECK_ZVAL_STRING_REL(zvalue);
(gdb) bt
#0 0x008ebc07 in _zval_dtor_func (zvalue=0x77fdb4d8,
__zend_filename=0xeac8e8 "/home/fuzzphp/php-5.4.16/Zend/zend_execute_API.c",
__zend_lineno=438)
at /home/fuzzphp/php-5.4.16/Zend/zend_variables.c:35
#1 0x008da584 in _zval_dtor (zvalue=0x77fdb4d8,
__zend_filename=0xeac8e8 "/home/fuzzphp/php-5.4.16/Zend/zend_execute_API.c",
__zend_lineno=438)
at /home/fuzzphp/php-5.4.16/Zend/zend_variables.h:35
#2 0x008db528 in _zval_ptr_dtor (zval_ptr=0x77fdcb00,
__zend_filename=0xeae170 "/home/fuzzphp/php-5.4.16/Zend/zend_variables.c",
__zend_lineno=182)
at /home/fuzzphp/php-5.4.16/Zend/zend_execute_API.c:438
#3 0x008ec0c1 in _zval_ptr_dtor_wrapper (zval_ptr=0x77fdcb00) at
/home/fuzzphp/php-5.4.16/Zend/zend_variables.c:182
#4 0x0090046a in zend_hash_apply_deleter (ht=0x116ad88,
p=0x77fdcae8) at /home/fuzzphp/php-5.4.16/Zend/zend_hash.c:650
#5 0x009005fb in zend_hash_graceful_reverse_destroy (ht=0x116ad88) at
/home/fuzzphp/php-5.4.16/Zend/zend_hash.c:687
#6 0x008daed3 in shutdown_executor () at
/home/fuzzphp/php-5.4.16/Zend/zend_execute_API.c:247
#7 0x008edf1e in zend_deactivate () at
/home/fuzzphp/php-5.4.16/Zend/zend.c:938
#8 0x0086438f in php_request_shutdown (dummy=0x0) at
/home/fuzzphp/php-5.4.16/main/main.c:1800
#9 0x00990d12 in do_cli (argc=2, argv=0x7fffe628) at
/home/fuzzphp/php-5.4.16/sapi/cli/php_cli.c:1171
#10 0x00991418 in main (argc=2, argv=0x7fffe628) at
/home/fuzzphp/php-5.4.16/sapi/cli/php_cli.c:1364
-
It seems that _zval_copy_ctor_func can be used to trigger double free/use after
free issue, in case when emalloc pointed here:
http://lxr.php.net/xref/PHP_5_4/Zend/zend_variables.c#123 fails (estrndup calls
emalloc internally). The interpreter runs destroy functions on error (memory
exhastion) which lead to use value.str.val two times. Please see the test
script for details.
I'm not sure how to fix the issue, so I left it for smarter than me. :-)
Test script:
---
https://bugs.php.net/bug.php?id=65000&edit=1
Bug #60704 [Asn->Csd]: unlink() bug with some files path
Edit report at https://bugs.php.net/bug.php?id=60704&edit=1
ID: 60704
Updated by: s...@php.net
Reported by:dean at dacunha dot net
Summary:unlink() bug with some files path
-Status: Assigned
+Status: Closed
Type: Bug
Package:Filesystem function related
Operating System: Linux 3.0.0-14-generic #23-Ubunt
PHP Version:5.3.10
Assigned To: shm
Block user comment: N
Private report: N
New Comment:
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/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2012-02-14 14:14:29] s...@php.net
Automatic comment from SVN on behalf of shm
Revision: http://svn.php.net/viewvc/?view=revision&revision=323213
Log: * fixed bug #60704 unlink() bug with some files path
Reviewed by: rasmus@
[2012-02-12 09:53:36] s...@php.net
The following patch has been added/updated:
Patch Name: themostevilpatchever2.patch
Revision: 1329040416
URL:
https://bugs.php.net/patch-display.php?bug=60704&patch=themostevilpatchever2.patch&revision=1329040416
[2012-02-11 08:32:47] s...@php.net
Attached patch should fix this issue. Will commit if after a review.
[2012-02-11 08:32:04] s...@php.net
The following patch has been added/updated:
Patch Name: themostevilpatchever.patch
Revision: 1328949124
URL:
https://bugs.php.net/patch-display.php?bug=60704&patch=themostevilpatchever.patch&revision=1328949124
[2012-02-06 14:55:40] dean at dacunha dot net
Hi,
I've just tested with php 5.3.10, the bug is still here.
Do you still need me to test with version 5.3.9 ?
Here is the proof:
root@djavanubu:/root#
root@djavanubu:/root# cat b.php
#!/usr/local/bin/php
root@djavanubu:/root#
root@djavanubu:/root# /usr/local/bin/php -v
PHP 5.3.10 (cli) (built: Jan 31 2012 22:48:16)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
root@djavanubu:/root#
root@djavanubu:/root#
root@djavanubu:/root# ./b.php
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /root/b.php on line 7
root@djavanubu:/root#
root@djavanubu:/root# rm "/mnt/M:/NEWBASE/BRASIL/Carlinhos
Brown/Alfagamabetizado - Angel's Robot List.1.2.mp3"
root@djavanubu:/root#
root@djavanubu:/root# strace ./b.php
[...]
lstat("/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3", {st_mode=S_IFREG|0755, st_size=1247232, ...}) = 0
lstat("/mnt/M://BRASIL/Carlinhos Brown", {st_mode=S_IFDIR|0755, st_size=40960,
...}) = 0
lstat("/mnt/M://BRASIL", {st_mode=S_IFDIR|0755, st_size=81920, ...}) = 0
link("/mnt/M://BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3", "/mnt/M:/NEWBASE/BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's
Robot List.1.2.mp3") = 0
unlink("BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot List.mp3") = -1
ENOENT (No such file or directory)
write(1, "\nWarning: unlink(BRASIL/Carlinho"..., 135
Warning: unlink(BRASIL/Carlinhos Brown/Alfagamabetizado - Angel's Robot
List.mp3): No such file or directory in /root/b.php on line 7
) = 135
[...]
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=60704
--
Edit this bug report at https://bugs.php.net/bug.php?id=60704&edit=1
Bug #60337 [Asn->Csd]: bcscale related problem on 64bits platforms
Edit report at https://bugs.php.net/bug.php?id=60337&edit=1 ID: 60337 Updated by: s...@php.net Reported by:s...@php.net Summary:bcscale related problem on 64bits platforms -Status: Assigned +Status: Closed Type: Bug Package:BC math related PHP Version:trunk-SVN-2011-11-19 (SVN) Assigned To: shm Block user comment: N Private report: N New Comment: fixed in svn Previous Comments: [2011-11-19 12:46:32] s...@php.net Automatic comment from SVN on behalf of shm Revision: http://svn.php.net/viewvc/?view=revision&revision=319546 Log: - Fixed bug #60337 bcscale related crashed on 64bits platforms [2011-11-19 12:35:54] s...@php.net Description: bcscale uses long typed variable to store scale passed further to bclib calls. Unfortunately bclib uses int type for scale parameter, thus large long numbers (which uses 8 bytes on 64 bits platforms) could be casted to negative number and cause memory corruption as a result of pointer arithmetic with scale param. Test script: --- Expected result: ALIVE Actual result: -- $ php ^D Segmentation fault: 11 (core dumped) -- Edit this bug report at https://bugs.php.net/bug.php?id=60337&edit=1
