After upgrading to 2005.0, when cli php is emerged the created php executable seg faults when run causing the following during the install process: Installing PHP CLI binary: /var/tmp/portage/php-4.3.11/image//usr/bin/ Installing PHP CLI man page: /var/tmp/portage/php-4.3.11/image//usr/share/man/man1/ Installing shared extensions: /var/tmp/portage/php-4.3.11/image//usr/lib/php/extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /var/tmp/portage/php-4.3.11/image//usr/lib/php/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2 !!! ERROR: dev-php/php-4.3.11 failed. !!! Function php-sapi_src_install, Line 561, Exitcode 2 Reproducible: Always Steps to Reproduce: 1. emerge php Actual Results: PHP not installed. Expected Results: PHP should have been installed. I have done all that I can think of. Re-emerged both gcc and glibc. Did a revdep-rebuild. Please let me know what additional information is needed.
Always post emerge --info output when reporting bugs.
Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.4.26-gentoo-r11 i686) ================================================================= System uname: 2.4.26-gentoo-r11 i686 Celeron (Mendocino) Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 10 2005, 00:35:37)] dev-lang/python: 2.3.4-r1 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.4_p6, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium2 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.nestegg.com http://www.ibiblio.org/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://gentoo.nestegg.com/gentoo-portage" USE="x86 alsa apache2 apm arts avi berkdb bitmap-fonts crypt emboss encode foomaticdb fortran gdbm gif gnome gpm gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mp3 mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl slang snmp spell ssl svga tcpd tiff truetype truetype-fonts type1-fonts xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
You forgot to reopen this one... ;-)
please repeat the emerge with debugging CFLAGS, and provide a backtrace for the php binary.
debugging flags: USE="debug" CFLAGS="-march=pentium2 -O2 -pipe -ggdb3" CXXFLAGS="-march=pentium2 -O2 -pipe -ggdb3" FEATURES="nostrip"
After emerging with debug there's no traceback: Installing PEAR environment: /var/tmp/portage/php-4.3.11/image//usr/lib/php/php/ make[1]: *** [install-pear-installer] Segmentation fault make: *** [install-pear] Error 2
enable core dumps "ulimit -c unlimited" and then run gdb against the php binary and the core dump.
Created attachment 57441 [details] core dump
the core dump is entirely useless on it's own. you MUST run gdb against it to produce a backtrace, that is then usable. gdb /var/tmp/portage/..../php core
Is this what we're after? (gdb) bt #0 0x40843be0 in init_usm_post_config () from /usr/lib/libnetsnmp.so.5 #1 0x4082a753 in snmp_call_callbacks () from /usr/lib/libnetsnmp.so.5 #2 0x4081fb27 in read_premib_configs () from /usr/lib/libnetsnmp.so.5 #3 0x407fc266 in init_snmp () from /usr/lib/libnetsnmp.so.5 #4 0x08120946 in zm_startup_snmp (type=1, module_number=12) at /var/tmp/portage/php-4.3.11/work/php-4.3.11/ext/snmp/snmp.c:186 #5 0x08200a7f in zend_startup_module (module=0x83c7340) at /var/tmp/portage/php-4.3.11/work/php-4.3.11/Zend/zend_API.c:1006 #6 0x081cb280 in php_startup_extensions (ptr=0x83d18ac, count=0) at /var/tmp/portage/php-4.3.11/work/php-4.3.11/main/main.c:1045 #7 0x08222cdb in php_startup_internal_extensions () at internal_functions_cli.c:129 #8 0x081c9c8b in php_module_startup (sf=0x83aebc4, additional_modules=0x0, num_additional_modules=0) at /var/tmp/portage/php-4.3.11/work/php-4.3.11/main/main.c:1218 #9 0x082216f0 in main (argc=1, argv=0xbffffb14) at /var/tmp/portage/php-4.3.11/work/php-4.3.11/sapi/cli/php_cli.c:582
Based on the backtrace I found the running an snmp command also seg faults. Re-emerged net-snmp with the same results. Now rebuilding with debugging.
yes, that gdb backtrace data is exactly what I was wanting this is something broken in net-snmp. if you could rebuild net-snmp with the debugging flags I provided, and repeat the backtrace procedure again, we should get some line numbers into the net-snmp stuff for the source of the bug.
Core was generated by `snmpget'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libnetsnmp.so.5...done. Loaded symbols for /usr/lib/libnetsnmp.so.5 Reading symbols from /usr/lib/libcrypto.so.0.9.7...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.7 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 #0 init_usm_post_config (majorid=0, minorid=3, serverarg=0x0, clientarg=0x0) at snmpusm.c:2818 2818 snmpusm.c: No such file or directory. in snmpusm.c (gdb) bt #0 init_usm_post_config (majorid=0, minorid=3, serverarg=0x0, clientarg=0x0) at snmpusm.c:2818 #1 0x40081753 in snmp_call_callbacks (major=0, minor=3, caller_arg=0x0) at callback.c:224 #2 0x40076b27 in read_premib_configs () at read_config.c:861 #3 0x40053266 in init_snmp (type=0x400a923c "snmpapp") at snmp_api.c:818 #4 0x40071504 in snmp_parse_args (argc=1, argv=0xbffffb14, session=0xbffff9a0, localOpts=0x8049188 "C:", proc=0x8048fe0 <optProc>) at snmp_parse_args.c:596 #5 0x08048a97 in main (argc=1, argv=0xbffffb14) at snmpget.c:133
ok, I'm passing this over to the netmon folk for net-snmp, since it's NOT a php bug.
Doug, mind posting the snmpget command you used to get that backtrace?
It was snmpget with no options.
hmmm.. snmpget with no options only shows the usage. That really leads me to believe something's really funky on your end. Anyhow, I'm unable to reproduce that here.
This happened when upgrading to 2005.0. I'm guessing that some library needs to be rebuilt, but which one? This is happening on a production machine, so it's difficult for me to go off and rebuild everything. What is happening at that point in the code? Does that give any clue as to what might need to be rebuilt?
have you rebuilt net-snmp itself?
Yes, along with glibc and gcc. Also a revdep-rebuild.
see anthing here http://sourceforge.net/tracker/?group_id=12694&atid=112694 looking similar?
Here's some more info. First I was able to find time to do an "emerge -e system" which did not fix the problem. I did a little snooping and in the routine init_usm_post_config where this is crashing and it's possible for usm_create_initial_user to return NULL. However, this is immediately followed by: SNMP_FREE(noNameUser->engineID); which would be a bad address if noNameUser is NULL. Adding a check for this case fixes the crash and appears to make things work correctly, but I don't know why I have this problem on one machine only. Any thoughts? In any case, looks like a bug that should be fixed.
*** Bug 93912 has been marked as a duplicate of this bug. ***
I have a two machines this is happening on, one is a production machine, I was able to disable the snmp USE flag to get PHP to work on the production machine. I can mess about with the other machine, so I will do some backtraces etc and let you know what I come up with.
*** Bug 105006 has been marked as a duplicate of this bug. ***
I also had a machine that was doing this, several months ago, and I fixed it by disabling the snmp use flag. Somebody in #gentoo-apache suggested it. However, today I find that simple snmpwalk commands also segfault when run locally against my snmpd. Is this related?
dev-php/php, dev-php/mod_php, and dev-php/php-cgi have been replaced by dev-lang/php. Please upgrade (following the guide at http://svn.gnqs.org/projects/gentoo-php-overlay/file/docs/php-upgrading.html?format=raw) to the new-style PHP package and open a new bug if the problem persists. Thank you.
