Viewing Issue Simple Details Jump to Notes ] Wiki ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005586 [DCSS] Bug Report major always 2012-04-22 16:23 2012-11-26 23:42
Reporter araganzar View Status public  
Assigned To edlothiol
Priority normal Resolution done  
Status resolved   Product Branch 0.10 ancient branch
Summary 0005586: old game blocking spectating in Webtiles
Description I have a 447h old game under araganzar on CDO webtiles. This is a character that died. The problem is, the spectator link is this:
https://tiles.crawl.develz.org/#watch-araganzar [^]

This means that anyone who tries to spectate my games cannot because it tries to load the phantom game instead. I have tried to bring up the game multiple times and it sits on the loading screen. I've tried hitting ESC and Y and other keys in case the game is stuck on an invisible prompt...
Additional Information
Tags No tags attached.
Attached Files png file icon badgame.png [^] (48,594 bytes) 2012-04-22 16:23


png file icon minomax.png [^] (8,934 bytes) 2012-04-25 01:02

- Relationships

-  Notes
(0017847)
araganzar (reporter)
2012-04-22 17:01

I should note I have another game active under araganzar and am able to play - webtiles shows both games when I am online. Don't kill that one!
(0017854)
roctavian (developer)
2012-04-23 09:48

I think most of those 400+ hour idle times must be phantom games as well.
(0017865)
araganzar (reporter)
2012-04-24 18:01

I'd guess so. I've started up a game under another name to verify it's not something local - people are able to spectate fine.

I wouldn't want to lose a 20-days-old game, but surely this is throwing an error that can be trapped and used to either clear the game or provide the option to the user to clear it.

Another option would be to have the spectate link include an identifier unique to the player or to webtiles.
(0017866)
araganzar (reporter)
2012-04-25 01:01

My session under user MinoMax is now corrupted in this way. I have an active session I am playing, but two games show up on webtiles for MinoMax - one for the current game and one for the same game 16 hours before. See attached image.

This means no one can spectate, which is unfortunate because I've been running a series introducing people to the game.
(0017872)
edlothiol (developer)
2012-04-25 22:36

Yeah, these game entries only exist in the server program -- they should get cleared after the game ends and the session is closed, but somehow don't, and I have no idea why. Any information on when this happens would be helpful.
(0017981)
araganzar (reporter)
2012-05-06 06:08

I believe I know what is happening. I have been playing some games with a lot of spectators (sometimes up to 40-50). Tonight we had 10 people watching and the lag got unbearable (like 10-15s response time). I said I was going to quit and come back, but I could not quit out and had to refresh the page.

When I came back, I could start Crawl 0.10 but I also saw the old game still there. When I restarted my game I now had two games - one real one and one phantom one. All the old spectators still show on the old game, and you can go into those games and chat.

What could be happening is when the player crashes or reloads the game, either the cleanup that occurs on a crash or the resetting of stale processes is not properly clearing up entries for the attending spectators, or possibly those child records are preventing deletion of records for the game. If you look at all the old "phantom" games since you reset the server, all of them have at least 1 spectator.

Also, it appears to be random whether or not you get into the "phantom" game or the "real" game as a spectator. If I joined Arrythmia's "phantom" game or his "real" game, both took me to the real game. But anyone trying to join my "real" or "phantom" games goes to the phantom one, which is a black screen with chat.

If this takes more research, maybe appending the game identifier onto the url produced by the list of games on webtiles would fix the immediate issue as well. Also, long term, doing this would change a potential point of failure for spectators into a minor annoyance of a few extra games on the list.
(0017984)
araganzar (reporter)
2012-05-06 18:59

Okay. Clearly either the process is ending abnormally and thus not calling on_crawl_end to clear up the socket, or it's ending normally and on_crawl_end is not doing or failing the socket remove (when self.client_terminated).

I don't see logging in on_crawl_end, but putting a logging statement at the start and another when removing the socket would tell us if the process is ending abnormally as well as if an attempt was made to clear the socket.


Speculation: this looks to be occurring when the server is busy. All times this has happened it was a pretty active game with a lot of watchers.

I've played a bit with 10-15 spectators and at a certain point we all hit a point where the server lag is really bad. It's possible this is the player's internet connection but I've had it happen when my response/bandwidth from the site is fine. For this reason I suspect Tornado, the CrawlProcessHandler, or the spectator code has a small memory leak or other instability that shows up when heavily stressed.
__

I think a minor code change would allow spectating to work properly without masking the root cause.

In wshandler.py in the code following " def watch(self, username):" there are these statements:
if len(procs) >= 1:
  process = procs[0]
  self.logger.info("Started watching %s.", process.username)

The problem is, if there is a phantom game, procs[0] could be that phantom socket. If "process = procs[0]" were changed from 0 to a random integer from 0 to len(procs), the user would instead get one of the two games. So they could get in pretty easily. I've never seen more than 2 ghost games (and that was when I had 50 people watching so it's an unusual stress) so this should be sufficient.

This leaves the phantom games out there, it doesn't mask the underlying problem so it can still be researched/duplicated, and it when it does occur it will be a slight annoyance to the spectator rather than a roadblock.
(0017985)
araganzar (reporter)
2012-05-06 19:03

Something like (in the watch function in wshandler.py)
if len(procs) > = 1:
  process = procs[randrange(0,len(procs)-1)]
  self.logger.info("Started watching %s.", process.username)
(0019285)
StormyDragon (reporter)
2012-07-29 07:22

Browser: Chrome

Here is a way to reliably reproduce the issue that causes games to idle forever despite being done.

You are a spectator, you use a spectator link to enter the game. Then in the same tab, change the link name to another person who is playing, then a third or a fourth.

The resulting chaos in the browser is in a way entertaining on it's own, however I noticed afterward that all the games I had used, games that eventually ended, were now in the broken idle state.
(0019700)
araganzar (reporter)
2012-08-24 06:38

Just happened on CSZO. Same story, browser tab crashed and returned to menu, spectators were in game. Same lockup.

HOWEVER this time I clicked the 0.11 link and it returned to the game after a long long wait.
(0020566)
edlothiol (developer)
2012-11-26 23:42

This has been fixed for a while.

- Issue History
Date Modified Username Field Change
2012-04-22 16:23 araganzar New Issue
2012-04-22 16:23 araganzar File Added: badgame.png
2012-04-22 16:58 araganzar Note Added: 0017846
2012-04-22 17:00 araganzar Note Deleted: 0017846
2012-04-22 17:01 araganzar Note Added: 0017847
2012-04-23 09:48 roctavian Note Added: 0017854
2012-04-24 18:01 araganzar Note Added: 0017865
2012-04-25 01:01 araganzar Note Added: 0017866
2012-04-25 01:02 araganzar File Added: minomax.png
2012-04-25 22:36 edlothiol Note Added: 0017872
2012-05-06 06:08 araganzar Note Added: 0017981
2012-05-06 18:59 araganzar Note Added: 0017984
2012-05-06 19:03 araganzar Note Added: 0017985
2012-07-29 07:22 StormyDragon Note Added: 0019285
2012-08-15 15:33 edlothiol Status new => assigned
2012-08-15 15:33 edlothiol Assigned To => edlothiol
2012-08-24 06:38 araganzar Note Added: 0019700
2012-11-26 23:42 edlothiol Note Added: 0020566
2012-11-26 23:42 edlothiol Status assigned => resolved
2012-11-26 23:42 edlothiol Fixed in Branch => 0.11 stable branch
2012-11-26 23:42 edlothiol Resolution open => done


Mantis 1.1.8[^]
Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker