Hi, I had this problem for serval months now (it started since php 4.3.8 appeared in portage). Every time I try to emerge php it compiles fine, but then segfaults on PEAR install. FROM THIS POINT ON IT ASLO MAKES MY SYSTEM HIGHLY UNSTABLE AND FREEZES IT: - after the segfault, I cannot start any apps anymore (X or command line). When I start a new app, it hangs there. Within 1 or 2 minutes, everything is blocked, exept for the mouse pointer that still moves. After 1 or 2 more minutes the complete system is frozen. This has been happening for several month, with several kernel versions (now I am on kernel 2.6.10-rc3). It has happened with php-4.3.8 up to 5.0.2 (but strangely I was able to install 5.0.1). php-4.3.6 did not have this problem, but it is not in portage anymore so I cannot install php.... Please fix this or put php-4.3.6 back. $ emerge info Portage 2.0.51-r8 (default-linux/x86/2004.0, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-rc3-vv_e1 i686) ================================================================= System uname: 2.6.10-rc3-vv_e1 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz Gentoo Base System version 1.6.6 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Sep 19 2004, 23:27:35)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r4 sys-devel/automake: 1.8.5 sys-devel/binutils: 2.14.90.0.8-r1 sys-devel/libtool: 1.5.2-r7 virtual/os-headers: 2.6.8.1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer -fPIC" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/alias /var/qmail/control /var/vpopmail/domains/var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer -fPIC" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks prelink sandbox sfperms" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo ftp://mirrors1.netvisao.pt/gentoo/ http://gentoo.mirror.icd.hu/ ftp://ftp.heanet.ie/pub/gentoo/ ftp://ftp.easynet.nl/mirror/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/overlays/portage /usr/local/overlays/bmg-gnome-current" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib acpi alsa apache2 apm arts avi berkdb bitmap-fonts breakme cdr crypt cups dga dts dvd dvdr dvdread encode f77 fam flac flash foomaticdb fortran gdbm gif gimpprintgnome gphoto2 gpm gstreamer gtk gtk2 icc imagemagick imap imlib jack java jpeg junit kde ldap libg++ libwww mad maildir matroska mikmod mmx mmx2 motif mozilla mpeg mysql nas ncurses nls nptl odbc oggvorbis ooo-kde opengl oss pam pam-mysql pdflib perl png ppds python qt quicktime readline sasl scanner sdl slang spell sqlite sse sse2 ssl tcltk tcpd tiff truetype usb x86 xml xml2 xmms xv xvid zlib"
please repeat this on a known good kernel (I recommend hardened-dev-sources), and provide a backtrace from the PEAR segfault. Also specify if PHP is linked against _any_ packages from BMG. You can get the old PHP version from the CVS tree.
Thanks for your reply. As I said, this problem has been going on for months, on many different kernels, including stable gentoo kernels, etc... (I have never tried hardened-sources, and don't have the time to try...). So this cannot be solved by changing the kernel version. I am attaching the strace output, but it is not complete as the write process probably froze before it could write everything to the disk. As I said, after the segfault all my processes strat freezing one after the other, and the machine is completely frozen after 30 seconds or 1 minute. PHP is not linked against anything from BMG, and I did not have anyithing from BMG installed my system for months now... As everything freezes I could not save complete output to the disk (but please check the attached file). But finaly, I have now again tried compiling with CFLAGS="-O2" and here is what I wrote down manually( it is at the end, in >>>Install, just after installing PHP CLI): [PEAR] Archive_Tar - installed:1.1 Error... Funtion php-sapi_src_install, line 525, Exitcode 2 (no error message)
Created attachment 46011 [details] strace output
your strace output doesn't contain the problem at all, not because it didn't write to disk, but because you only attached it to the emerge process and not the PHP process. compile PHP via ebuild: E=/usr/portage/dev-php/php/php-4.3.9.ebuild T=/tmp/pear S=/var/tmp/portage/php-4.3.9/work/php-4.3.9 V="-n -dshort_open_tag=0 -dsafe_mode=0" mkdir ${T} CFLAGS="-g" USE="debug" FEATURES="nostrip" ebuild $E clean CFLAGS="-g" USE="debug" FEATURES="nostrip" ebuild $E compile cd ${S}/pear strace -ostrace.pearbase.log -ff ${S}/sapi/cli/php ${V} ${S}/pear/install-pear.php -d "$T" -b "/usr/bin/" ${S}/pear/package-*.xml cd ${S}/pear strace -ostrace.pearpackage.log -ff ${S}/sapi/cli/php ${V} ${S}/pear/install-pear.php -d "$T" -b "/usr/bin/" ${S}/pear/packages/*.tar sync if your box crashes at any stage during the above, use the SysRq console to force a disk sync before rebooting, then note it down in this bug, and continue in the next logical place (eg repeat the variable definitions/cd and then run the next steps). After that you will have a set of files named strace.pearbase.log* and strace.pearpackage.log*. Tar them up and attach them here. Next, repeat the pear phases of the above without strace, but instead having enabled core dumps, and after rebooting, run gdb against the core dump and post up the full backtrace for each core dump.
Everything seems to complete fine, until sync. When I start "sync" it just hangs there, and my running X apps freeze and I cannot start new apps (as described previously). There is not segfault. Also, I tried to look in /var/tmp/portage/php-4.3.9/work/php-4.3.9/pear/ and everywhere else, but I cannot find the strace files... How do I enable core dumps ?
same problem here.
enable core dumps: "ulimit -c 500000000" if your machine crashes on 'sync' I'm strongly inclined to believe this is NOT a php problem. For the strace output take out the '-o...' argument, and try direct the output to a file (check that it's there before running sync).
Well, I think the problem happens at one of the commands before sync, but there is no output. As I said, the pear install is somewhat like a virus that makes the system rot from the inside. One app after the other stops responding until everything freezes. So it looks like the pear install launches its "virus", and I have enough time to start sync, which then freezes (as the other apps). Sorry, I don't have any more time to try this out, there is just no output. As Bjarke Istrup Pedersen posted he has the same problem, I would suggest you mark the php ebuilds as unstable until it is fixed. This is a huge problem as it takes ALL the Linux kernels down (this should not be possible for software). Thanks for your help.
When php returns to the command line it should NOT be running anything more. PHP doesn't fork at all in my straces of the commands I gave you to run. Bjarke/JoWilly: please run this test setup (modified from the previous version) ulimit -c 500000000 PV=4.3.10 PN=php P=${PN}-${PV} E=/usr/portage/dev-php/${PN}/${P}.ebuild T=/tmp/pear.test/ S=/var/tmp/portage/${P}/work/${P} V="-n -dshort_open_tag=0 -dsafe_mode=0" mkdir -p ${T} CFLAGS="-g" USE="debug" FEATURES="nostrip" ebuild $E clean CFLAGS="-g" USE="debug" FEATURES="nostrip" ebuild $E compile cd ${S}/pear strace -ff ${S}/sapi/cli/php ${V} ${S}/pear/install-pear.php -d "$T" -b "/usr/bin/" ${S}/pear/package-*.xml >/tmp/strace.pearbase.log 2>&1 cd ${S}/pear strace -ff ${S}/sapi/cli/php ${V} ${S}/pear/install-pear.php -d "$T" -b "/usr/bin/" ${S}/pear/packages/*.tar >/tmp/strace.pearpackage.log 2>&1 sync
Ok... Jeezzz... this took me again about 5 system reboots as it was rotting my system up again. This time I am positive that the problem happens at the second strace command (I never started sync anymore). The system was stable after the first, and I waited a little and started a few apps before running the second strace command. After the second command, it always freezes, and when I reboot the system the logfiles always have dissapeared, even when I quickly copied them to my home dir (files were there before the reboot when checking with ls, but after the rebbot they were gone). So, before starting the second strace command, I started a new shell and prepared a "cp" to copy the files to another HD with another FS (you won't believe what I went through.. :-). Anyway, I am attaching the files now (sigsev is in the second one).
Created attachment 46187 [details] strace.pearbase.log
Created attachment 46188 [details] strace.pearpackage.log
The sync command was to force the files to be written to disk. If you don't use it as the command, you MUST use the SysRq method to get to sync to make sure the files get written to disk. Alternatively, send the data straight over the network to another machine (you must use something that doesn't cache, like netcat in UDP mode). Looking at the second strace, the only suggestion I can make is to check how full your /tmp is, and check that it passes a forced fsck. The nature of your crash is going to make it _very_ hard to get a coredump (p.s. strace disables coredumps). Grasping at straws here to try and figure out why : 1. What is the '-vv_e1' patch on your kernel? Provide a link so I can check it out for possible things causing this. 2. Why is -fPIC in your C[XX]FLAGS? (I know this can cause problems on amd64) If you need a production quality PHP to get work done in the meantime, grab the old ebuilds from CVS, and put them in your overlay, and then use /etc/portage/package.mask to block all newer versions. The old versions are not in the tree anymore as they have a lot of security problems (that's almost the only reason the 4.3.* tree still gets new versions). cat >>/etc/portage.mask <<EOF >dev-php/php-4.3.6 >dev-php/php-cgi-4.3.6 >dev-php/mod_php-4.3.6 EOF
nearly the same issue here. but when pear installs fails, i get this error: kernel BUG at fs/reiser4/plugin/fle/tail-conversion.c:58! invalid operand: 0000 [+1] with a reiser4 tmp and root partition. using kernel 2.6.9-rc3-mm1.
JoWilly/Bjarke: are you using Reiser4 as well? Helmut: For reiser4 bugs, I strongly advise you to take it to LKML and ensure that it gets fixed properly. I'd love reiser4 to be more stable, but until it's a lot closer, it stays on experimental machines only.
#14> Thats a reiser4 bug, and has nothing to do with php (at least I think), I get it my self from time to time. The reiser4 developers are aware of the problem and working on it, you might wanna go to irc.otfc.net #reiser4. #15> Yes, I am using reiser4.
Robin: i'm aware of that. didn't point out my experiences detailed enough: i'm getting the kernel bug, since i'm using 2.6.10-rc3-mm1, before that,the pear install just hang, and system became unstable. so maybe - if they are using reiser4 - others viewing this thread may be directed to their real problem: reiser4 and it's bug
Bjarke/Helmut: ok, here is the kicker now. Please try to reproduce this when you aren't using reiser4. If you have sufficent memory, set PORTAGE_TMPDIR=/dev/shm as an easy way to get around it. Alternatively, make an ext3 loopback filesystem and use that for testing.
time is precious in the moment, and i'm afraid i can test it mid of january, not earlier. but i'll look what is possible until christmas.
Just compiled it on another computer, when using another filesystem for /var/tmp , and it compiles fine, so it might be a reiser4 bug after all.
Yes, I am using reiser4.
"when using another filesystem for /var/tmp , and it compiles fine, so it might be a reiser4 bug after all" that's true (just tried it here), and what i expected.
just unmounted /var/tmp (it's mounted -o bind from my reiser4 partition), and guess what .... it installes fine :) This should be send upstream to the reiser4 developers.
they're already aware of that, and i even found a patch (but didn't test it): http://lkml.org/lkml/2004/12/2/13
#24> I have another problem the other day, got a patch that looks like that one (only has the first + txn_restart_current(); ). It solved another problem, but didn't fix this, cannot say about this patch. Will test it later on my laptop, and report back.
I'm marking this as invalid, since it's a reiser4 bug, and I recommend you do go to the reiser4 mailing lists and solve it there.
let me state one last thing #24> patch works, and php complies
