httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@opengroup.org>
Subject Re: Runaway httpd process (fwd)
Date Wed, 22 Oct 1997 14:37:36 GMT
Looking at this hunk of the backtrace:

#1  0xef66a9a0 in sfrd (f=0x186ad0, buf=0x0, n=65478, disc=0x0) at sfrd.c:139
#2  0xef664698 in _sffilbuf (f=0x186ad0, n=-1) at sffilbuf.c:66
#3  0xef66b24c in sfread (f=0x186ad0, buf=0xefff1450, n=8192) at sfread.c:70
#4  0xef6a1df4 in fread (buf=0xefff1450, size=1, nmem=8192, fp=0x2080d8) at fread.c:24

It looks like you've configured Perl with sfio and apache has picked
up sfio's stdio.h, which re-defines fread() and other stdio
functions.  I'm not sure why it's breaking.  For a test, find your
sfio stdio.h and temporarily rename it or move it out of the way,
rebuild httpd/mod_perl and see what happens then.  I have not seen
this problem reported in the past.  If there's still trouble, please
send me your perl -V 

-Doug

> ---------- Forwarded message ----------
> Date: Fri, 17 Oct 1997 09:41:52 -0400
> From: Jonathan Roy <roy@atlantic.net>
> To: apache-bugs@apache.org
> Subject: Runaway httpd process
> 
> 
>   I can't reproduce this, but I've included all the info I can. Rarely (and
> I do mean rarely), a httpd will just start eating all the CPU it can get. I
> noticed one of those this morning. The file has 4 #include virtual=
> commands, one of which is an empty file. The isn't a circule include
> problem or anything like that. Also, new requests for this page work fine,
> it is just this single httpd that is messed up. I included the process line
> from top, from the status module, and a gdb stack trace.
> 
>   It is an Apache 1.2.3 setup running on Solaris 2.5.0. Has mod_php,
> mod_perl, mod_auth_mysql all compiled in (although the page where the
> problem happened has no php/perl/etc.) Some of the include files are
> recreated now and then, but I make them in /tmp then mv them into place,
> the odds of trying to load them while they are still 'open' is small, but
> perhaps that is what causes the problem. Anyways, here's the info:
> 
>   PID USERNAME PRI NICE  SIZE   RES STATE   TIME   WCPU    CPU COMMAND
> 23030 nobody    15    0 3784K 1616K run   307:02 33.50% 33.50% httpd1.2.3-php
> 
> 2 23030 0/4/24919 W 0.19 20568 0.0 0.01 297.26 137.158.128.16 t3.mpog.com
> GET /news.html HTTP/1.0
> 
> (gdb) where
> #0  0xef5f6620 in mmap ()
> #1  0xef66a9a0 in sfrd (f=0x186ad0, buf=0x0, n=65478, disc=0x0) at sfrd.c:139
> #2  0xef664698 in _sffilbuf (f=0x186ad0, n=-1) at sffilbuf.c:66
> #3  0xef66b24c in sfread (f=0x186ad0, buf=0xefff1450, n=8192) at sfread.c:70
> #4  0xef6a1df4 in fread (buf=0xefff1450, size=1, nmem=8192, fp=0x2080d8)
>     at fread.c:24
> #5  0x3a1f8 in send_fd_length ()
> #6  0x3a174 in send_fd ()
> #7  0x33e24 in default_handler ()
> #8  0x343ac in invoke_handler ()
> #9  0x36ce8 in run_sub_req ()
> #10 0x4a8ac in handle_include ()
> #11 0x4c7b4 in send_parsed_content ()
> #12 0x4cb20 in send_parsed_file ()
> #13 0x4cb8c in xbithack_handler ()
> #14 0x3430c in invoke_handler ()
> #15 0x371f0 in process_request_internal ()
> #16 0x37224 in process_request ()
> #17 0x30f64 in child_main ()
> #18 0x31148 in make_child ()
> #19 0x31924 in standalone_main ()
> #20 0x31d64 in main ()
> 
> -Jonathan
> 
> 
> --
> Jonathan Roy - roy@idle.com - Idle Communications, Inc.
> 
> 

Mime
View raw message