Author Topic: Bug report: Phantom People Bug  (Read 1066 times)

Datalink

  • Underling
  • *
  • Posts: 3
  • Datalink Online.
Bug report: Phantom People Bug
« on: September 14, 2015, 09:21:52 PM »
Bug summary: Client doesn't check who's around when you exit and re-enter game.

Versions affected (observed): 0.98b, 0.99b

Trigger condition for bug: Exiting City of Heroes without closing Paragon Chat

Detailed description: Logging out of CoH and keeping Paragon Chat open causes people around you in Paragon Chat at game client logout to appear where they where despite moving when you log back into the game.

Suggested fixes: clear user position data on login before requesting initial character position from XMPP server.

Temporary fix: Close Paragon Chat after closing game client and re-launch when you want to return.

Edit: Updated with versions affected and a suggestion for how to get around the issue until a fix can be implemented properly.
« Last Edit: September 15, 2015, 06:49:02 AM by Datalink »

Datalink

  • Underling
  • *
  • Posts: 3
  • Datalink Online.
Re: Bug report: Phantom People Bug
« Reply #1 on: September 15, 2015, 06:48:08 AM »
Bug summary: Client doesn't check who's around when you exit and re-enter game.

Versions affected (observed): 0.98b, 0.99b

Trigger condition for bug: Exiting City of Heroes without closing Paragon Chat

Detailed description: Logging out of CoH and keeping Paragon Chat open causes people around you in Paragon Chat at game client logout to appear where they where despite moving when you log back into the game.

Suggested fixes: clear user position data on login before requesting initial character position from XMPP server.

Temporary fix: Close Paragon Chat after closing game client and re-launch when you want to return.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Bug report: Phantom People Bug
« Reply #2 on: September 15, 2015, 02:18:17 PM »
Detailed description: Logging out of CoH and keeping Paragon Chat open causes people around you in Paragon Chat at game client logout to appear where they where despite moving when you log back into the game.

Suggested fixes: clear user position data on login before requesting initial character position from XMPP server.

Do you have any other steps in your reproduction process, or anything in the environment that may be relevant?

Proxy entity teardown is something that is already supposed to happen when you log out. I've heard a couple reports of the phantom player issue, but haven't been able to reproduce it. Logging out and back in without closing Paragon Chat is something that was tested extensively during development without running into the issue.

There are a couple of possibilities, but additional information is needed to narrow down which one is the cause.

  • The player entity is not successfully logged out, causing cleanup tasks to be delayed. The client crashing, being forcibly closed, or exiting while in a "Lost Connection to Mapserver" state might cause this. The network connection on localhost should eventually time out, but I might need to double check that the player is fully removed in case of a timeout. In any event, logging back in before the timeout expires would definitely cause the old state of everything to still be present, though a /mapmove should clear it and kick the phantom player out. This isn't exactly a bug, as while Paragon Chat is normally used by one player at once, in principle the underlying infrastructure is designed to support more than one.

  • The XMPP link is not fully disconnecting. Paragon Chat attempts a graceful disconnect and defers cleanup tasks until this succeeds. Networking issues might delay or prevent the disconnect. Running Paragon Chat with the -debug option and observing the XMPP session ending should shed some light on if this is the case.

  • Something is holding references to all of the proxy players and not releasing them. The XMPP resource metadata is reference counted as it may be used by a number of different independent subsystems (zone, channel occupant, costume request callback, etc.) and proxies are cleaned up when the last reference is released -- though the resource itself is allowed to be cached for a certain amount of time even with 0 refs. My first thought was maybe doing something silly like adding yourself to your global friends list could create a reference loop and prevent cleanup, but I checked and the friends list uses identity references instead, which do not block proxy deletion.

Other things you could try that might provide useful information: During a normal session, does /xmppdisconnect cause everyone to vanish? Does /xmppconnect afterward cause them to reappear over the course of 5-10 seconds? What about when you've logged back in to find phantom players, does /xmppdisconnect have any effect then? Does switching maps and then coming back clear them, or are they still there?

Datalink

  • Underling
  • *
  • Posts: 3
  • Datalink Online.
Re: Bug report: Phantom People Bug
« Reply #3 on: September 15, 2015, 02:38:03 PM »
Codewalker, This was why I suggested flushing during login, instead of or in addition to logout. This would also help a bug I've encountered several times where someone else who has hit this bug has sent chat to my client until they restart the PC client. One time the 'chat from beyond' bug happened when both a friend and I had been near the person sending text at their last logout, then left before their next login. The friend and I where both in the Pocket D when the person logged off, and the Forward Base Zeta map when the other person logged back on.


The /xmppdisconnect and /xmppreconnect test had kept 3 people present despite disconnect. This was not as thorough a test as I could have performed, but it did operate in a fashion other than described.


I will switch to debug mode on my next logon and keep track of information from the debug logs as well as switch to the 'leave Paragon Chat open' style of disconnect.


A social reason why this issue could happen fairly frequently that I've heard is that since PC doesn't save the password or a login token, several people keep the Paragon Chat application open to avoid having to retype their passwords and speed up load time.

Codewalker

  • Hero of the City
  • Titan Network Admin
  • Elite Boss
  • *****
  • Posts: 2,740
  • Moar Dots!
Re: Bug report: Phantom People Bug
« Reply #4 on: September 15, 2015, 03:46:50 PM »
This was why I suggested flushing during login, instead of or in addition to logout.

That's the thing. Everything associated with the XMPPLink instance attached to the player already is flushed in the connection callback, mostly to clear things out if you /xmppconnect after losing the XMPP connection without a clean disconnect.

However, that won't help if the problem is (1) or (2), because that means the entities you're seeing are associated with a different XMPPLink. Proxies are shared between link instances to avoid unnecessary duplication if you have multiple clients connected simultaneously. You can flush it all you want, but you only have access to your own link, not to the other player's that is stuck in limbo.

Simply destroying all entities on the map at login regardless if they are still referenced just hides the problem. Not only does it break multi-instancing entirely*, but you'd still be left with whatever problem was causing them to not be destroyed. Instead of knowing about it, it would be invisible and possibly causing worse problems, such as a crash if whatever is holding the reference tries to access them after they are removed.

It could also be something holding onto a roomlink from another session somehow. That would keep the room alive, which in turn would keep all of the occupants alive, and if the room was the meta channel, would keep the proxies alive. To give you an idea of the complexity involved, here's a comment that might shed some light:

// Why all this rigmarole of XMPPLink -> RoomLink -> Room? Theoretically one player
// entity could be in a room hosting the map they're running around on, while another
// could add that same room as a global chat channel. The room JID is the same for
// both, so the XMPPIdentity (which is global) refers to the same room. That's good
// in that they can share the occupant list, but bad in that the handler callback needs
// to do different things for incoming messages in zones versus global channels.
// Even multiple players in the same channel is a problem, as the messages need to
// go different places depending on which link they arrived over, and the room may
// be in different states (currently connecting versus active member) on each session.
// We don't officially support multiple players on one ParagonChat instance, but
// since the mapserver protocol has no concept of a global 'one true player', keeping
// state on a per-XMPPLink basis is the only sensible implementation.

// This gets even more complicated if the same RoomLink is needed in multiple
// contexts for the same entity (i.e. the same XMPP room JID added as two separate
// channels). We can't join the same room more than once on a given XMPP session,
// so add yet another layer to hold the callback functions to handle messages.
// Final layout looks something like this:
//
// XMPPRoomHandle   - Context, incoming message callback, and user data per handle.
// \-> XMPPRoomLink - Shared state for the room across the entire XMPPLink,
//     |              evaporates when last handle to it is released.
//     \-> XMPPRoom - Global room information, is cleaned up when no more XMPPRoomLinks
//                    reference it. Holds occupant list.


This would also help a bug I've encountered several times where someone else who has hit this bug has sent chat to my client until they restart the PC client.

It actually wouldn't help with that at all. The problem there is that your friend somehow didn't see your unavailable <presence/> and still thinks that you're in the zone's meta channel, so they are sending their local chat to you. There's nothing you can do on your end about that**, and correcting the inconsistent state requires your friend's cooperation, usually by disconnecting and reconnecting to XMPP.



* While multi-instancing is not something that's supported or even advertised that it's possible, it's not something I want to sacrifice as it helps keep the backend clean and free of special-case hacks that assume only one player at a time.

** If you're still logged in to the same resource as the one they saw you on, going to the zone they're in and then leaving may cause them to realize that you've left.