httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: 2.0.26 was in production briefly tonight
Date Fri, 19 Oct 2001 18:41:04 GMT
"William A. Rowe, Jr." wrote:
> 
> From: "Greg Ames" <gregames@remulak.net>
> Sent: Thursday, October 18, 2001 8:39 PM
> 
> > I captured 3 dumps in /usr/local/apache2.0.26-debug/corefiles.  All of
> > them look pretty much the same.  Here's the backtrace from one.
> 
> Fixed.

Well, I have good news and bad news.

The good news is that I figured out how to recreate the seg faults.  All
three of the dumps last night were for requests to
http://xml.apache.org/cocoon/dist .  If I bring up the server fresh, hit
it with this URL from Netscape, it works.  It's just a distribution
directory, served by autoindex, which looks pretty much like ours except
it has .jar files and cute icons. 

But if I scatter a few of these URLs in my log replay input file, or
manually hit the server with this URL after it has run a bunch of
traffic, I still get seg faults even after the latest core.c fix. 
/usr/local/apache2.0.26-debug/corefiles/httpd.core.6 looks like the
dumps from last night; httpd.core.5 is slightly different:

#0  0x280bb871 in apr_array_cat (dst=0x81d3494, src=0x0) at
apr_tables.c:142
                                                     ^            
                                                     |--- whoa, what's
this?
                                                                         
|
                                                                         
v
#1  0x280bb9d6 in apr_array_append (p=0x81cd00c, first=0x8158b84,
second=0x0)
    at apr_tables.c:209
#2  0x806fe28 in merge_core_dir_configs (a=0x81cd00c, basev=0x8158b24,
    newv=0x81cdd00) at core.c:286
#3  0x8063217 in ap_merge_per_dir_configs (p=0x81cd00c, base=0x8158a74,
    new_conf=0x8144a5c) at config.c:262
#4  0x8075e5a in ap_directory_walk (r=0x81cd03c) at request.c:937
#5  0x8073264 in core_map_to_storage (r=0x81cd03c) at core.c:2622
#6  0x80745cf in ap_run_map_to_storage (r=0x81cd03c) at request.c:109
#7  0x8074f31 in ap_process_request_internal (r=0x81cd03c) at
request.c:175
#8  0x8060519 in ap_process_request (r=0x81cd03c) at http_request.c:284
#9  0x805c2b6 in ap_process_http_connection (c=0x8128114) at
http_core.c:289
#10 0x806b423 in ap_run_process_connection (c=0x8128114) at
connection.c:82
#11 0x806b5e1 in ap_process_connection (c=0x8128114) at connection.c:219
#12 0x8061aa4 in child_main (child_num_arg=2) at prefork.c:830
#13 0x8061bfa in make_child (s=0x8095974, slot=2) at prefork.c:917
#14 0x8061c6e in startup_children (number_to_start=50) at prefork.c:940
#15 0x8062074 in ap_mpm_run (_pconf=0x809500c, plog=0x80ce00c,
s=0x8095974)
    at prefork.c:1156
#16 0x806746d in main (argc=3, argv=0xbfbffbc0) at main.c:432
#17 0x805be81 in _start ()

If you are going to gdb these, stick with httpd.core.5 and .6.  These
are with the core.c change on.  gdb will no doubt complain about the
others now.

Greg

Mime
View raw message