httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <jwool...@virginia.edu>
Subject Re: segfault ap_save_brigage in the latest 2.0
Date Mon, 27 Sep 2004 03:30:22 GMT

Ouch.  This one kinda sucks.  Well done on the debugging dumps though...
you grabbed almost all of the things I was going to ask for.  :)

Let's see if I can make any sense of this.


> myfunc does:
>
>      bucket = apr_bucket_transient_create(buf, len, ba);
>      bb = apr_brigade_create(wb->pool, ba);
>      APR_BRIGADE_INSERT_TAIL(bb, bucket);
>      ap_pass_brigade(f, bb);

Seems reasonable.

> (gdb) source /home/stas/apache.org/httpd-2.0/.gdbinit
> (gdb) dump_bucket bucket
>   bucket=HEAP     (0x09544f98) length=1455   data=0x09545178
>       contents=[1..10~# Running u...] rc=1
> (gdb) dump_brigade bb
> dump of brigade 0x9554e78
>     | type     (address)    | length | data addr  | contents
>   | rc
> --------------------------------------------------------------------------------
> brigade is empty
> end of brigade

All this seems reasonable too.  Note that the transient bucket you created
has morphed into a heap bucket (as it ought to when you run save_brigade,
which calls setaside on all of the buckets -- and transient setaside does
a alloc-morph-memcpy onto the heap).

> (gdb) dump_brigade b
> dump of brigade 0xbfffebd4
>     | type     (address)    | length | data addr  | contents
>   | rc
> --------------------------------------------------------------------------------
>   0 | § (0xbfffebf8) | 156585592 | 0x405cbc18 | [**unknown**]          | n/a
>   1 | ÐÎl
>   (0xbfffec48) | 156585592 | 0x404edd4e | [**unknown**]          | n/a
>   2 | ÐÎl
>   (0xbfffec78) | 156585592 | 0x00000004 | [**unknown**]          | n/a
>   3 | ¨ (0xbfffecc8) | 156585592 | 0x080ead44 | [**unknown**]          | n/a
>   4 | ¨ (0xbfffecf8) | 156585592 | 0xbfffed9c | [**unknown**]          | n/a
>   5 |#
>   (0xbfffed68) | 156585592 | 0x00000000 | [**unknown**]          | n/a
>   6 |#
>   (0xbfffed98) | 156585592 | 0x4044d9fd | [**unknown**]          | n/a
>   7 | Cannot access memory at address 0x0

Yowzah.  Um yeah that's obviously bad.  :)

Looking at the ->prev pointer of b, it seems that the pointer there is way
out of range compared to the other pointer values you gave.  And brigade b
is obviously corrupt, so... yeah.  So the question is, at what point did
brigade b get corrupted.  The easiest way to find that out is to enable
brigade debugging -- that way, any time you do any manipulations to the
brigade that could potentially corrupt it, it will sanity-check the ring
pointers in both directions for you.  That way it will assert when the
corruption happens rather that some arbitrary time in the future, which is
what you're seeing here.

Hope this helps,
Cliff

Mime
View raw message