Following up on a very old thread (below). Brian, thanks for your very useful instructions, and sorry for not following them sooner.
Excerpts from Brian Rectanus's message of Sat Mar 20 14:51:16 -0700 2010: > Often if you upgrade/replace mod_security2.so on a running httpd you > will see this (repeating segfaults) until you RESTART httpd. This is my In short, I did not (the Debian package did not) restart apache after installing mod_security, only graceful restarted, which you indicate is not a supported way to install or upgrade. That's all anyone needs to read, but just for completeness: I got the core dump using your instructions, but running gdb on it produced the same stack trace that I originally posted in the Debian bug: ... ap_process_request ap_run_log_transaction (mod_security) apr_global_mutex_lock segfault Not sure why the trace up to ap_run_error_log didn't look as expected. I am using the prefork MPM, apache 2.2.9 from Debian lenny (2.2.9-10+lenny9), and mod_security 2.5.11 from Debian lenny-backports (2.5.11-1~bpo50+1). The steps to reproduce: 1. Start apache without mod_security installed (or configured obviously). 2. Configure mod_security. My config is very simple: SecRuleEngine On SecAuditEngine RelevantOnly SecRequestBodyAccess On SecRequestBodyLimit 1073741824 SecRequestBodyNoFilesLimit 65536 SecAuditLog /var/log/apache2/post.log SecAuditLogParts AIZ SecRule REQUEST_METHOD POST nolog,auditlog No core rules or anything. 3. Install mod_security via the Debian package. This reloads (graceful restarts) apache. 4. Make a request that would trigger audit logging (POST request). Segfault. 5. Reload apache again--no more segfaults! Probably a fluke. I think the resolution, for the Debian bug, is that apache must be restarted, not just reloaded after libapache-mod-security is installed. Or, based on my experiments, you could reload it twice. :-) Andrew Excerpts from Brian Rectanus's message of Sat Mar 20 14:51:16 -0700 2010: > Alberto Gonzalez Iniesta wrote: > > Hi, > > > > I got this [1] bug report about ModSecurity segfaulting. I couldn't > > reproduce it, it may be related to the arch of the reporter (x86_64). > > Please, feel free to write to the bug report (574...@bugs.debian.org) if > > you need further information. > > > > Thanks, > > > > Alberto > > > > > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574376 > > Normally a backtrace of the thread/process causing the core will show > something like this: > > #0 0x00007f05edc257d0 in ?? () > No symbol table info available. > #1 0x000000000044990d in ap_run_error_log () > No symbol table info available. > #2 0x0000000000448678 in log_error_core () > No symbol table info available. > #3 0x00000000004487a3 in ap_log_error () > No symbol table info available. > #4 0x000000000044f12a in sig_coredump () > No symbol table info available. > #5 <signal handler called> > No symbol table info available. > #6 0x00007f05edc257d0 in ?? () > No symbol table info available. > #7 0x000000000044990d in ap_run_error_log () > No symbol table info available. > > So I am thinking that this backtrace is not of the thread/process that > caused the segfault. > > Often if you upgrade/replace mod_security2.so on a running httpd you > will see this (repeating segfaults) until you RESTART httpd. This is my > best guess given the info here. In order to do more I need a backtrace > generated from a core. Can you configure Apache to dump core and > reproduce it? > > Make sure there is a core dump area with something like: > > CoreDumpDirectory /tmp > > Make sure limits are set to dump core: > > ulimit -c unlimited > > Restart and trigger the error. A core file should be in the directory > you specified. > > Then use gdb to get a backtrace: > > 1) gdb /path/to/httpd /path/to/core > 2) within gdb enter: > > thread apply all bt full > > You can get it into a file with something like: > > gdb /path/to/httpd /path/to/core --batch --quiet \ > -ex "thread apply all bt full" > backtrace.log > > See also: http://httpd.apache.org/dev/debugging.html > > Other issues may be what MPM use used. There may be some issues with > mod_security that was compiled with prefork Apache without threads in > APR and then installed in an httpd with worker MPM (or vice versa). > Alberto, can you shed some light here? > > Also, if it truly is failing around the global mutex lock, then you can > avoid this by changing from the default Serial logging (which locks) to > the non-locking Concurrent type: > > SecAuditLogType Concurrent > > If this fixes the issue, then I'd really want a proper backtrace so I > can look into that further. ;) > > thanks, > -B > > -- > Brian Rectanus > Breach Security > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
