httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Edmundsson <ni...@acc.umu.se>
Subject Re: httpd 2.2.8 + mod_cache segfaults
Date Wed, 20 Feb 2008 19:01:22 GMT
On Wed, 20 Feb 2008, Plüm, Rüdiger, VF-Group wrote:

>> Anyone seen something similar? Any hints on where to dig?
>
> From what I can see in the stack trace frame #4 points to the NULL pointer.

OK, I thought that one looked fishy ;)

> Looks like there is no copy function set for the particular bucket 
> type that gets processesd (not even the default one 
> (apr_bucket_copy_notimpl) that returns APR_ENOTIMPL).
>
> So please try the following:
>
> frame 5
> dump_brigade bb
> dump_bucket ec

Neato! I had totally missed the .gdbinit with its goodness lurking in 
the httpd source directory.

The ec variable has been killed by the compiler though, so no such 
luck.

> This should give a hint which bucket / bucket type fails and should give
> hints how to proceed further.

Not surprisingly, the culprit is my DISKCACHE bucket type. Obviously 
something in httpd core has changed that triggers new and exiting bugs 
in my code (ie. functions that was never called previously ;)

The DISKCACHE bucket (which is a hacked FILE bucket, essentially it 
tracks the cachefile EOF and transforms into FILE buckets as it gets 
cached) uses apr_bucket_shared_split and apr_bucket_shared_copy, and 
that's probably dead wrong. I wouldn't expect the end result be a null 
function pointer though, and I see no hints of that:

(gdb) dump_brigade bb
dump of brigade 0xb4124ad8
    | type     (address)    | length | data addr 
---------------------------------------------------
  0 | FILE     (0x08204620) | 3932160 | 0x08204678
  1 | DISKCACHE(0x08204780) | 145678336 | 0x08204728
  2 | DISKCACHE(0x08204990) | 928063488 | 0x08204728
  3 | DISKCACHE(0x082047d8) | 1073741824 | 0x08204728
  4 | DISKCACHE(0x08204830) | 70873087 | 0x08204728
  5 | DISKCACHE(0x08204938) | 1002868737 | 0x08204728
  6 | DISKCACHE(0x08204888) | 1073741824 | 0x08204728
  7 | DISKCACHE(0x082046d0) | 145678336 | 0x08204728
  8 | EOS      (0x082048e0) | 0      | 0x00000000
end of brigade

(gdb) print *bb->list.next->link.next->type
$16 = {name = 0xb7ca5e04 "DISKCACHE", num_func = 5,
   is_metadata = APR_BUCKET_DATA,
   destroy = 0xb7ca26c0 <diskcache_bucket_destroy>,
   read = 0xb7ca2700 <diskcache_bucket_read>,
   setaside = 0xb7ca25b0 <diskcache_bucket_setaside>,
   split = 0x806420c <apr_bucket_shared_split@plt>,
   copy = 0x806451c <apr_bucket_shared_copy@plt>}

To be honest, I had a hard time figuring out what the setaside, split 
and copy functions really should do and ended up randomly hacking 
until the thing worked at the time and haven't touched the buckets 
since. Pointers to docco/code that actually explains what they're 
supposed to do would be appreciated.

Or, to be blunt: Explain it like you would to a three-year-old ;)

In any case, I should probably try to figure out how to reproduce this 
thing. All coredumps I've looked at have been when serving DVD images, 
which of course works flawlessly when I try it...

/Nikke - appreciates the possibilities given by the bucket brigades,
          but definately not getting the complete picture...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se      |     nikke@acc.umu.se
---------------------------------------------------------------------------
  "I am the toddler that naps in the night! ...Huh???" - Darkwing Duck
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Mime
View raw message