after I upgrade my linux to redhat 8.0 I got this error: [root@beta proc]# tail -f /var/log/httpd/error_log [Tue Nov 19 17:01:38 2002] [notice] child pid 3654 exit signal Segmentation fault (11) [Tue Nov 19 17:01:38 2002] [notice] child pid 3637 exit signal Segmentation fault (11) [Tue Nov 19 17:01:39 2002] [notice] child pid 3651 exit signal Segmentation fault (11) [Tue Nov 19 17:01:39 2002] [notice] child pid 3631 exit signal Segmentation fault (11) [Tue Nov 19 17:01:40 2002] [notice] child pid 3657 exit signal Segmentation fault (11) [Tue Nov 19 17:01:40 2002] [notice] child pid 3652 exit signal Segmentation fault (11) [Tue Nov 19 17:01:40 2002] [notice] child pid 3647 exit signal Segmentation fault (11) [Tue Nov 19 17:01:41 2002] [notice] child pid 3698 exit signal Segmentation fault (11) [Tue Nov 19 17:01:41 2002] [notice] child pid 3655 exit signal Segmentation fault (11) [Tue Nov 19 17:01:42 2002] [notice] child pid 3656 exit signal Segmentation fault (11) this happens all of the time.. when I run the 'top' command, sometimes I can see the httpd processes using 99% of CPU time (less than 5 second) and after that more one error line...
Please post a backtrace from a core dump created by one of the segfaulting child processes. Thanks!
the Segmentation fault doesn't generate a core dumped file... can I force it to make one?
Use the CoreDumpDirectory directive and specify a directory that is writable by the Apache child processes and has sufficient disk space. See http://httpd.apache.org/docs-2.0/mod/mpm_common.html#coredumpdirectory for exact details of this directive. After you get a core dump, use gdb /path/to/httpd /path/to/core (gdb) where <backtrace displayed here by gdb> (gdb) quit to get a backtrace.
I follow your steps, I set the CoreDumpDirectory to /tmp directory and I have sufficient disk space. but the core file doesn't generate.. I'm trying set the LogLevel to debug.. [Wed Nov 20 09:51:17 2002] [info] mod_unique_id: using ip addr 10.0.0.2 [Wed Nov 20 09:51:18 2002] [notice] Apache/2.0.40 (Red Hat Linux) configured -- resuming normal operations [Wed Nov 20 09:51:18 2002] [info] Server built: Sep 4 2002 17:20:34 [Wed Nov 20 09:51:18 2002] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem) [Wed Nov 20 09:52:20 2002] [notice] child pid 7884 exit signal Segmentation fault (11) [Wed Nov 20 09:52:20 2002] [notice] child pid 7883 exit signal Segmentation fault (11) [Wed Nov 20 09:52:20 2002] [notice] child pid 7882 exit signal Segmentation fault (11) my httpd.conf is ok [root@beta tmp]# httpd -t Syntax OK more one tip? thanks
Wow, I'm not accustomed to having problems getting core dumps with non-threaded programs on Linux :( Here is an uglier way to get a backtrace... apachectl stop (if not already stopped) gdb /path/to/httpd (gdb) r -DONE_PROCESS let it run until it segfaults; hopefully it will still segfault in this mode, at which point gdb will regain control (gdb) where If this doesn't work, the next step would be to comment out the LoadModule directives for various modules and see if a module is segfaulting and which one it is. You might open a PR with RedHat too since it appears that you are using RedHat's build of Apache. Surely they would understand any nuances of getting core dumps with the kernel they ship.
okey Jeff, the "ugly" mode works, here is the full steps: --- [root@beta /]# /etc/init.d/httpd stop Stopping httpd: [ OK ] [root@beta /]# gdb /usr/sbin/httpd GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 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 "i386-redhat-linux"...(no debugging symbols found)... (gdb) r -DONE_PROCESS Starting program: /usr/sbin/httpd -DONE_PROCESS [New Thread 8192 (LWP 8704)] Program received signal SIGPIPE, Broken pipe. [Switching to Thread 8192 (LWP 8704)] 0x4038f2a4 in writev () from /lib/libc.so.6 (gdb) where #0 0x4038f2a4 in writev () from /lib/libc.so.6 #1 0x402259ce in apr_sendv () from /usr/lib/libapr.so.0 #2 0x08078555 in writev_it_all () #3 0x08079893 in core_output_filter () #4 0x0807169c in ap_pass_brigade () #5 0x0805decf in chunk_filter () #6 0x0807169c in ap_pass_brigade () #7 0x08073e6a in ap_content_length_filter () #8 0x0807169c in ap_pass_brigade () #9 0x4056af0f in completed.1 () from /etc/httpd/modules/libphp4.so #10 0x405772a5 in completed.1 () from /etc/httpd/modules/libphp4.so #11 0x40576919 in completed.1 () from /etc/httpd/modules/libphp4.so #12 0x4056dca6 in completed.1 () from /etc/httpd/modules/libphp4.so #13 0x4055f50f in completed.1 () from /etc/httpd/modules/libphp4.so #14 0x4055f492 in completed.1 () from /etc/httpd/modules/libphp4.so #15 0x4055f117 in completed.1 () from /etc/httpd/modules/libphp4.so #16 0x4055294f in completed.1 () from /etc/httpd/modules/libphp4.so #17 0x405606b6 in completed.1 () from /etc/httpd/modules/libphp4.so #18 0x4056ef7a in completed.1 () from /etc/httpd/modules/libphp4.so #19 0x4056b7bd in completed.1 () from /etc/httpd/modules/libphp4.so #20 0x0807169c in ap_pass_brigade () #21 0x08078e27 in default_handler () #22 0x08065bf5 in ap_run_handler () #23 0x0806620d in ap_invoke_handler () #24 0x080629c6 in ap_process_request () #25 0x0805e0ac in ap_process_http_connection () #26 0x0806f0d5 in ap_run_process_connection () #27 0x08064238 in child_main () #28 0x0806445a in make_child () #29 0x080644b6 in startup_children () #30 0x08064cdf in ap_mpm_run () #31 0x0806ac5f in main () #32 0x402dd4ce in __libc_start_main () from /lib/libc.so.6 (gdb) ----------------------------------
I'm really sorry, but I neglected the following critical instruction: If you see a message like "Program received signal SIGPIPE, Broken pipe." then you need to use the continue command (gdb) cont to proceed to the code that segfaulted. SIGPIPE is normal behavior, but it interrupts the debug process and you need to continue at that point to hit the problem. So try again but run "cont" when you see the SIGPIPE message. Sorry!!!! (By the way, this sounds like another problem reported recently that was identified as a PHP issue. I bet that if you comment out the LoadModule for php it won't segfault anymore.)
okey jeff, no problem ;) now here is the output: ------------------ [root@beta var]# gdb /usr/sbin/httpd GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 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 "i386-redhat-linux"...(no debugging symbols found)... (gdb) r -DONE_PROCESS Starting program: /usr/sbin/httpd -DONE_PROCESS [New Thread 8192 (LWP 17452)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 17452)] 0x40350982 in strcasecmp () from /lib/libc.so.6 (gdb) (gdb) where #0 0x40350982 in strcasecmp () from /lib/libc.so.6 #1 0x40235ae5 in overlap_hash () from /usr/lib/libapr.so.0 #2 0x40235df3 in apr_table_overlap () from /usr/lib/libapr.so.0 #3 0x0807db3e in ap_add_common_vars () #4 0x406546c1 in completed.1 () from /etc/httpd/modules/libphp4.so #5 0x0807169c in ap_pass_brigade () #6 0x40b732a8 in handle_include () from /etc/httpd/modules/mod_include.so #7 0x40b760bb in send_parsed_content () from /etc/httpd/modules/mod_include.so #8 0x40b76a80 in includes_filter () from /etc/httpd/modules/mod_include.so #9 0x0807169c in ap_pass_brigade () #10 0x08078e27 in default_handler () #11 0x08065bf5 in ap_run_handler () #12 0x0806620d in ap_invoke_handler () #13 0x0807d51a in ap_run_sub_req () #14 0x40b7311e in handle_include () from /etc/httpd/modules/mod_include.so #15 0x40b760bb in send_parsed_content () from /etc/httpd/modules/mod_include.so #16 0x40b76a80 in includes_filter () from /etc/httpd/modules/mod_include.so #17 0x0807169c in ap_pass_brigade () #18 0x40bd74e9 in handle_map_file () from /etc/httpd/modules/mod_negotiation.so #19 0x08065bf5 in ap_run_handler () #20 0x0806620d in ap_invoke_handler () #21 0x08062f31 in ap_internal_redirect () #22 0x080629ac in ap_process_request () #23 0x0805e0ac in ap_process_http_connection () #24 0x0806f0d5 in ap_run_process_connection () #25 0x08064238 in child_main () #26 0x0806445a in make_child () #27 0x080644b6 in startup_children () #28 0x08064cdf in ap_mpm_run () #29 0x0806ac5f in main () #30 0x402f14ce in __libc_start_main () from /lib/libc.so.6 (gdb) -----------------------------
try # ulimit -c # ulimit -c unlimited # ulimit -c before starting it. I'm guessing you had it set to zero
you're right Ian, it was setting to 0 I execute "ulimit -c unlimited" but.. the errors still flooding me ------------- [Wed Nov 20 15:25:04 2002] [notice] child pid 11219 exit signal Segmentation fault (11) [Wed Nov 20 15:25:04 2002] [notice] child pid 11218 exit signal Segmentation fault (11) [Wed Nov 20 15:25:04 2002] [notice] child pid 11217 exit signal Segmentation fault (11) [Wed Nov 20 15:25:05 2002] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 8 children, there are 2 idle, and 3 total children -------------
I replied to the bug a bit too quickly, and didn't see that jeff had got you to do the 'ugly' method, and had a backtrace to work off. the 'tip' was only to generated core files, not to fix the problem... sorry for the confusion.
no problem Ian, I'm waiting the jeff "light" heh :)
Hello, I did some tests, and I think that is error is solved. look the content of file conf.d/php.conf <Files *.php> SetOutputFilter PHP SetInputFilter PHP LimitRequestBody 524288 </Files> this means that my php script can't have more than 5k ? my index.php have 3k, and if I test with lynx http://localhost the "[notice] child pid 3654 exit signal Segmentation fault (11)" flood me but if I delete that line: "LimitRequestBody 524288" the errors stop!! I don't know nothing about development, but this solved my problem.. what to you think about this? thanks for all the help
please discard my last message, two hours later the errors come back... sorry
My first suggestion is to get on the PHP list, show them the backtrace, tell them your PHP and Apache versions, and get opinions on the likelihood that such a problem is already fixed in their next release. If that is not fruitful, this needs to be debugged on the latest Apache and PHP code with a debug build (i.e., with symbols).
ok with apache 2.0.43 and php 4.3.0_RC1 works perfect! thanks Jeff
please Flavio . i have the same problem child pid.... and i'm an amateur , please send me how can i fix this problem like you did and thank you .