Recent upgrade of apache from 2.0.54 to 2.0.55 caused apache to segfault. No entries were written to apache's error log. Re-emerging all modules & dev-lang/php didn't resolve the problem. Am running MySQL 5.0.15 PHP 5.0.5-r1
What revision of 2.0.54 did you upgrade from? Also, please post an emerge info. If you could also see if you can figure out what is causing the segfault would be great - disable all the add-on modules and see if it still segfaults. If it doesn't, then re-add each module one by one testing for the segfault.
Was running the latest of 2.0.54 (2.0.54-r31), after downgrading back to this one everything worked again nicely. emerge info follows: Portage 2.0.53_rc6 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r3, 2.6.12. 3-linode14 i686) ================================================================= System uname: 2.6.12.3-linode14 i686 UML Gentoo Base System version 1.12.0_pre9 ccache version 2.4 [enabled] dev-lang/python: 2.2.3-r1, 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.4.19-r1, 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/ config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-detect distlocks sandbox sfperms strict userpriv" GENTOO_MIRRORS="ftp://130.207.108.135/pub/gentoo http://gentoo.mirrors.easynews. com/linux/gentoo/ http://gentoo.seren.com/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowex 3dnowext aalib apache2 apm avi bash-completion berkdb bitmap- fonts bmp bzip2 calendar cdb cgi cjk ck-server cli crypt cups curl dba dpms eds emboss encode erandom exif fastcgi foomaticdb ftp gd gd-external gdbm gif gmp gstreamer hal iconv imagemagick imlib inifile java javascript jpeg jpeg2k junit kerberos libcaca libg++ libwww linuxthreads-tls mad mailwrapper mcve mikmod mmx mmx2 mmxext mng mode-owner mp3 mpeg msn mysql mysqli ncurses nls offensive ogg oggvorbis opengl oss pam pcre pdflib pear perl php pic png posix python quicktime readline real rtc session sharedmem simplexml skey slang sockets spl sqlite sse ssl sun-jdk symlink sysvipc tcltk tcpd tidy tiff tokenizer truetype truetype-fonts type1-fonts udev unicode utf8 vhosts vorbis win32codecs x86 xinetd xml xml2 xmlrpc xsl xvid yaz zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS I can't do much testing, trying out with apache 2.0.55, as this is a running webserver and can't afford downtime. However, if there's any more system details or things you'd like me to try which do not imply downtime, I'd be happy to give it a try.
I don't know if I've bumped in to a same bug or different one, but for my home server Apache 2.0.55 + PHP 5.0.5 started segfaulting after update. The segfaulting doesn't happen in all pages, but just on part of them, and it also happens on nonexistent pages, when 404 redirection points to a PHP script. Contrary to what google search on the subject suggests (it seems like a really common problem, see "google apache 2.0.55 segfault" for example), the problem can't be worked around by disabling mod_rewrite or setting zend_ze1_compatibility=0 or register_long_arrays=0. Do you think it's a new bug or not? For reference, flammie.dyndns.org is my test server and it's mostly written in PHP and works, so the PHP in general seems to work, except in some cases.
The problem with me can be traced down to session_start(); Disabling that prevents the segfaults when the time has come. Before the time has come, everything works perfectly. This also means that when it begins segfaulting; restarting apache usually resolves the issue for a few hours.
Here's one backtrace for it: #0 0xb78f5ea7 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=1 '\001', tsrm_ls=0x827ec70) at /mnt/scratch/var/tmp/portage/php-5.0.5-r4/work/php-5.0.5/main/output.c:298 #1 0xb78f6fb9 in zif_ob_flush (ht=0, return_value=0x84aa658, this_ptr=0x0, return_value_used=0, tsrm_ls=0x3) at /mnt/scratch/var/tmp/portage/php-5.0.5-r4/work/php-5.0.5/main/output.c:764 #2 0xb795524f in zend_do_fcall_common_helper (execute_data=0xaa98be80, opline=0xa993a834, op_array=0x82e3d08, tsrm_ls=0x827ec70) at /mnt/scratch/var/tmp/portage/php-5.0.5-r4/work/php-5.0.5/Zend/zend_execute.c:2760 #3 0xb7955a90 in zend_do_fcall_handler (execute_data=0xaa98be80, opline=0xa993a834, op_array=0x0, tsrm_ls=0x827ec70) at /mnt/scratch/var/tmp/portage/php-5.0.5-r4/work/php-5.0.5/Zend/zend_execute.c:2894 #4 0xb79514a2 in execute (op_array=0x82e3d08, tsrm_ls=0x827ec70) at /mnt/scratch/var/tmp/portage/php-5.0.5-r4/work/php-5.0.5/Zend/zend_execute.c:1437 #5 0xb792b766 in zend_execute_scripts (type=8, tsrm_ls=0x827ec70, retval=0x0, file_count=3) at /mnt/scratch/var/tmp/portage/php-5.0.5-r4/work/php-5.0.5/Zend/zend.c:1064 #6 0xb78e6615 in php_execute_script (primary_file=0xaa98e200, tsrm_ls=0x827ec70) at /mnt/scratch/var/tmp/portage/php-5.0.5-r4/work/php-5.0.5/main/main.c:1643 #7 0xb795ef98 in php_handler (r=0x8273c98) at /mnt/scratch/var/tmp/portage/php-5.0.5-r4/work/php-5.0.5/sapi/apache2handler/sapi_apache2.c:565 #8 0x0806a4f3 in ap_run_handler (r=0x8273c98) at config.c:152 #9 0x0806aa49 in ap_invoke_handler (r=0x8273c98) at config.c:364 #10 0x08065a8e in ap_process_request (r=0x8273c98) at http_request.c:249 #11 0x08060eac in ap_process_http_connection (c=0x826dd00) at http_core.c:251 #12 0x08073a15 in ap_run_process_connection (c=0x826dd00) at connection.c:43 #13 0x08073cfa in ap_process_connection (c=0x826dd00, csd=0x0) at connection.c:176 #14 0x08066d84 in process_socket (p=0x826dbd8, sock=0x826dc10, my_child_num=-1213334874, my_thread_num=0, bucket_alloc=0x0) at worker.c:522 #15 0x0806749c in worker_thread (thd=0x0, dummy=0x0) at worker.c:842 #16 0xb7d9af04 in apr_threadattr_stacksize_set () from /usr/lib/libapr-0.so.0 #17 0x0815dee8 in ?? () #18 0x0826cef8 in ?? () #19 0x00000000 in ?? () It appears I forgot to recompile apr and stuff with debug options, but I suppose this should help?
This looks like a php bug
Seems to be fixed upstream in 5.1.0: http://bugs.php.net/bug.php?id=33987 http://bugs.php.net/bug.php?id=35156 http://bugs.php.net/bug.php?id=34581 etc. tested using gentoo-php-overlay/dev-lang/php/php-5.1.1 and phptoolkit-1.0
The new dev-lang/php revisions added to the tree should fix this, please upgrade to those. Best regards, CHTEKK.
