subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: svn 1.8.9 checkout crashes (debugging details provided)
Date Wed, 28 May 2014 20:39:57 GMT
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 (APR_STATUS_IMPLIES_HANGUP(status)) {
         fprintf(stderr, "crash ahead (status: %ld)\n", (long) status);
     /* Report the request as 'died'/'cancelled' to the application */

Whenever the macro triggers, I get a segfault (or, to put it another 
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 

The only thing that may be a problem is a segfault without the macro
triggering -- a false negative. I say this because I (stupidly?) 
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:

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.

View raw message