Grisha wrote .. > > On Sun, 29 Jan 2006, Graham Dumpleton wrote: > > > Grisha wrote .. > >> > >> buffer = bufsize; > >> > > > > I suspect you mean't: > > > > buffer += bufsize; > > buffer = bufsize should be correct because you move the pointer to the > end > of where the bufer was. buffer += bufsize would set it further than you > need it.
"buffer" is a char* pointer, specifically the character string buffer inside of the Python string object. "bufsize" is an integer (long) representing the number of bytes read so far. "buffer" is set on the line before that to the start of the internal buffer of the newly resized Python string object. To get to where the next lot of data to be read into, that buffer pointer has to be offset by the number of bytes. Assiging long of bufsize to char* isn't going to work. Thus, still think it is: buffer += bufsize; > > 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. > > The first thing I'd check is for validity of b. Buckets use reference > counting much like Python, so sometimes it's possible for a bucket to > "self-distruct". Starting to delve into the bucket now. Haven't looked at reference count stuff yet, but the b->type object seems to be bogus. This is where the read() function pointer is kept and since it is a bad value it is why it dies. Graham
