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
