Closed andrewspy closed 11 years ago
Can you pull master and test against that ??
I've run the test script a bunch of times and cannot reproduce, some changes that could affect this kind of thing were made in the last 48 hours ...
I have pull the master (1f2003af51) and it still crash with another possible error zend_mm_heap corrupted
on top of the errors I mentioned earlier.
I am starting to suspect I compile wrongly somewhere. Can other people confirm?
Did you make clean ?? Can I get a backtrace from gdb ??
I have make clean
on the master (1f2003af51), and it still crashes occasionally. I do encounter 1 FAIL test when make test
on the following:-
FAIL Test objects that have gone away [tests/gone.phpt]
As for gdb, I do not know on producing the backtrace. Would you be able to share with me on the your compilation option for PHP, so that I can try to compile PHP again and test against the test case.
Thanks!
Regards, Andrew
[joe@fiji pthreads]$ cat /usr/src/php-src/config.nice
#! /bin/sh
#
# Created by configure
'./configure' \
'--with-apxs2=/opt/php-zts/bin/apxs' \
'--prefix=/opt/php-zts' \
'--bindir=/opt/php-zts/bin' \
'--with-config-file-dir=/opt/php-zts' \
'--with-config-file-scan-dir=/opt/php-zts/modules.d/' \
'--with-curl=shared,/usr' \
'--with-zlib' \
'--enable-libxml' \
'--enable-dom' \
'--enable-simplexml' \
'--enable-gd-native-ttf' \
'--disable-phar' \
'--enable-shared' \
'--enable-maintainer-zts' \
'--enable-opcache=shared' \
'--with-mysqli=mysqlnd' \
'--enable-debug' \
"$@"
[joe@fiji pthreads]$
There's my config.nice at the moment,
[joe@fiji pthreads]$ php-zts -m
[PHP Modules]
Core
ctype
date
dom
ereg
fileinfo
filter
hash
iconv
json
libxml
mysqli
mysqlnd
pcre
PDO
pdo_sqlite
posix
pthreads
Reflection
session
SimpleXML
SPL
sqlite3
standard
tokenizer
xml
xmlreader
xmlwriter
zlib
Modules list there ^^
I'm a little busy today, but I will try and emulate your setup exactly later on and see what I can find, just wanted you to check against master to be sure the problem still exists .... nobody enjoys looking for problems that don't exist :)
--enable-debug is what creates debugging symbols in the php build, you then build pthreads against this, and it will have debugging symbols ...
To get a backtrace, get your debug php running with pthreads loaded, execute the following:
gdb php-zts
run /path/to/script.php
(where php-zts is your ts php binary and /path/to/script.php is the code that crashes)
Watch the screen, if errors are reported type
backtrace
and copy/paste the output here ...
when a process crashes a "core" file is written (you might need to set ulimit -c to a value != 0 for this to happen).
once you got the core file (which is usualy named
example:
You end up in some kind of shell that controls GDB. The command "bt" produces a backtrace.
Hi @krakjoe
Using your PHP compilation option and your list of module did resolve the issue. I'll try to generate a GDB backtrace on my enviroment and let you have a look.
Thanks!
<?php
/**
* Testing create object(Lib) in other class(App) outside of the threads!
* Thread(T)/Worker(W) will occasionally crash with following possible error:-
* - Segmentation fault (very often)
* - PHP Fatal error: Nesting level too deep - recursive dependency?
* in Unknown on line 0 (not very often)
*/
class Lib{
private $var1; // For some reason, will not crash if no property
private $var2;
private $var3;
private $var4;
private $var5;
function __construct(){
$this->var1 = 0;
$this->var2 = 0;
$this->var3 = 0;
$this->var4 = 0;
$this->var5 = 0;
}
}
class App{
private static $lib;
static function init(){
self::$lib = new Lib;
return 1;
}
public static function getInstance() {
return self::$lib;
}
}
App::init();
class T extends Thread{
function run(){
print "Running Thread...\n";
App::init();
$w = new W;
$w->start();
$works = array();
for($i=0; $i<10; $i++){
$s = new S;
$works[] = $s; // Keep a reference
$w->stack($s);
}
$w->shutdown();
}
}
class S extends Stackable{
function run(){
var_dump(App::getInstance());
print "Running Stackable...\n";
}
}
class W extends Worker{
function run(){
App::init();
print "Running Worker...\n";
}
}
/**
* Threads/Workers are running independently of App/Lib, but may still crash
* occationally!
*/
$threads = [];
for($i=0; $i<10; $i++){
$t = new T;
$t->start();
$threads[] = $t;
}
$threads = [];
print "Done!\n";
Afternoon @andrewspy, above is a modified version of your original code, without explicit dtors, with privates and statics ...
==31458== Memcheck, a memory error detector
==31458== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==31458== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==31458== Command: php-zts stat.php
==31458==
==31458==
==31458== HEAP SUMMARY:
==31458== in use at exit: 752 bytes in 24 blocks
==31458== total heap usage: 129,228 allocs, 129,204 frees, 26,628,654 bytes allocated
==31458==
==31458== LEAK SUMMARY:
==31458== definitely lost: 672 bytes in 21 blocks
==31458== indirectly lost: 48 bytes in 2 blocks
==31458== possibly lost: 0 bytes in 0 blocks
==31458== still reachable: 32 bytes in 1 blocks
==31458== suppressed: 0 bytes in 0 blocks
==31458== Rerun with --leak-check=full to see details of leaked memory
==31458==
==31458== For counts of detected and suppressed errors, rerun with: -v
==31458== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
I think that should fix it ...
Hi @krakjoe,
The script you modified still does not resolve the "Segmentation Fault" issue. And, I have discovered that it is caused by the --enable-debug
of the compilation settings. For some reason, if we don't specify "--enable-debug" during compilation, the segmentation fault will happen, which does not make any sense to me.
Hope you can look into it. Thanks!
Regards, Andrew
Did u pull in changes from master ???
Will try no debug build at home am out and about at the minute ..
Hi @krakjoe,
Sorry, I have not pull from master yet... let me try that first.
Thanks!
Hi @krakjoe,
I have pull from master, and everything seems to work fine now even without the --enable-debug
compilation option. Just a note that, I still have a fail test during make test
process on:-
FAIL Test objects that have gone away [tests/gone.phpt]
Thanks a lot!
Regards, Andrew
@krakjoe The test is failing because the --EXPECT-- part is empty. Should be:
object(O)#2 (0) {
}
I have been trying to identify a testcase, which works perfectly fine in Win32, but some how crash occasionally in Linux x86_64. Not sure what is the issue. Below is the test code:-
php -m
php -i