httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philip M. Gollucci" <>
Subject Re: Endless loop in split_on_bdry() of library/parser_multipart.c?
Date Wed, 31 May 2006 09:18:31 GMT
> Thanks for your help. I'll see I go with GDB first. If I get nowhwere, 
> I'll try the .t.
Looking at library/parser_multipart.c and associated tests t/parsers.c ->
we definetely exercise that code block sucessfully.

If you copy httpd's .gdbinit file you can make use of
dump_brigade in
dump_brigade out
dump_bucket e
dump_bucket f

from within gdb, but I'm betting you are already using them since you're 
using gdb.

static apr_status_t split_on_bdry(apr_bucket_brigade *out,
                                   apr_bucket_brigade *in,
                                   const apr_strmatch_pattern *pattern,
                                   const char *bdry)

     apr_bucket *e = APR_BRIGADE_FIRST(in);
     apr_size_t blen = strlen(bdry), off = 0;

------> line ~121   while ( e != APR_BRIGADE_SENTINEL(in) ) {

or better yet, at your problem source:

      do {
                 apr_bucket *f = APR_BRIGADE_FIRST(in);
                 APR_BRIGADE_INSERT_TAIL(out, f);
-----> line ~171            } while (e != APR_BRIGADE_FIRST(in));

and send a
bt full
with the dump_* commands from above after it gets stuck.

maybe something will jump out.

I looked at your mod_spin module (1.0) in src/mod_spin.c where you call 
ap_discard_request_body.  Seems sane to me.

In one of the tests that hits this do {} while, I see this
(gdb) bt full

#0  split_on_bdry (out=0x81f9438, in=0x81f9458, pattern=0x81f8e38, 
bdry=0x81f8e29 "\r\n--AaB03x") at parser_multipart.c:171
         idx = 136287324
         len = 181
         buf = 0x804d7d0 "\n\r\n--AaB03x\r\ncontent-disposition: 
form-data; name=\"\"\r\ncontent-type: text/plain;\r\n 
quoted-printable\r\n\r\nJoe owes =80100.\r\n--AaB03x--\r\n"
         s = 136146624
         e = (apr_bucket *) 0x81d6e68
         blen = 10
         off = 1
#1  0x2807f6eb in apreq_parse_multipart (parser=0x81f8d88, t=0x81f8c10, 
bb=0x81f8da8) at parser_multipart.c:583
         param = (apreq_param_t *) 0x81f9998
         pool = (apr_pool_t *) 0x8063018
         ba = (apr_bucket_alloc_t *) 0x8075018
         ctx = (struct mfd_ctx *) 0x81f8dc8
         s = 5

This part confuses me why they are error buckets, let alone why that 
symbol isn't defined for me... but thats a goof on my part, that I'll 
have to figure out somehow.......  Interestly, I don't think any of them 
are none error buckets from tests 9 -> 494. (attached -verbose output)

(gdb) dump_bucket e
  bucket=IMMORTAL (0x081d6e68) length=181    data=0x0804d6a0
     No symbol "ap_bucket_type_error" in current context.
(gdb) dump_brigade in
dump of brigade 0x81f9458
    | type     (address)    | length | data addr  | contents 
    | rc
  0 | IMMORTAL (0x081d6e68) | 181    | 0x0804d6a0No symbol 
"ap_bucket_type_error" in current context.
(gdb) dump_brigade out
dump of brigade 0x81f9438
    | type     (address)    | length | data addr  | contents 
    | rc
  0 | IMMORTAL (0x081d6ec0) | 29     | 0x0804d6a0No symbol 
"ap_bucket_type_error" in current context.

Time for sleep.

Philip M. Gollucci ( 323.219.4708
Consultant /
Senior Software Engineer - TicketMaster -
1024D/A79997FA F357 0FDD 2301 6296 690F  6A47 D55A 7172 A799 97F

"It takes a minute to have a crush on someone, an hour to like someone,
and a day to love someone, but it takes a lifetime to forget someone..."

View raw message