Opened 7 years ago

Closed 11 months ago

#90 closed defect (worksforme)

jpgraph+xcache causes php to segfault

Reported by: renchap Owned by: moo
Priority: critical Milestone: 3.0.4
Component: cacher Version: 1.2-dev
Keywords: Cc: c960657
Application: jpgraph PHP Version: 5.2.1
Other Exts: SAPI: FastCGI
Probability: Blocked By:
Blocking:

Description

forum post here

After a few hours, all my jpgraph scripts segfault (not the scripts that dont use jpgraph).
I have the same bug when using APC, but all is fine with php running as fastcgi whithout any cache module.

Change History (20)

comment:1 Changed 7 years ago by moo

  • Status changed from new to assigned

comment:2 Changed 7 years ago by moo

i need a gdb backtrace

comment:3 follow-up: Changed 7 years ago by renchap

Seems to bug also with php 5.1.6 :

May 2 12:39:56 jaina php-cgi[14900]: segfault at 0000000000000000 rip 000000000063536b rsp 00007fff08862ed0 error 6
May 2 12:39:56 jaina grsec: From 80.201.236.147: signal 11 sent to /usr/lib64/php5/bin/php-cgi[php-cgi:14900] uid/euid:1005/1005 gid/egid:1006/1006, parent /usr/lib64/php5/bin/php-cgi[php-cgi:3008] uid/euid:1005/1005 gid/egid:1006/1006
May 2 12:39:56 jaina php-cgi[8765]: segfault at 0000000000000000 rip 000000000063536b rsp 00007fff08862ed0 error 6
May 2 12:39:56 jaina grsec: From 217.70.85.68: signal 11 sent to /usr/lib64/php5/bin/php-cgi[php-cgi:8765] uid/euid:1005/1005 gid/egid:1006/1006, parent /usr/lib64/php5/bin/php-cgi[php-cgi:3008] uid/euid:1005/1005 gid/egid:1006/1006

/usr/lib64/php5/bin/php-cgi --version
PHP 5.1.6-pl11-gentoo (cgi-fcgi) (built: Apr 30 2007 14:07:06)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

with XCache v1.2.0, Copyright (c) 2005-2006, by mOo

how can i launch the php fcgi process with gdb ? i use spawn-fcgi from lighttpd

comment:4 in reply to: ↑ 3 Changed 7 years ago by renchap

gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3)

Linux jaina.renchap.com 2.6.18.1-grsec-xxxx-grs-ipv6-64 #2 SMP Wed Nov 1 08:56:15 CET 2006 x86_64 Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz GenuineIntel? GNU/Linux

PHP 5.2.1-pl3-gentoo (cgi-fcgi) (built: May 6 2007 10:33:24) (DEBUG)Copyright (c) 1997-2007 The PHP GroupZend? Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with XCache v1.2.0, Copyright (c) 2005-2006, by mOo

when i started php, i got this : http://perso.renchap.com/php.log

i will wait for segfaults, but i dont know if these leaks are due to my scripts or php/xcache

comment:5 follow-up: Changed 7 years ago by renchap

Program terminated with signal 11, Segmentation fault.
#0 0x0000000000771675 in ?? ()
(gdb) bt
#0 0x0000000000771675 in ?? ()
#1 0x0000000000772fcc in ?? ()
#2 0x000000000077463d in _efree ()
#3 0x00000000007830cf in ?? ()
#4 0x0000000000783054 in _zval_ptr_dtor ()
#5 0x0000000000791e26 in _zval_ptr_dtor_wrapper ()
#6 0x00000000007a15b2 in zend_hash_destroy ()
#7 0x0000000000791a7c in _zval_dtor_func ()
#8 0x0000000000782e1d in ?? ()
#9 0x0000000000783036 in _zval_ptr_dtor ()
#10 0x0000000000791e26 in _zval_ptr_dtor_wrapper ()
#11 0x00000000007a15b2 in zend_hash_destroy ()
#12 0x00000000007b5fc4 in zend_object_std_dtor ()
#13 0x00000000007b63c2 in zend_objects_free_object_storage ()
#14 0x00000000007ba362 in zend_objects_store_del_ref_by_handle ()
#15 0x00000000007ba1ba in zend_objects_store_del_ref ()
#16 0x0000000000791ab1 in _zval_dtor_func ()
#17 0x0000000000782e1d in ?? ()
#18 0x0000000000783036 in _zval_ptr_dtor ()
#19 0x0000000000791e26 in _zval_ptr_dtor_wrapper ()
#20 0x00000000007a1960 in ?? ()
#21 0x00000000007a1f96 in zend_hash_reverse_apply ()
#22 0x0000000000782a1e in shutdown_destructors ()
#23 0x000000000079346f in zend_call_destructors ()
#24 0x0000000000738cce in php_request_shutdown ()
#25 0x0000000000819541 in main ()

contact me on IRC if you want more informations (nick : renchap)

comment:6 in reply to: ↑ 5 Changed 7 years ago by renchap

this is better :

Program terminated with signal 11, Segmentation fault.
#0  0x0000000000771675 in ?? ()
(gdb) bt
#0  0x0000000000771675 in ?? ()
#1  0x0000000000772fcc in ?? ()
#2  0x000000000077463d in _efree ()
#3  0x00000000007830cf in ?? ()
#4  0x0000000000783054 in _zval_ptr_dtor ()
#5  0x0000000000791e26 in _zval_ptr_dtor_wrapper ()
#6  0x00000000007a15b2 in zend_hash_destroy ()
#7  0x0000000000791a7c in _zval_dtor_func ()
#8  0x0000000000782e1d in ?? ()
#9  0x0000000000783036 in _zval_ptr_dtor ()
#10 0x0000000000791e26 in _zval_ptr_dtor_wrapper ()
#11 0x00000000007a15b2 in zend_hash_destroy ()
#12 0x00000000007b5fc4 in zend_object_std_dtor ()
#13 0x00000000007b63c2 in zend_objects_free_object_storage ()
#14 0x00000000007ba362 in zend_objects_store_del_ref_by_handle ()
#15 0x00000000007ba1ba in zend_objects_store_del_ref ()
#16 0x0000000000791ab1 in _zval_dtor_func ()
#17 0x0000000000782e1d in ?? ()
#18 0x0000000000783036 in _zval_ptr_dtor ()
#19 0x0000000000791e26 in _zval_ptr_dtor_wrapper ()
#20 0x00000000007a1960 in ?? ()
#21 0x00000000007a1f96 in zend_hash_reverse_apply ()
#22 0x0000000000782a1e in shutdown_destructors ()
#23 0x000000000079346f in zend_call_destructors ()
#24 0x0000000000738cce in php_request_shutdown ()
#25 0x0000000000819541 in main ()

comment:7 Changed 7 years ago by renchap

here is the full backtrace : http://perso.renchap.com/xcache/

PHP 5.2.1-pl3-gentoo (cgi-fcgi) (built: May 7 2007 18:47:50) (DEBUG)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

with XCache v1.2.0, Copyright (c) 2005-2006, by mOo

comment:8 Changed 7 years ago by moo

analyzed

<?php
class Graph {
// ...
var $yaxis;
}

// ...
class Axis {
// ...
var $color=array(0,0,0); // <- corruption detected when destructing this
}

possible relative code:

<?php
    $this->yaxis = new Axis($this->img,$this->yscale);

comment:9 Changed 7 years ago by moo

  • Resolution set to fixed
  • Status changed from assigned to closed

seems fixed in 1.2-dev as of r380, feel free to reopen

comment:10 Changed 7 years ago by renchap

  • Resolution fixed deleted
  • Status changed from closed to reopened

Segfaults are back :(

Here is the core and php/xcache binaries : http://perso.renchap.com/xcache/2/

comment:11 Changed 7 years ago by mike503

i'm also having an issue. with xcache turned on i am getting bad gateways via fastcgi, and tons of:

php-cgi[6949]: segfault at 0000002a9cc86cc4 rip 0000002a98bc5b38 rsp 0000007fbfff4408 error 4
php-cgi[6951]: segfault at 0000002a9cc86cc4 rip 0000002a98bc5b38 rsp 0000007fbfff4408 error 4
php-cgi[6920]: segfault at 0000002a9cc86a34 rip 0000002a98bc5b38 rsp 0000007fbfff4408 error 4
php-cgi[6956]: segfault at 0000002a9cc8694c rip 0000002a98bc5b38 rsp 0000007fbfff4408 error 4
php-cgi[6959]: segfault at 0000002a9cc86b34 rip 0000002a98bc5b38 rsp 0000007fbfff4408 error 4
php-cgi[6960]: segfault at 0000002a9cc88dd4 rip 0000002a98bc5b38 rsp 0000007fbfff4408 error 4

[root@web03 ~]# uname -a
Linux web03 2.6.20.7-mike #1 SMP Sun Apr 15 20:05:16 PDT 2007 x86_64 GNU/Linux

XCache v1.2.0 built with:
./configure --enable-xcache --enable-xcache-optimizer --enable-xcache-coverager

on ubuntu edgy, all up to date currently from apt

PHP version PHP 5.2.3
memcache from pecl is the only other external module i have compiled in

[root@web03 src]# php -m
[PHP Modules]
bz2
ctype
curl
date
dom
exif
filter
gd
hash
iconv
json
libxml
mbstring
mcrypt
memcache
mysql
mysqli
pcntl
pcre
PDO
pdo_sqlite
posix
Reflection
session
shmop
SimpleXML
sockets
SPL
SQLite
standard
tidy
tokenizer
xml
xmlreader
xmlwriter
xsl
zlib

compiled with:
Configure Command => './configure' '--enable-fastcgi' '--enable-discard-path' '--enable-force-cgi-redirect' '--enable-cli' '--with-mysql' '--with-mysqli=/usr/bin/mysql_config' '--with-curl' '--enable-mbstring' '--with-zlib' '--with-gd' '--enable-track-vars' '--enable-inline-optimization' '--disable-rpath' '--disable-ipv6' '--disable-debug' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir' '--enable-gd-native-ttf' '--enable-shmop' '--with-xsl' '--enable-sockets' '--enable-pcntl' '--with-mcrypt' '--with-bz2' '--enable-sqlite-utf8' '--with-tidy' '--with-pcre-dir' '--enable-exif'

it seemed to be triggered heavily with vbulletin based stuff. i am thinking it might be due to classes/OOP coding, because i don't think my procedural based websites i coded myself had any issues. APC also had an issue with vbulletin's classes at one point too. seems like that is a tricky thing. vbulletin 3.6.5 is the version currently on this site.

here's my php.ini options:

extension = "xcache.so"

xcache.cacher = on
xcache.coverager = on
xcache.optimizer = on
xcache.size = 60M
xcache.count = 2
xcache.var_count = 2
;xcache.readonly_protection = on
;xcache.mmap_path = "/tmp/xcache"

i had tried to do the readonly + different mmap because it looked like it worked for someone else, but it did not for me.

comment:12 Changed 7 years ago by moo

  • pending set to 0

renchap reported to have crash with all other cachers too. i recommend to make a memory test on the box which is however, not possible for a busy server.

suggested memtest tool: Hiren's BootCD, memtest+86 etc

comment:13 Changed 7 years ago by judas_iscariote

where is the code that crashes now ? I have run the complete (318 tests) of JPgraph test suite with no crash..

comment:14 Changed 7 years ago by jrabbit

I originally mentioned this problem on the forums. On my machine it was intermittent - it only fails after a few hours use of my site. It may be that you need to run the test suite repeatedly for a problem to occur. Also, I'm not familiar with the test suite - is it web based or command line 'make test'? If it starts a new copy of php each time, the fault may never show using it.

My situation differs from renchap's slightly in that if I turn read only protection on and use /tmp/xcache as the mmap folder, the fault does not occur.

comment:15 Changed 7 years ago by moo

thanks

comment:16 Changed 7 years ago by c960657

  • Cc c960657 added

FWIW either "/etc/init.d/apache2 reload" or "touch /usr/share/jpgraph2/jpgraph.php" also fixes the problem.

comment:17 Changed 2 years ago by moo

  • Milestone set to undecided

comment:18 Changed 14 months ago by moo

  • Status changed from reopened to new

comment:19 Changed 14 months ago by moo

  • Status changed from new to infoneeded_new

looks like threaded, please check against latest trunk version (after 3.0.2).

will close if no more feedback provided

comment:20 Changed 11 months ago by moo

  • Milestone changed from undecided to 3.0.4
  • Resolution set to worksforme
  • Status changed from infoneeded_new to closed

I suppose the problem is gone with some reason. either fixed in XCache or in PHP

Note: See TracTickets for help on using tickets.