On 2014-05-28 05:47, Bert Huijben wrote:
I'm guessing these patches (r2361 fixes a stupid compilation error
introduced in r2360) fix the problem. They fix the segfault I could
reproduce while trying here.
I'm having a cold right now, which is still affecting my coding
quality, so
I would like some confirmation from others before calling this problem
completely fixed.
For testing my case, I did this in outgoing.c using your macro and have
done a big bunch of test runs:
/*************************************************************************/
if (SERF_BUCKET_READ_ERROR(status)) {
if (APR_STATUS_IMPLIES_HANGUP(status)) {
fprintf(stderr, "crash ahead (status: %ld)\n", (long) status);
getchar();
}
/* Report the request as 'died'/'cancelled' to the application */
(void)(*request->handler)(request,
/*************************************************************************/
Whenever the macro triggers, I get a segfault (or, to put it another
way,
whenever I don't get a segfault, the macro doesn't trigger). So it's
stable for me in at least one direction -- I don't get any false
positives.
The only thing that may be a problem is a segfault without the macro
triggering -- a false negative. I say this because I (stupidly?)
believed
that FreeBSD's support for the POLLHUP poll() event meant I didn't
have to check APR_STATUS_IS_ECONNRESET(status) or
APR_STATUS_IS_ECONNABORTED(status), so my first instance of debug
code had only
if (status == SERF_ERROR_REQUEST_LOST) { ... }
With this, there was one and only one case in which I got a segfault
without the test triggering. This segfault occurred at the same code
point as the other segfaults, but I didn't get to check 'status'. It's
possible it was ECONNRESET or ECONNABORTED (maybe related to some
non-poll event), but I can't be sure.
Since adding the new debug code, every segfault has been associated with
SERF_ERROR_REQUEST_LOST (120102 or whatever it is), so at least svn
is usable now in my case.
I'll get the FreeBSD users in this forum thread to test your fix:
http://forums.freebsd.org/viewtopic.php?f=43&t=46620
If it seems to do the trick, I can send it to the freebsd-ports mailing
list and the port maintainer for wider testing. I've noticed the trunk
version of outgoing.c diverges a fair bit from the 1.3.5 version, but
from what I can tell, a 1.3.5 patch based on your fix ought to keep
1.3.5 afloat until 1.3.6 comes along.
You've been awesome! Hope you get well soon.
