Summary: | dev-lang/php-5.2.10, www-apps/phpBB: won't work together | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sven E. <dark> |
Component: | [OLD] Development | Assignee: | PHP Bugs <php-bugs> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | axiator, kfm, web-apps |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sven E.
2009-07-01 23:39:48 UTC
Please post emerge -pv dev-lang/php output as well. Are you using suhosin? Might be a dupe of 276583 or the curl regression of 5.2.10. In both cases, please retry with the just committed php-5.2.10-r1 and report back. First, emerge -pv output, I'll try the upgrade again and report back. [ebuild U ] dev-lang/php-5.2.10 [5.2.9-r2] USE="apache2 berkdb bzip2 cjk crypt gd gdbm iconv imap ipv6 ncurses nls pcre postgres readline reflection session snmp spell spl ssl truetype unicode xml zlib -adabas -bcmath -birdstep -calendar -cdb -cgi -cli -concurrentmodphp -ctype -curl -curlwrappers -db2 -dbase -dbmaker -debug -discard-path -doc -empress -empress-bcs -esoob -exif -fastbuild -fdftk -filter -firebird -flatfile -force-cgi-redirect -frontbase -ftp -gd-external -gmp -hash -inifile -interbase -iodbc (-java-external) -json -kerberos -kolab -ldap -ldap-sasl -libedit -mcve -mhash -msql -mssql -mysql -mysqli -oci8 -oci8-instant-client -odbc -pcntl -pdo -pic -posix -qdbm -recode -sapdb -sharedext -sharedmem -simplexml -soap -sockets -solid -sqlite -suhosin -sybase -sybase-ct -sysvipc -threads -tidy -tokenizer -wddx -xmlreader -xmlrpc -xmlwriter -xpm -xsl -yaz -zip" 0 kB --- I guess I am neither using curl, nor suhosin... Unfortunately php-5.2.10-r1 doesn't work either. Reopening then... I just tried reproducing your problem and I was unable to do so. A fresh phpBB-3.0.5 install (vanilla tarball) works flawlessly with 5.2.10-r1 via fastcgi (lighttpd) here. Please make sure that you are not missing any error messages. If you have disabled display_errors or similar php settings (well, phpBB might do that as well), errors might only be logged to your web server or a configured error_log file. Please check those. If no php errors are there, maybe there are messages about apache child crashes or something like that. Shame on me - I did check the vhost's log files, without result, but totally forgot to check the main server's logs - Thanks for your hint about the childs: [Mon Jul 06 03:28:01 2009] [notice] child pid 1458 exit signal Segmentation fault (11) [Mon Jul 06 03:28:02 2009] [notice] child pid 1459 exit signal Segmentation fault (11) [Mon Jul 06 03:28:03 2009] [notice] child pid 1460 exit signal Segmentation fault (11) ---- So yes, obviously the childs segfault. The question remains why. On the same server (other vhosts though), I have various other php-scripts I wrote myself, which all seemed to run fine with 5.2.10 (as far as I tested them). What would be the next steps, now that we know the childs segfault? I'm still unable to reproduce it, even with apache/mod_php, so I fear you have to collect the debugging information yourself. This means: Please report a bug to http://bugs.php.net/ and post the URL to the bug report here, so that I can track it and get the patch once there is one. Then you should ideally provide both a short reproduce script (phpBB3 is probably not considered short) and a backtrace. The latter one is probably easier to accomplish, so I'd focuse on getting this one. This howto should help: http://bugs.php.net/bugs-generating-backtrace.php It's also important that the php devs usually want you to reproduce the bug with a vanilla php (i.e. no distribution-specific patches, this means you should get the official release or a recent snapshot from php.net and build it yourself) and for a useful backtrace they need you to build php with --enable-debug (as noted in the howto). Besides that, I fear I cannot help you much, but feel free to ask back if you have any questions. Thanks for you input so far, Chris. The backtrace thing was, what I was looking for. I'm damed though. before grabbing a php tarball and doing a vanilla build, I thought I'd emerge php with USE="debug", give it a shot and look at the trace myself. Surprise: No crach - I built again without debug, and then again with debug, and it is absolutely reproduceable. Do you by any chance know, if the php build itself modifies the C flags, whne debugging is enabled? And even more important, do you think there is a way to track this down? Ok, so we've got a gcc optimizer issue again (USE=debug mainly strips all custom flags). If I hadn't seem your CFLAGS I'd said it is a bug, but -funroll-loops is something which is certainly not considered a safe CFLAG if set globally. Although removing that CFLAG from your global CFLAGS and rebuilding php might help, it might also be an issue in any library on your system, so I'm tempted to close this bug as INVALID until you have done a full system rebuild and can still confirm it. http://www.gentoo.org/doc/en/gcc-optimization.xml#doc_chap3 So, sorry, but this is not a configuration we can support, unless you or someone else proves that it is not related to -funroll-loops (it might even be -O3. I think having it is considered safe, but it might still trigger different bugs than most standard configurations, so please rebuild at least php with -O2, if you have no luck otherwise). After rebuilding without debug and removing loop unrolling everything seems to work fine. I guess it is gcc's fault then, though loop unrolling seems to be one of the easier optimizations to do. I'd suggest marking the bug closed? |