Re: Runaway httpd process (fwd)

[Dean Gaudet <dg...@arctic.org>]

You may wish to link with "-warn-common" if you can, that's a gnu ld
option, but there's probably a similar one for solaris ld.  Or try
compiling with "-Wshadow" under gcc.  You'll get some shadowing warnings
in pthreads.h, but that's solaris header file lameness.

What you're looking for is one of the symbols in sfio that's being
resolved by something in apache, when it shouldn't be.

Another way to do this is to use nm to list the imported symbols in
libsfio, and see if any of them match the exported symbols in apache. 

Dean

On Mon, 27 Oct 1997, Jonathan Roy wrote:

> 
>   Got another one of these, same spot (although in mmap this time). Just
> FYI. I assume your thought about it being an incompatibility with the sfio
> header is the culprit and I'll try to avoid that problem whenever I can get
> 1.3b2 running. (My fastcgi stuff won't work right, so I'm still trapped at
> the 1.2.x level.) If someone has time to spend on it, maybe they can
> investigate possible weird sfio interactions with Apache. Anyways, just
> thought I'd let you know it happened against as an additional data point. :)
> 
>   Thanks,
> 
> -Jonathan
> 
> (gdb) where
> #0  0xef5f6620 in mmap ()
> #1  0xef66a9a0 in sfrd (f=0x195a40, buf=0x0, n=65172, disc=0x0) at sfrd.c:139
> #2  0xef664698 in _sffilbuf (f=0x195a40, n=-1) at sffilbuf.c:66
> #3  0xef66b24c in sfread (f=0x195a40, buf=0xefff11e8, n=8192) at sfread.c:70
> #4  0xef6a1df4 in fread (buf=0xefff11e8, size=1, nmem=8192, fp=0x195200)
>     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
> 
> At 10:37 AM 10/22/97 -0400, Doug MacEachern wrote:
> >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 <ro...@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.
> >> 
> >> 
> >
> >
> 
> --
> Jonathan Roy - roy@idle.com - Idle Communications, Inc.
>