Opened 16 years ago

Closed 16 years ago

Last modified 16 years ago

#36 closed defect (fixed)

exception: "ConnectionDone instance has no attribute 'getTraceback'"

Reported by: Brian Warner Owned by:
Priority: critical Milestone: 0.2.2
Component: negotiation Version: 0.2.1
Keywords: Cc:

Description

Sigh. The problem that broke 0.2.0 (discovered mere minutes after its release) is still present in 0.2.1. One of the changes in 0.2.0 was to give more information to pending remote method calls which fail because the connection is lost: code was added to hand a relevant Failure object to these calls so their errbacks would see ConnectionDone? or ConnectionClosed? with a message like "duplicate connection closed by remote end" rather than something more generic.

The bug is that connectionList is specified to take a Failure instance, but in certain circumstances a bare Exception is passed in instead. When a bare exception appears as the argument to errback(), the code which attempts to extract a stack trace from the exception fails (that's what Failures are for). I fixed some of these to release 0.2.1; apparently I didn't fix all of them.

The symptom is an exception that looks like the following:

        --- <exception caught here> ---
          File "/usr/lib/python2.4/site-packages/foolscap/eventual.py", line 26, in _turn
            cb(*args, **kwargs)
          File "/usr/lib/python2.4/site-packages/foolscap/call.py", line 77, in fail
            stack = why.getTraceback()
        exceptions.AttributeError: ConnectionDone instance has no attribute 'getTraceback'

Change History (4)

comment:1 Changed 16 years ago by Brian Warner

Sometimes the exception looks like this instead:

exceptions.AttributeError: 'ConnectionDone' object has no attribute 'getTraceback'

I found at least one problem, which would only be triggered on the slave-side of a connection. In addition, the problem only surfaces if logRemoteFailures is turned on, since that's the place where we try to extract the traceback so we can dump it to the logs. This combination probably explains why it wasn't caught by the unit tests, and why it only happens intermittently elsewhere.

comment:2 Changed 16 years ago by Brian Warner

.. and in looking more closely, it appears that I'm calling loseConnection() with non-Failures all over the place.

comment:3 Changed 16 years ago by Brian Warner

Resolution: fixed
Status: newclosed

This ought to be fixed by the new 0.2.2 release.

comment:4 Changed 16 years ago by Brian Warner

Milestone: undecided0.2.2
Version: 0.1.70.2.1
Note: See TracTickets for help on using tickets.