Grisha wrote .. > > On Sun, 29 Jan 2006, Jim Gallacher wrote: > > > I don't know if this is the answer to the problem, but it looks like > a bug > > anyway. In connobject.c starting at line 133: > > > > /* time to grow destination string? */ > > if (len == 0 && bytes_read == bufsize) { > > > > _PyString_Resize(&result, bufsize + HUGE_STRING_LEN); > > buffer = PyString_AS_STRING((PyStringObject *) result); > > buffer += HUGE_STRING_LEN; > > bufsize += HUGE_STRING_LEN; > > } > > > > > > It looks like we've just set the buffer pointer to an address somewhere > > inside the buffer. That can't be good. The buffer pointer should be set > to > > the bytes_read position. > > ...or bufsize. Of course they are the same, but I think this would read > cleaner: > > if (len == 0 && bytes_read == bufsize) { > > _PyString_Resize(&result, bufsize + HUGE_STRING_LEN); > buffer = PyString_AS_STRING((PyStringObject *) result); > buffer = bufsize; > bufsize += HUGE_STRING_LEN; > } > > This bug would garble the data if it's at least twice HUGE_STRING_LEN, > since the first time around the code would work OK because bufsize would > equal HUGE_STRING_LEN.
I suspect you mean't: if (len == 0 && bytes_read == bufsize) { _PyString_Resize(&result, bufsize + HUGE_STRING_LEN); buffer = PyString_AS_STRING((PyStringObject *) result); buffer += bufsize; bufsize += HUGE_STRING_LEN; } Anyway, this change doesn't help with Mac OS X as it doesn't even get invoked. Unlike suggestions by someone else that "self" seemed to be getting corrupted, it looks fine to me, and code simply crashed down in: apr_bucket_read(b, &data, &size, APR_BLOCK_READ) on very first call to it. Thus need to start tracking into Apache itself and see what there may be about bucket structures that isn't correct. This is where I got to last time before I gave up, feeling it wasn't worth the effort at the time. I'll try and build a version of Apache with debug so I can get a better stack trace. Graham