The first exception is pretty normal. When two Tubs in the same process are shut down (such as at the end of a unit test), they drop references, which triggers the cross-Tub GC messages, which may be delivered after the other end has forgotten about the object being decref'ed. It's harmless, although it'd be a good idea for Foolscap to tolerate them silently: fixed in [8d1ca85].
The second one is probably similar. It indicates that a message was sent to a local object which had gone out-of-scope by the time the message was processed. The object in question was the first one allocated (clid=1, since 0 is used for the Broker itself, for remote_decref), which (if this is a storage server) is probably the RIStorageServer instance (whatever object was the target of the first inbound getReference() call).
That sort of problem *ought* to be handled by returning an error message to the remote caller, not with log.err(). The requestID is the very first token in the CALL sequence, so we know who to send the error to. I think it's a bug/oversight in call.py which allows that error to escape, and worth fixing.
