After upgrading to php-5.2.1-r3 (from php-5.1.6-r6), when I try to access the previously working mediawiki-1.8.4, apache-2.0.58-r2 segfaults and no web page is served up. ==> /var/log/apache2/error_log <== [Sun Mar 11 17:40:20 2007] [notice] child pid 1053 exit signal Segmentation fault (11) If I recompile php and its various extensions with the USE debug flag, ~ # USE=debug emerge -av php pecl-pdo pecl-pdo-mysql pecl-pdo-odbc pecl-pdo-sqlite dev-php5/pecl-yaz then restart apache, apache works as expected and serves up mediawiki pages. ~ # emerge --info Portage 2.1.2.2 (default-linux/x86/2006.1/server, gcc-4.1.1, glibc-2.5-r0, 2.6.16-hardened-r11 i686) ================================================================= System uname: 2.6.16-hardened-r11 i686 AMD Duron(tm) Processor Gentoo Base System release 1.12.9 Timestamp of tree: Sun, 11 Mar 2007 23:00:07 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.2.3-r6, 2.3.5-r3, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=athlon-xp -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php4/ext-active/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php4/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php4/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php4/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O3 -march=athlon-xp -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distcc distlocks fixpackages metadata-transfer parallel-fetch sandbox severe sfperms strict userpriv" GENTOO_MIRRORS="http://128.213.5.34/gentoo/ http://cudlug.cudenver.edu/gentoo/ http://gentoo.noved.org/ http://mirror.tucdemonic.org/gentoo/ http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LINGUAS="en en_CA" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/sunrise" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dfx 3dnow X a52 aac adns alsa apache2 audiofile bcmath berkdb bitmap-fonts bzip2 calendar cdparanoia cdr cli cracklib crypt ctype cups curl dba dbus dbx dga directfb doc dri dts dv dvb dvd dvdread emacs encode exif expat fastcgi fbcon firefox flac foomaticdb fortran ftp gb gcj gd gdbm ggi gif gmp gnome gnustep gnutls gphoto2 gpm gtk gtk2 gtkhtml guile hal iconv imagemagick imap imlib innodb iodbc ipv6 isdnlog jack java jpeg kde leim libg++ lm_sensors lua mad maildir mailwrapper matroska mcal memlimit mhash midi mikmod ming mmx motif mpeg mplayer mysql nas ncurses nls nptl nptlonly nsplugin odbc offensive ofx ogg openexr opengl pam pcntl pcre pda pdf perl php png portaudio posix ppds pppd python qt3 qt4 quicktime rdesktop readline reflection samba sasl session sharedext simplexml slang slp snmp soap sockets speex spell spl sqlite sse ssl svg svga tcl tcltk tcpd tetex theora threads tidy tiff tk tokenizer truetype truetype-fonts type1-fonts unicode usb vcd vorbis wddx win32codecs wmf wxwindows x86 xanim xine xml xmlrpc xorg xosd xpm xprint xsl xvid yaz zip zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_CA" USERLAND="GNU" VIDEO_CARDS="sis vga vesa fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Are you using dev-php5/eaccelerator by chance? If yes, try without it.
Both dev-php[45]/eaccelerator are listed as masked and not installed on my server.
Hmmm...
not the only one, please see http://www.dreamhoststatus.com/2007/02/21/php-521-upgrades-under-way/ - MediaWiki versions under 1.9.2 Any version of MediaWiki under version 1.9.2 will have problems with PHP 5.2. For information on upgrading please see http://www.mediawiki.org.
Thanks for that. I will add ~www-apps/mediawiki-1.9.3 to package.keywords and try an upgrade tonight.
mediawiki-1.9.3 doesn't work either. I had to switch back to a debug version of php and its extensions. At least it is a simple workaround.
(In reply to comment #6) i have mediawiki-1.9.3 install, both x86 and ppc, same result. mediawiki-1.6.10 (last version to run with php4) install tricky, but finally successful (after adaption of table "job" 'cause of new UTF-8 standard in MySQL) please, what does "debug version of php" essentially mean. setting USE-Flag +debug in portage .use for dev-lang/php and recompile ? any significant risks or drawbacks involved? thanks in advancd > mediawiki-1.9.3 doesn't work either. I had to switch back to a debug version of > php and its extensions. > > At least it is a simple workaround. >
(In reply to comment #7) > please, what does "debug version of php" essentially mean. > setting USE-Flag +debug in portage .use for dev-lang/php and recompile ? "Debug version" means compiling php as I had described above: ~ # USE=debug emerge -av php pecl-pdo pecl-pdo-mysql pecl-pdo-odbc pecl-pdo-sqlite dev-php5/pecl-yaz You would have to select your own pecl-* packages corresponding to what is in use at your site. The easiest way to find out what you are using is to emerge just php with the debug USE flag, then check in the correct /usr/lib/php5/lib/php/extensions/no-debug-zts-* directory to see what hadn't been moved into the corresponding .../debug-zts-* directory. Keep emerging pecl packages until you get them all. If this isn't fixed soon, I will be adding php to package.use. Note that none of the pecl packages have a USE debug flag, so they need to be manually emerged each time after php is compiled. Requiring a manual emerge is itself an interesting shortcoming of the pecl packages. Perhaps they should have a debug USE flag added to force a --newuse recompile, even though they don't actually use debug for anything. Jakub, would you like me to open a new bug report for this?
compiled with option debug ist working ... fascinating, but why ?
I'm having crashes with php and apache too and the cause appears to be something accessing memory that it shouldn't. Maybe in the debug version the memory access succeeds because the memory layout is different? Output from valgrind which shows the access violation is below for the maintainers to look at: jon@hal ~ $ valgrind php php_test.php ==15740== Memcheck, a memory error detector. ==15740== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==15740== Using LibVEX rev 1658, a library for dynamic binary translation. ==15740== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==15740== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==15740== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==15740== For more details, rerun with: -v ==15740== ==15740== Invalid read of size 4 ==15740== at 0x829862C: _zval_ptr_dtor (in /usr/lib/php5/bin/php) ==15740== by 0x82CF392: (within /usr/lib/php5/bin/php) ==15740== by 0x82CED9A: execute (in /usr/lib/php5/bin/php) ==15740== by 0x82AC4EB: zend_execute_scripts (in /usr/lib/php5/bin/php) ==15740== by 0x825D8BC: php_execute_script (in /usr/lib/php5/bin/php) ==15740== by 0x8362A7C: main (in /usr/lib/php5/bin/php) ==15740== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==15740== ==15740== Process terminating with default action of signal 11 (SIGSEGV) ==15740== Access not within mapped region at address 0x8 ==15740== at 0x829862C: _zval_ptr_dtor (in /usr/lib/php5/bin/php) ==15740== by 0x82CF392: (within /usr/lib/php5/bin/php) ==15740== by 0x82CED9A: execute (in /usr/lib/php5/bin/php) ==15740== by 0x82AC4EB: zend_execute_scripts (in /usr/lib/php5/bin/php) ==15740== by 0x825D8BC: php_execute_script (in /usr/lib/php5/bin/php) ==15740== by 0x8362A7C: main (in /usr/lib/php5/bin/php) ==15740== ==15740== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 1) ==15740== malloc/free: in use at exit: 1,020,548 bytes in 12,934 blocks. ==15740== malloc/free: 13,997 allocs, 1,063 frees, 1,366,025 bytes allocated. ==15740== For counts of detected errors, rerun with: -v ==15740== searching for pointers to 12,934 not-freed blocks. ==15740== checked 2,708,372 bytes. ==15740== ==15740== LEAK SUMMARY: ==15740== definitely lost: 0 bytes in 0 blocks. ==15740== possibly lost: 0 bytes in 0 blocks. ==15740== still reachable: 1,020,548 bytes in 12,934 blocks. ==15740== suppressed: 0 bytes in 0 blocks. ==15740== Reachable blocks (those to which a pointer was found) are not shown. ==15740== To see them, rerun with: --show-reachable=yes Segmentation fault
Hmm, once I rebuilt php without stripping the binaries there is slightly more useful information from valgrind: ==10154== Invalid read of size 4 ==10154== at 0x829862C: _zval_ptr_dtor (in /usr/lib/php5/bin/php) ==10154== by 0x82CF392: zend_do_fcall_common_helper_SPEC (in /usr/lib/php5/bin/php) ==10154== by 0x82CED9A: execute (in /usr/lib/php5/bin/php) ==10154== by 0x82AC4EB: zend_execute_scripts (in /usr/lib/php5/bin/php) ==10154== by 0x825D8BC: php_execute_script (in /usr/lib/php5/bin/php) ==10154== by 0x8362A7C: main (in /usr/lib/php5/bin/php) ==10154== Address 0x8 is not stack'd, malloc'd or (recently) free'd Unfortunately if I turn on debugging (-g) then it doesn't fail so I can't get any more info.
I have also problems with the child pid segfaulting with apache-2.2.4, php-5.2.1-r3 and mysql-5.0.38 recently. Perhaps it's related to this debian bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397904
(In reply to comment #12) > I have also problems with the child pid segfaulting with apache-2.2.4, > php-5.2.1-r3 and mysql-5.0.38 recently. Perhaps it's related to this debian > bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397904 > I'm getting segv here too. If stays even if I remove mysql from the use flags. Using the debug flag fixes it. A minimal PHP script can trigger it: <? $fp = fopen("/dev/null", "r"); ?> My use flags are: apache2 cli -mssql crypt -curl gd gdbm imap jpeg -mcal mysql -oci8 -pam -pdflib png -postgres -qt -snmp hardenedphp -freetds -tiff session xml dba ldap pcre posix -calendar sqlite sockets If I get time this afternoon, I'll try a few compiles with different use flags to try to isolate things a bit better.
(In reply to comment #13) I finally found out what caused the segfaults on my machine. I don't think it's related to this one, but if you indeed use mpm-peruser, too have a look at: http://bugs.gentoo.org/show_bug.cgi?id=177628
I found out what was causing mine. My CFLAGS included -funroll-loops (to be precise, it was "-O3 -march=i686 -funroll-loops -pipe"). Removing that fixed the problem. This problem was present on all builds of PHP 5.2.x, CLI, CGI or apache module. Is it possible to get this fixed in the ebuild?
(In reply to comment #15) > I found out what was causing mine. My CFLAGS included -funroll-loops (to be > precise, it was "-O3 -march=i686 -funroll-loops -pipe"). Removing that fixed > the problem. No, we are not going to filter unsupported CFLAGS.
Please, test with php-5.2.4_pre200708051230-r2
Running the command: ACCEPT_KEYWORDS=~x86 USE=-debug emerge -av =dev-lang/php-5.2.4_pre200708051230-r2 =dev-php5/pecl-pdo-1.0.3 =dev-php5/pecl-pdo-mysql-1.0.2 =dev-php5/pecl-pdo-odbc-1.0.1 =dev-php5/pecl-pdo-sqlite-1.0.1-r1 =dev-php5/pecl-yaz-1.0.8 and then restarting apache2 and loading a page from mediawiki gives me this: [Sat Aug 11 17:17:40 2007] [notice] child pid 28151 exit signal Segmentation fault (11) Switching to USE=debug in the emerge line above gave me back a working web server.
Anyone having this issue should post emerge --info when commenting here, it's required for bugs.
So, to conclude: * John Altstadt, the initial bug reporter, uses -O3 and -funroll-loops -> INVALID * Walter Wandra didn't post emerge --info * Jon Dye didn't post emerge --info either; additionally this might be a completely different bug (mediawiki is mentioned nowhere as far as I see) * Timo Gurr's problem was not related to this bug Unless someone can confirm *this* bug with sane CFLAGS (i.e. not -O3 and especially not -funroll-loops), it should be marked INVALID. (In reply to comment #8) > Requiring a manual emerge is itself an interesting shortcoming of the pecl > packages. Perhaps they should have a debug USE flag added to force a --newuse > recompile, even though they don't actually use debug for anything. Jakub, would > you like me to open a new bug report for this? No, this isn't going to happen. Binary incompatibilities are to be expected sometimes (we do not have php5_0 and php5_2 either, though some (all?) extensions will break when switching without rebuilding), and switching between USE="debug" and USE="-debug" certainly is one of those cases where this is expected.
Per discussion with other PHP maintainers, closing as TEST-REQUEST. Feel free to reopen *if* you can still reproduce this with USE="-debug" *after* you've re-emerged your LAMP setup and related PECL extensions w/ -O2 or less and *without* -funrolls-loops or any similar funky unsupported C[XX]FLAGS Thanks.
From make.conf.example: # NOTE: the -On optimization levels are set with the letter O, not -0 (zero). # # Decent examples: #CFLAGS="-mcpu=athlon-xp -O3 -pipe" #CFLAGS="-march=pentium3 -O3 -pipe" So it would appear that the first recommendation a new user would see is to use -O3. I have no idea where I got the -funroll-loops from. It was probably recommended somewhere (forums?) back at the time when I originally installed Gentoo a few years ago, because I haven't changed that portion of make.conf in a very long time. I have now switched to: CFLAGS="-march=athlon -O2 -pipe -fomit-frame-pointer" as per http://gentoo-wiki.com/Safe_Cflags. Just recompiling php and the pecls with the new CFLAGS and -debug has fixed the problem. Thanks for the heads up. It would be nice if make.conf.example had a pointer to a list of acceptable CFLAGS instead of having incorrect examples. I assume that the wiki is not canonical, but I couldn't easily find a better place. (In reply to comment #20) >> Requiring a manual emerge is itself an interesting shortcoming of the pecl >> packages. Perhaps they should have a debug USE flag added to force a --newuse >> recompile... > No, this isn't going to happen. Binary incompatibilities are to be expected > sometimes (we do not have php5_0 and php5_2 either, though some (all?) > extensions will break when switching without rebuilding), and switching > between USE="debug" and USE="-debug" certainly is one of those cases where > this is expected. This isn't just a binary incompatibility. The build changes the installed location of the pecl packages depending on whether php was built with debug or -debug.
