After emerging apache2 and mod_perl and editing /etc/conf.d/apache2 like this : APACHE2_OPTS="-D PHP5 -D FASTCGI -D PERL" i get segfault. Reproducible: Always Steps to Reproduce: 1.emerge apache2 mod_perl 2.nano -w /etc/conf.d/apache2 3./etc/init.d/apache2 restart Actual Results: * Restarting apache2 ... httpd not running, trying to start /sbin/runscript.sh: line 472: 4457 Segmentation fault ${APACHE2} ${APACHE2_OPTS} -k restart [ !! ]
Can you please try the follow: emerge gdb, if you don't already have it installed gdb /usr/sbin/apache2 (inside gdb) set args -X -D PHP5 -D FASTCGI -D PERL run (it should now crash) where Post the output of the 'where' command here. Thanks
(gdb) where #0 0xb7126aa4 in ?? () #1 0x00000000 in ?? () #2 0x0810ebd0 in ?? () #3 0x080bc750 in ?? () #4 0x00000004 in ?? () #5 0xb7139e3c in ?? () #6 0x00000003 in ?? () #7 0xbffffa88 in ?? () #8 0xb7126c94 in ?? () #9 0x080a20f0 in ?? () #10 0x080bc2d0 in ?? () #11 0x080bc9b8 in ?? () #12 0xb7139460 in ?? () #13 0xb71267b5 in ?? () #14 0x00000000 in ?? () #15 0x0000000b in ?? () #16 0xb7126bef in ?? () #17 0x08161ad8 in ?? () #18 0xb7133916 in ?? () #19 0x00000009 in ?? () #20 0x080bc720 in ?? () #21 0x080bc9b8 in ?? () #22 0xb7139e3c in ?? () ---Type <return> to continue, or q <return> to quit--- #23 0xbffffab8 in ?? () #24 0xb712691c in ?? () #25 0x080a20f0 in ?? () #26 0x080bc2d0 in ?? () #27 0xb7139460 in ?? () #28 0x00000000 in ?? () #29 0xb71267b5 in ?? () #30 0xb712680d in ?? () #31 0x0808fc63 in _IO_stdin_used () #32 0xb71268f0 in ?? () #33 0x00000000 in ?? () #34 0xb7139e3c in ?? () #35 0xbffffad8 in ?? () #36 0xb711a30a in ?? () #37 0x080a20f0 in ?? () #38 0x080bc2d0 in ?? () #39 0x080bc2d0 in ?? () #40 0xb711a2a9 in ?? () #41 0xb7ca89a8 in ?? () #42 0x0811f704 in ?? () #43 0x080ce1a0 in ?? () #44 0x08068ac9 in ap_run_post_config () #45 0x080cc198 in ?? () ---Type <return> to continue, or q <return> to quit--- #46 0x080ce1a0 in ?? () #47 0x080bc2d0 in ?? () #48 0x00000000 in ?? () #49 0xb7ff71a0 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 #50 0x0806e4fc in main ()
you must have debugging information ENABLED. Otherwise, backtraces will not be usefull. You see, it contains just "??" each per line. You would otherwise see a bloat of function names and local variables otherwise (that we need to track this down). adapt your /etc/make.conf (temporary) to contain the following subset: FEATURES="keeptemp keepwork nostrip" C[XX]FLAGS="-O0 -g3" then, backtraces will be helpful :)
Same problem here. Here's what I get: ---snip--- Starting program: /usr/sbin/apache2 -X -D PHP5 -D FASTCGI -D PERL (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 10460)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 10460)] 0xa7a42aef in ap_pcw_walk_files_config (pconf=0x80a8e28, s=0x80c3008, dconf=0x80c36f0, modp=0xa7a57340, dir_cb=0xa7a427a0 <modperl_hash_handlers_dir>, data=0x0) at modperl_pcw.c:52 52 ap_conf_vector_t **dirs = (ap_conf_vector_t **)dconf->sec_file->elts; ---snip--- Any ideas? Thanks, Nate
# gdb /usr/sbin/apache2 GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -X -D PERL Starting program: /usr/sbin/apache2 -X -D PERL [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 30258)] mod_perl trace flags dump: a On (Apache API interaction) c On (configuration for directive handlers) d On (directive processing) e On (environment variables) f On (filters) g On (Perl runtime interaction) h On (handlers) i On (interpreter pool management) m On (memory allocations) o On (I/O) s On (perl sections) t On (benchmark-ish timings) modperl_cmd_requires: push PerlRequire /etc/apache2/modules.d/apache2-mod_perl-startup.pl Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 30258)] 0xb7a7ab35 in ap_pcw_walk_files_config (pconf=0x80ace28, s=0x80c7008, dconf=0x80c76f0, modp=0xb7a8eda0, dir_cb=0xb7a7a7dd <modperl_hash_handlers_dir>, data=0x0) at modperl_pcw.c:52 52 ap_conf_vector_t **dirs = (ap_conf_vector_t **)dconf->sec_file->elts; (gdb) where #0 0xb7a7ab35 in ap_pcw_walk_files_config (pconf=0x80ace28, s=0x80c7008, dconf=0x80c76f0, modp=0xb7a8eda0, dir_cb=0xb7a7a7dd <modperl_hash_handlers_dir>, data=0x0) at modperl_pcw.c:52 #1 0xb7a7ad87 in ap_pcw_walk_config (pconf=0x80ace28, s=0x80c7008, modp=0xb7a8eda0, data=0x0, dir_cb=0xb7a7a7dd <modperl_hash_handlers_dir>, srv_cb=0xb7a7a841 <modperl_hash_handlers_srv>) at modperl_pcw.c:106 #2 0xb7a7a992 in modperl_mgv_hash_handlers (p=0x80ace28, s=0x80c7008) at modperl_mgv.c:473 #3 0xb7a6d3da in modperl_hook_post_config (pconf=0x80ace28, plog=0x80d6ed0, ptemp=0x80d8ed8, s=0x80c7008) at mod_perl.c:584 #4 0x0806a620 in ap_run_post_config (pconf=0x80ace28, plog=0x80d6ed0, ptemp=0x80d8ed8, s=0x80c7008) at config.c:86 #5 0x08070e2e in main (argc=4, argv=0xbffff284) at main.c:565 I'm currently using Apache2 compiled with USE="-mpm_worker mpm_prefork" and mod_perl with USE="-threads" (though I've tried it with threads and received the same error). I am confirming the above error. Is there a solution yet?
Works Ok here with Apache and mod_perl 2.0.0rc6 (see bug # 77551) compiled with CFLAGS="... -D_FILE_OFFSET_BITS=64" - may be this is the problem ?
any trial to get 64bit support *partially* is likely to fail and result into SEGFAULTs. Either get a complete 64bit apache system (and all packages that depend directly or indirectly on apr) or leave it *as-is*, that is, no 64bit anylonger - as we dropped it because of a couple of problems we ran into. Please try compiling it without D_FILE_OFFSET_BITS=64 and any other 64bit alike flags. If it works, than we know that it's been the reason for sure. 64bit enabled apache is about to come back ASAP apache 2.2/2.1 hits the portage tree ;)
[cite] Either get a complete 64bit apache system (and all packages that depend directly or indirectly on apr) or leave it *as-is*, that is, no 64bit anylonger - as we dropped it because of a couple of problems we ran into. [cite] The question is: how to disable 64bit support totally ? Recent versions of perl will detect LFS support without any help from user. And if you'll compile Apache without LFS support there are ZERO options to compile mod_perl! With -D_FILE_OFFSET_BITS=64 you'll get something incompatible with Apache and without it you'll get something incompatible with libperl ! At least when I compile apache, perl (default, no need for my intervention) and mod_perl with -D_FILE_OFFSET_BITS=64 I something working...
I'm being really far off familar with mod_perl (nor perl), but the majority was against supporting LFS somewhere before apache 2.1/2.2. So, finally, we should push an apache httpd 2.1/2.2 ebuild into the tree (hard masked of course), that then will have LFS enabled by default, and let mod_perl depend on it. but do you want to use this version anyway? Well, it's been really not my descission in dropping LFS, however, we had too many problems (obviousely) in supporting it (don't ask me, but the others obviousely don't answer otherwise!!). Is there *any* state of progress in mod_perl w/ current (yet masked) apache ebuilds?
I do not know what to do, but I DO know few facts about current state of mod_perl in portage. 1. Perl. It will say while compiling: -- cut -- Try to understand large files, if available? [y] -- cut -- And then happily use command -- cut -- gcc -DPERL_CORE -c -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 $CFLAGS -- cut -- 2. Apache. LFS support removed for 2.0.x. Can be enabled with "CFLAGS=-D_FILE_OFFSET_BITS=64 ...". 3. mod_perl. Will NOT detect LFS and WILL NOT use -D_FILE_OFFSET_BITS=64 by default. More: even if you'll add -D_FILE_OFFSET_BITS=64 to CFLAGS it WILL ignore it and will use it's own CFLAGS. I've used some brute force way to make in honour portage's $CFLAGS (see bug # 77551 ). When I compile everything with LFS support everythin works. If someone want to compile Apache and mod_perl without LFS support he or she will be forced to make perl non-LFS aware - I do not know if it's easy or not. In any case it'll require rebuild of most perl extensions. And since quite frankly I'm not interested in full rebuild of everything perl-related just to make mod_perl happy I've decided to make apache and mod_perl use -D_FILE_OFFSET_BITS=64. THIS worked. Apache works, mod_perl works, mod_php works (via -D_FILE_OFFSET_BITS=64 in portage CFLAGS). End of story - at least for me.
About versions: I've used perl 5.8.6-r4, apache 2.0.54-r5 and mod_perl 2.0.0rc6 - with flags discussed above. I have no information about any masked versions in portage... Since by default perl 5.8.6-r4 will use LFS and apach 2.0.54-r5 will not... well - there are no way to compile mod_perl compatible with both... This was the problem all along.
Apache won't be LFS aware until we put 2.1/2.2 into portage. The only way to fix this is to remove LFS from PERL (I believe). Possibly a useflag that enables LFS and blocks apache if it's set?
I've got the following: perl-5.8.6-r6 apache-2.0.54-r31 As we know from Canal Vorfeed's comments, perl uses -D_FILE_OFFSET_BITS=64 by default. I set this flag in make.conf as suggested, and confirmed that Apache2 got compiled using this flag. I did not appply the patch to mod_perl that he mentions in another bug. Apache will start, but it doesn't serve any pages. I removed the startup flags -D PERL and -D PHP4 from /etc/conf.d/apache2, restarted the server -- still nothing. So, for me, Canal Vorfeed's solution (sadly) in general didn't work -- Apache itself runs but now doesn't serve pages. (without the flag, Apache was working, mod_perl wasn't)
I've got a problem that's likely related to this: net-www/apache-2.0.55-r1 (x86) dev-lang/perl-5.8.7-r3 (x86) www-apache/mod_perl-2.0.1-r2 (~x86) With -D PERL to apache, it freezes during startup. I'm guessing this is due to the mismatch of a non-LFS apache and LFS perl/mod_perl. Is there any good way to get mod_perl working with apache-2 at this time, or do I need to do an additional apache-1 install with mod_perl-1.3?
net-www/apache-2.0.55-r1 (x86) sys-devel/libperl-5.8.7 (x86) dev-lang/perl-5.8.7-r3 (x86) www-apache/mod_perl-2.0.1-r2 (~x86) This combination causes apache to hang during startup with -D PERL is specified, most likely due to a mismatch of large file support between apache (disabled) and libperl (enabled). Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 2.6.12-gentoo-r10 i686) ================================================================= System uname: 2.6.12-gentoo-r10 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.14 dev-lang/python: 2.2.3-r5, 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 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.22 virtual/os-headers: 2.4.19-r1, 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -finline-functions -falign-loops=5 -falign-jumps=5 -falign-functions=33" 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=pentium3 -O2 -finline-functions -falign-loops=5 -falign-jumps=5 -falign-functions=33" DISTDIR="/var/cache/distfiles" FEATURES="autoconfig sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/var/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://<local mirror>" USE="x86 acl adns alsa apache2 apm arts avi berkdb bitmap-fonts bzip2 crypt eds emboss encode expat foomaticdb fortran gdbm geoip gif gpm gstreamer gtk2 imagemagick imap imlib jpeg ldap libg++ libwww mad mhash mikmod mmx motif mp3 mpeg mysql ncurses nls odbc ogg oggvorbis opengl oss pam pcre pdflib perl php png python quicktime readline samba sdl slang spell sqlite sse ssl tcpd tiff truetype truetype-fonts type1-fonts udev vhosts vorbis xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
(In reply to comment #15) > net-www/apache-2.0.55-r1 (x86) > sys-devel/libperl-5.8.7 (x86) > dev-lang/perl-5.8.7-r3 (x86) > www-apache/mod_perl-2.0.1-r2 (~x86) I have this exact combination on 2 boxes, and 2 boxes with 5.8.8 for perl, and can't dup this bug still :/ I also completely missed this bug when I unmasked mod_perl-2.0.1-r2 this weekend. Mea culpa completely on failing to find this bug in my trackers.
*** Bug 124317 has been marked as a duplicate of this bug. ***
Just to be 100% safe - would someone (who is experiencing this) mind doing a fresh rebuild of mod_perl? I'd like to rule out any in-place (non-bump) edits having made it into the ebuild through good intentions, that also inadvertantly fixed this bug when no one was looking.
Just emerged mod_perl-2.0.1-r2 on a stable box using exact same versions as in comment #15 and didn't see any problems at all. Apache starts, stops and restarts properly and I get the expected results from browsing http://localhost/perl-status as well. As mod_perl has never been installed on this box before I can't say I've experienced this issue before but I can't seem to replicate it either.
Installed mod_perl and tested here, seems to work for me.
FWIW, been using this for ages and it never did segfault for me.
Can any of the original bug posters comment/confirm following a re-emerge of 2.01-r2? If we don't hear anything in the next day or so I'm voting to close this bug out (you can always reopen it :)
mod_perl-2.0.2 seems to work. At least apache2 doesn't hang at startup.
Going ahead and marking this bug closed now. Please reopen if this bug persists. Thanks for your patience, ~mcummings
