When running zoph (Zoph Organizes Photos, http://zoph.sf.net), php segfaults in the middle of pages. It seems to segfault in the same place (as measured by how much of the page is sent to the browser) under the same configuration (how php is run, CFLAGS), but changing the configuration does change when the segfault occurs. Sometimes, part of the text passed as arguments to a php 'echo' will get sent to the browser, but php segfaults before the rest is. The segfaults are observable when running zoph via mod_php in Apache 1 and when running it under php-cgi. They occur on many separate pages of zoph: albums.php, users.php?_action=new, import.php, and possibly more that I haven't discovered yet. Though my normal CFLAGS include optimization, php, when compiled with CFLAGS="-pipe", exhibits the same behavior. gentoo ~ # emerge --info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r0, 2.6.11-gentoo-r4 i686) ================================================================= System uname: 2.6.11-gentoo-r4 i686 AMD Athlon(tm) XP 2800+ Gentoo Base System version 1.6.12 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 30 2005, 14:33:29)] distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.10 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r3, 1.6.3, 1.7.9-r1, 1.9.5, 1.4_p6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/cups/docs/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X aalib acl acpi aim alsa apm avi berkdb bitmap-fonts bzlib calendar cdr cdrom cgi chroot cracklib crypt cups curl emboss encode escreen esd ethereal exif expat fam fbdev foomaticdb force-cgi-redirect fortran ftp gcj gd gdbm gif gimpprint gpm gtk gtk2 icq idea imagemagick imap imlib ipv6 ithreads jabber java jikes jpeg libg++ libwww mad maildir matroska mikmod motif mp3 mpeg mpeg4 mplayer msn mysql ncurses nls nptl objc ogg oggvorbis opengl oss pam pcre pdflib perl plotutils png ppds procmail pthreads python readline samba skey slang spell ssl svga symlink tcltk tcpd threads tiff transcode truetype truetype-fonts type1-fonts usb vhosts vim-with-x vorbis wxwindows xml2 xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
I've been running gdb over apache to see exactly where the segfault occurs, and have gotten some interesting results. I've tried loading a few pages: - albums.php, user.php?_action=new, search.php (many times): crashes in "execute () from /etc/apache/extramodules/libphp4.so" (see attached gdb log) - import.php (many times): crashes in "vio_write () from /usr/X11R6/lib/libmysqlclient.so.12". When I run bt, gdb says, "Cannot access memory at address 0xbf7ffff0" after outputting line #0, the call to vio_write(). - import.php (only once): "net_write_command () from /usr/X11R6/lib/libmysqlclient.so.12". I didn't try bt for this crash, and I haven't seen it crash in net_write_command() since.
Created attachment 63632 [details] Log of gpg session
Please compile apache and mod_php / php with debugging: CFLAGS=-g CXXFLAGS=-g FEATURES=nostrip emerge your_packages_here -pipe does only change if gcc makes tempfiles when calling assembler, or to send the content through a pipe, this only affects the speed of compiling. -O2 should not be used when compiling with -g, since you will get inprecise line-numbers. php version? apache version? php use flags? apache use flags? emerge -pv mod_php apache
(In reply to comment #3) > Please compile apache and mod_php / php with debugging: > > CFLAGS=-g CXXFLAGS=-g FEATURES=nostrip emerge your_packages_here Ok, I'm trying that. I'll have news on the results in a little bit. > -pipe does only change if gcc makes tempfiles when calling assembler, or to send > the content through a pipe, this only affects the speed of compiling. Right. > -O2 should not be used when compiling with -g, since you will get inprecise > line-numbers. Good to know. > php version? > apache version? > php use flags? > apache use flags? > > emerge -pv mod_php apache gentoo ~ # CFLAGS=-g CXXFLAGS=-g FEATURES=nostrip emerge -av apache mod_php These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] net-www/apache-1.3.33-r5 +pam (-selinux) +ssl 0 kB [ebuild R ] dev-php/mod_php-4.4.0 +X -apache2 +berkdb +crypt +curl -debug -doc -fdftk -firebird -flash -freetds +gd -gd-external +gdbm -gmp -hardenedphp +imap -informix +ipv6 +java +jpeg -kerberos -ldap -mcal -memlimit -mssql +mysql +nls -oci8 -odbc +pam +png -postgres -snmp +spell +ssl +tiff +truetype +xml2 -yaz 0 kB Total size of downloads: 0 kB Do you want me to merge these packages? [Yes/No]
Ok. I finally got around to gdb'ing apache/mod_php with debugging (sorry about the delay), and I'm another heap of gpg. I tried to load albums.php twice and import.php once (on three seperate -X runs of apache); the gpg log shows the SIGSEGV and backtraces for each.
Created attachment 65180 [details] Log of segfaults with debugging
Hi, That backtrace doesn't include any PHP debugging symbols. You'll need to recompile PHP with the -g CFLAG and recreate the backtrace. The other thing to do is the switch from USE=gd to USE=gd-external, and see if that fixes it. Best regards, Stu
Please try using dev-lang/php-4.4.0 and report back if it works now, much changed in the PHP support there and we'd like to know if this fixes it. More informations on transiting to dev-lang/php can be found on [1]. Best regards, CHTEKK. [1] http://forums.gentoo.org/viewtopic-t-377385.html
See comment #8
When the new dev-lang/php finally went stable (or got mentioned in the GWN, at least) a few days ago, I upgraded. Instead of segfaulting, php complained about hitting an internal memory limit. Debugging revealed that a function in zoph was recursing infinitely. With the new PHP failing helpfully, with it now publicized, and with the original problem revealed to be a bug in zoph, I'm closing this bug. Thanks