Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 276135 - dev-lang/php-5.2.10, www-apps/phpBB: won't work together
Summary: dev-lang/php-5.2.10, www-apps/phpBB: won't work together
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: PHP Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-01 23:39 UTC by Sven E.
Modified: 2009-07-06 18:30 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven E. 2009-07-01 23:39:48 UTC
After upgrading from php-5.2.9x to php-5.2.10 phpBB stopped working. Downgrading reversed the problem.
I'd expect phpBB to run, but even a freshly unzipped install doesn not work, all that happens ad HTTP 200 Status header is returned (all other headers are missing) and that's about it.
Does anyone have an idea, what change from 5.2.9x to 5.2.10 does trigger this?
How could I track this down?

Reproducible: Always

Steps to Reproduce:
1.upgrade php to 5.2.10
2.try to install phpBB
3.

Actual Results:  
phpBB is not working

Expected Results:  
phpBB should be working the same way it did with 5.2.9

Portage 2.1.6.13 (default/linux/x86/2008.0/server, gcc-4.1.2, glibc-2.9_p20081201-r2, 2.6.27.12 i686)
=================================================================
System uname: Linux-2.6.27.12-i686-Celeron_-Coppermine-with-glibc2.0
Timestamp of tree: Wed, 01 Jul 2009 20:00:01 +0000
distcc 3.1 i686-pc-linux-gnu [disabled]
app-shells/bash:     3.2_p39
dev-lang/python:     2.4.4-r14, 2.5.4-r3
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.6-r2
sys-devel/autoconf:  2.13, 2.63
sys-devel/automake:  1.5, 1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.27-r2
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O3 -mtune=pentium3 -march=i686 -funroll-loops -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /var/bind"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-O3 -mtune=pentium3 -march=i686 -funroll-loops -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LDFLAGS="-Wl,-O1"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl apache2 berkdb bzip2 cjk cli cracklib crypt dri fortran gd gdbm gpm iconv idn imap ipv6 isdnlog midi mudflap ncurses nls nptl nptlonly offensive openmp pam pcre perl postgres pppd python readline reflection session slang snmp spell spl ssl sysfs tcpd truetype unicode x86 xattr xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dbd deflate dir env expires ext_filter file_cache filter headers include log_config logio mem_cache mime mime_magic negotiation rewrite setenvif so" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Christian Hoffmann (RETIRED) gentoo-dev 2009-07-05 23:26:38 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.
Comment 2 Sven E. 2009-07-05 23:39:11 UTC
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...
Comment 3 Sven E. 2009-07-06 01:29:38 UTC
Unfortunately php-5.2.10-r1 doesn't work either.
Comment 4 Christian Hoffmann (RETIRED) gentoo-dev 2009-07-06 08:36:34 UTC
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.
Comment 5 Sven E. 2009-07-06 09:05:52 UTC
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?
Comment 6 Christian Hoffmann (RETIRED) gentoo-dev 2009-07-06 12:25:52 UTC
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.
Comment 7 Sven E. 2009-07-06 15:49:15 UTC
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?
Comment 8 Christian Hoffmann (RETIRED) gentoo-dev 2009-07-06 17:09:03 UTC
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).
Comment 9 Sven E. 2009-07-06 18:30:29 UTC
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?