Bug Patch: Segfault with PerlOptions -Enable
-8-- Start Bug Report 8-- 1. Problem Description: Apache2 segfaults when a virtual host is configured with PerlOptions -Enable (using the libapache2-mod-perl2 package on a stock Ubuntu 7.04 installation). A test case using bug-reporting-skeleton-mp2.tar.gz is available at http://www.ece.ubc.ca/~derekp/webdevel/mp2-perloptions-enable-bug.tar.gz A patch to fix the segfault is included below. While it does fix the segfault, it is not thoroughly tested. 2. Used Components and their Configuration: *** mod_perl version 2.02 *** using /usr/lib/perl5/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB = aprext MP_APXS= /usr/bin/apxs2 MP_CCOPTS = -g -Wall MP_COMPAT_1X = 1 MP_GENERATE_XS = 1 MP_INCLUDE_DIR = /usr/include/apache2 /usr/include/apr-1.0 MP_LIBNAME = mod_perl MP_TRACE = 0 MP_USE_DSO = 1 MP_USE_GTOP= 1 MP_USE_STATIC = 0 *** /usr/sbin/apache2 -V Server version: Apache/2.2.3 Server built: Jan 15 2007 18:14:50 Server's Module Magic Number: 20051115:3 Server loaded: APR 1.2.7, APR-Util 1.2.7 Compiled using: APR 1.2.7, APR-Util 1.2.7 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT= -D SUEXEC_BIN=/usr/lib/apache2/suexec -D DEFAULT_PIDLOG=/var/run/apache2.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=/var/run/apache2/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=/etc/apache2/mime.types -D SERVER_CONFIG_FILE=/etc/apache2/apache2.conf *** /usr/bin/ldd /usr/sbin/apache2 linux-gate.so.1 = (0xe000) libm.so.6 = /lib/tls/i686/cmov/libm.so.6 (0xb7eb6000) libpcre.so.3 = /usr/lib/libpcre.so.3 (0xb7e96000) libaprutil-1.so.0 = /usr/lib/libaprutil-1.so.0 (0xb7e7c000) libldap_r.so.2 = /usr/lib/libldap_r.so.2 (0xb7e46000) liblber.so.2 = /usr/lib/liblber.so.2 (0xb7e39000) libdb-4.4.so = /usr/lib/libdb-4.4.so (0xb7d3b000) libpq.so.5 = /usr/lib/libpq.so.5 (0xb7d1d000) libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0xb7cbf000) libexpat.so.1 = /usr/lib/libexpat.so.1 (0xb7c9f000) libapr-1.so.0 = /usr/lib/libapr-1.so.0 (0xb7c7c000) libuuid.so.1 = /lib/libuuid.so.1 (0xb7c79000) librt.so.1 = /lib/tls/i686/cmov/librt.so.1 (0xb7c7) libcrypt.so.1 = /lib/tls/i686/cmov/libcrypt.so.1 (0xb7c41000) libpthread.so.0 = /lib/tls/i686/cmov/libpthread.so.0 (0xb7c2a000) libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0xb7c26000) libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb7ae5000) /lib/ld-linux.so.2 (0xb7eeb000) libresolv.so.2 = /lib/tls/i686/cmov/libresolv.so.2 (0xb7ad2000) libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0xb7aba000) libgnutls.so.13 = /usr/lib/libgnutls.so.13 (0xb7a4a000) libssl.so.0.9.8 = /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7a0a000) libcrypto.so.0.9.8 = /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb78c8000) libkrb5.so.3 = /usr/lib/libkrb5.so.3 (0xb784b000) libcom_err.so.2 = /lib/libcom_err.so.2 (0xb7847000) libtasn1.so.3 = /usr/lib/libtasn1.so.3 (0xb7832000) libz.so.1 = /usr/lib/libz.so.1 (0xb781e000) libgcrypt.so.11 = /usr/lib/libgcrypt.so.11 (0xb77cd000) libgpg-error.so.0 = /usr/lib/libgpg-error.so.0 (0xb77c9000) libk5crypto.so.3 = /usr/lib/libk5crypto.so.3 (0xb77a3000) libnsl.so.1 = /lib/tls/i686/cmov/libnsl.so.1 (0xb778c000) libkrb5support.so.0 = /usr/lib/libkrb5support.so.0 (0xb7788000) *** (apr|apu)-config linking info -L/usr/lib -laprutil-1 -L/usr/lib -lapr-1 -luuid -lrt -lcrypt -lpthread -ldl *** /usr/bin/perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=linux, osvers=2.6.15.7, archname=i486-linux-gnu-thread-multi uname='linux rothera 2.6.15.7 #1 smp sat sep 30 10:21:42 utc 2006 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/shar e/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Ds itelib=/usr/local/share/perl/5.8.8 -Dsitearch=/usr/local/lib/perl/5.8.8 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1d ir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -U usenm -Duseshrplib -Dlibperl=libperl.so.5.8.8
Re: Bug Patch: Segfault with PerlOptions -Enable
-8-- Start Bug Report 8-- 1. Problem Description: Apache2 segfaults when a virtual host is configured with PerlOptions -Enable (using the libapache2-mod-perl2 package on a stock Ubuntu 7.04 installation). A test case using bug-reporting-skeleton-mp2.tar.gz is available at http://www.ece.ubc.ca/~derekp/webdevel/mp2-perloptions-enable-bug.tar.gz A patch to fix the segfault is included below. While it does fix the segfault, it is not thoroughly tested. 2. Used Components and their Configuration: *** mod_perl version 2.02 Can you verify that this problem exists in 2.03 also (and svn trunk)? I checked the Changes for trunk and didn't see anything but if this problem still exists and your test case fixes it then there's a good chance we can add this fix once it's been verified.
Re: Configuration Data vs. DirectoryIndex
Marc M. Adkins wrote: I have been struggling with DirectoryIndex behavior and configuration information from custom Perl directives for a while now. I've been scanning the web and posting here and thanks for the previous responses. I now have a solution that seems to work. I have extracted a minimal set of tests that demonstrate the problem and my solution, which I have attached as an archive (tar czf format). I'm not completely happy with my solution, mostly because I'm not completely sure why it works -- or perhaps more to the point why it is necessary. I keep thinking that the mod_dir DirectoryIndex should just work but of course that's bootless. Either it doesn't in this situation or I don't understand something. I'd be pleased to have a better solution. Or an explanation of why this one works. I have tried to reduce the problem to the smallest possible footprint to make it easy to review, for them what has the time and interest. Failing that, perhaps this IS a good solution and may benefit some other poor soul. it's probably just a misunderstanding on your part. I'll take a look at it, but I have absolutely no idea what your tarball actually does - that it contains more than one .conf file is too complex for me to wade through. try using this as a basis instead: http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz if you can have 'make test' issue a failure that can be easily verified I'm pretty sure I can explain what's going on. see also http://marc.info/?l=apache-modperlm=111335082632706w=2 specifically http://marc.info/?l=apache-modperlm=111461643218624w=2 HTH --Geoff
Re: [mp2] Apache2::Reload doesn't reload
On 6/27/07, Colin Wetherbee [EMAIL PROTECTED] wrote: I have a handler in a module called JetSet::Handler. That module depends on a number of other modules, which I've tried to include with 'use', with limited success. It seems, sometimes, symbols act just fine and reload when they should, but other times, I have to restart Apache in order to get the symbols to reload. You have to understand, Perl has no support for reloading modules. What Reload and similar modules do (clearing the symbol table and %INC and loading the module again) usually works, but it's never going to be work for 100% of all perl code because it's not an actual language feature. # In Handler.pm: require JetSet::Debug; JetSet::Debug-import(); # ... JetSet::Debug::DebugLevel(JetSet::Debug::DEBUG_WARN); # End Why import it at all if you're going to fully qualify it like that? Is this your actual code? # From error_log: failed to resolve handler `JetSet::Handler': Bareword JetSet::Debug::DEBUG_WARN not allowed while strict subs in use at /home/cww/sites/rain/htdocs/jet-set/JetSet/Handler.pm line 19. You can declare the sub names with the use subs pragma. Adding parentheses on the end of DEBUG_WARN might help too. I'm not opposed to doing that, but in that case, how does one deal with things like constants? I think what you're really asking here is how do you handle configuring your application. There are many ways to do it. I usually end up having a configuration object of some kind, usually implemented as a singleton. And yes, I restart when I want to change them. It's fairly easy to implement a periodic check for changes in your config file though, if you want to. Things like Log4Perl have this built in. Or, if you really did mean constants, I put them in the files where they are used, and never touch them, since they are... constants. - Perrin
