Permalink
Browse files

Disable assertion that is being hit and can be safely avoided.

Its not clear why we're sometimes hitting this, but we can just bail
on the connection callback since it's just indicating a failure
anyway. It's likely due to some issue in SessionManager but it wasn't
clear how it could occur since the apparently correct checks are
performed before triggering the callback.
  • Loading branch information...
1 parent 147facb commit d749bda8a1922249a0940dc1cd5aa8324443af80 @ewencp ewencp committed Sep 17, 2012
Showing with 10 additions and 1 deletion.
  1. +10 −1 liboh/src/HostedObject.cpp
@@ -671,7 +671,16 @@ void HostedObject::iHandleDisconnected(
if (cc == Disconnect::Forced)
self->disconnectFromSpace(spaceobj.space(), spaceobj.object());
if (cc == Disconnect::LoginDenied) {
- assert(self->mPresenceData.find(spaceobj)==self->mPresenceData.end());
+ // This:
+ //assert(self->mPresenceData.find(spaceobj) == self->mPresenceData.end());
+ // is failing sometimes. It really shouldn't since
+ //SessionManager should only invoke this if an outstanding
+ //connection request failed. Possible explanations:
+ //SessionManager is screwing up when there's a high
+ //latency/retries, or maybe we're somehow getting a proximity
+ //result (creating the mPresenceData entry) and a login error
+ //due to retries. See Issue #519.
+ if (self->mPresenceData.find(spaceobj) != self->mPresenceData.end()) return;
self->mObjectHost->unregisterHostedObject(spaceobj, self.get());
if (--self->mNumOutstandingConnections==0&&self->mDestroyWhenConnected) {
self->mDestroyWhenConnected=false;

0 comments on commit d749bda

Please sign in to comment.