httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@worldgate.com>
Subject Re: segfaults on CGI's with current CVS snapshot
Date Mon, 04 Aug 1997 21:35:49 GMT
On Mon, 4 Aug 1997, Dean Gaudet wrote:

> Hmm, I haven't touched file_walk yet ... at least I don't remember
> touching it. 
> 
> Is that built with just -g, or -O as well?  'cause -O can cause locals to

-O2.  'dat's the default.  Sigh.  

> appear screwy.  (Heaven knows why nobody has caught up to the work that a
> bunch of people put into the DWARF standard about 5 years ago to allow an
> optimizer to tell the debugger where to find the value of a variable
> throughout the subroutine... there's a cool state machine in DWARF
> debugging output.) 
> 
> Maybe one of the things I did isn't safe across a fork().
> 
> And finally ... you've done a "make clean" and a full rebuild right?

Yup.  Tracking it further, it started between 25 and 30 days ago.  Isn't
cvs great.  Still looking...

> 
> Dean
> 
> On Mon, 4 Aug 1997, Marc Slemko wrote:
> 
> > Ok, removing the signal handler to avoid the extra cruft in the
> > core (I have been meaning to make a define that does that...):
> > 
> > #0  0xaffe in file_walk (r=0xd4034) at http_request.c:544
> > 544                 entry_config = file[j];
> > (gdb) bt
> > #0  0xaffe in file_walk (r=0xd4034) at http_request.c:544
> > #1  0xb1f0 in sub_req_lookup_uri (new_file=0x95cc4 "/docs", r=0xcf074)
> >     at http_request.c:660
> > #2  0x13128 in add_cgi_vars (r=0xcf074) at util_script.c:298
> > #3  0x275e4 in cgi_child (child_stuff=0xefbfb7e8) at mod_cgi.c:298
> > #4  0x20ae in spawn_child_err_core (p=0x9400c, func=0x275c4 <cgi_child>, 
> >     data=0xefbfb7e8, kill_how=kill_after_timeout, pipe_in=0xefbf9790, 
> >     pipe_out=0xefbf978c, pipe_err=0xefbf9788) at alloc.c:1222
> > #5  0x2272 in spawn_child_err_buff (p=0x9400c, func=0x275c4 <cgi_child>, 
> >     data=0xefbfb7e8, kill_how=kill_after_timeout, pipe_in=0xefbfb7e4, 
> >     pipe_out=0xefbfb7e0, pipe_err=0xefbfb7dc) at alloc.c:1303
> > #6  0x279bb in cgi_handler (r=0xcf074) at mod_cgi.c:414
> > #7  0x8db7 in invoke_handler (r=0xcf074) at http_config.c:409
> > #8  0xba89 in process_request_internal (r=0xcf074) at http_request.c:1033
> > #9  0xbac7 in process_request (r=0xcf074) at http_request.c:1049
> > #10 0x4695 in child_main (child_num_arg=0) at http_main.c:2369
> > #11 0x4836 in make_child (s=0x7b034, slot=0) at http_main.c:2472
> > #12 0x4888 in startup_children (number_to_start=1) at http_main.c:2497
> > #13 0x4cd0 in standalone_main (argc=3, argv=0xefbfd958) at http_main.c:2671
> > #14 0x5173 in main (argc=3, argv=0xefbfd958) at http_main.c:2856
> > (gdb) print file
> > $1 = (core_dir_config **) 0x0
> > (gdb) print num_files
> > $3 = 503820
> > 
> > num_files don't quite look right.
> > 
> > I would be tempted to say it looks like one of Dean's optimizations, but
> > I tried backing out a couple of things without finding it yet...
> > 
> > On Mon, 4 Aug 1997, Marc Slemko wrote:
> > 
> > > Freaky.  Note that 4 == sizeof(lots of things).
> > > 
> > > I copied your config files over and figured out that if I removed enough
> > > Location directives from access.conf it worked.
> > > 
> > > Freaky.  
> > > 
> > > On Mon, 4 Aug 1997, Brian Behlendorf wrote:
> > > 
> > > > Nope.  Even completely compiling out mod_alias and mod_rewrite, the problem
> > > > persists.  
> > > > 
> > > > It's not particular to the script, as even printenv will fail (i.e.
> > > > http://www.apache.org:8080/~brian/printenv/docs).  It will fail anytime
> > > > a PATH_INFO that matches an existing directory under the vhost's doc root
> > > > which is - get this - exactly four letters long.  Not 3, not 5.  WTF?
 I
> > > > can't find any other correlation except for the length, and I can't find
> > > > another length that causes this problem.  
> > > > 
> > > > 	Brian
> > > > 
> > > > 
> > > > --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> > > > "Why not?" - TL           brian@organic.com - hyperreal.org - apache.org
> > > > 
> > > 
> > 
> > 
> 


Mime
View raw message