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
