Hi James, On Fri, Aug 08, 2014 at 02:40:32PM +1200, James Dempsey wrote: > I have a few more details about this segfault: > > in http_request_forward_body(), msg->sov is taking on some silly values > that I've been unable to track down thus far. > > For example, I have observed msg->sov = -2147483520 at > src/proto_http.c:5485, which causes an underflow, eventually affecting the > value of msg->next, which in turn causes the segfault. Is anyone able to > help me understand how to track down where this value of msg->sov comes > from?
I've looked at your report and at your patch. I still don't get a clear picture of the bug, even less its cause, so as you can imagine, for now your patch looks a bit magic to me :-/ Just to help me, I found from the code location that in your case it's the client which is sending chunked contents to the server. What's the approximate average and max chunk sizes ? It's just so that I understand if we're accumulating a small error until it becomes positive or if we're making big steps. From the code location you changed, I don't see how it is possible for msg->sov to make a large step since we take the min of the request size (buf->i) and the chunk len. So I'm a bit puzzled. However I could imagine something very stupid : chunk_len is a long long while buf->i is an int, so the MIN() macro can make a stupid choice and that *might* be what really happens. Could you please try the following change to see if this is the case : - msg->sov -= msg->next + MIN(msg->chunk_len, req->buf->i); + msg->sov -= msg->next + MIN((long long)msg->chunk_len, (long long)req->buf->i); It's not the proper fix (the fix should be to fix the macro or the callers), but it should be enough for our test to confirm the issue comes from there in fact. Thanks a lot for your investigations, and sorry for the very late response (I'm currently in the process of moving and not reading the list very often I must confess). Willy
