Zandronum Chat @ irc.zandronum.com
#zandronum
Get the latest version: 2.1.2
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002552Zandronum[All Projects] Bugpublic2015-12-20 05:432017-08-13 18:18
ReporterEnsaladaDeTomate 
Assigned ToTorr Samaho 
PriorityhighSeveritycrashReproducibilityrandom
StatusassignedResolutionreopened 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version2.1 
Target VersionFixed in Version3.0 
Summary0002552: Crash and spam of P_PlayerThink: No body for "# "
DescriptionThis issue is veeeery random, that theres no way to tell when it will happen, and as the title says, Zandronum crashes by that P_PlayerThink issue, but yeah, sorry if my english is not the best one, but ill try my best to explain it clearly. (I have to point that this happens on a survival server, i have no idea if it happens in other game modes)


* If somebody spectates or dies while playing, it will:

  - crash/dc everyone that is still alive ingame.
  - "" "" everyone that is "Death" but still in the list waiting until the round is over.

* 99& of times it wont crash/dc spectators (theres still 1% that it will crash them)

- When the issue is going to happen, it will always lag one random player for like 3 - 5 seconds until it crashes, then it will start to crash everyone, one by one.

(Theres also a trick that will prevent you from beign dc'd, when the lag event explained above is happening, or when everyone is crashing, and you manage to SPECTATE in time, 99.9% of the times you wont dc/crash, but theres still 0.01% from beign kicked too)

Thanks to ^ trick, i had seen 15+ players crashing in a server until it was empty, and i was the only one that wasnt kicked/dc'd.
Steps To ReproduceSince the issue is sooooooooooooooo random, theres no way to know how it will happen or how to reproduce it, it just happens sooo often (60%+ of the times) that it is starting to annoy players.
Additional InformationThe wad's beign used in the survival servers where the already explained issue happens, are:

- Samsara-v0.31-beta.pk3 (http://www.best-ever.org/download?file=samsara-v0.31-beta.pk3)

- samsara_ex-ha1.pk3 (http://www.best-ever.org/download?file=samsara_ex-ha1.pk3)

- smaddonsfix23.pk3 (http://www.best-ever.org/download?file=smaddonsfix23.pk3)

I also got 2 crash reports:

-http://www.mediafire.com/download/dmx8cqdo2a2bhja/CrashReport1.zip [^]

-http://www.mediafire.com/download/xictpynwc78d3tp/CrashReport2.zip [^]
Attached Files? file icon 2016.10.06_01.15.27_doom2.hubs2.cld [^] (367,301 bytes) 2016-10-05 23:17
zip file icon CrashReport-ticket2552.zip [^] (18,782 bytes) 2016-10-09 20:04
? file icon 2016.10.09_13.02.57_hubs2.cld [^] (366,851 bytes) 2016-10-09 20:27

- Relationships
related to 0002380resolvedTorr Samaho Client crash when exiting map in hexen/hexdd.wad 
related to 0002071resolvedTorr Samaho Actor net IDs go out of sync on the client on returning to maps within hubs 
related to 0002342new Server crashes after many players play, and many map changes in a hub. 

-  Notes
User avatar (0014214)
EnsaladaDeTomate (reporter)
2016-01-27 18:27

Just wanted to clarify, the msg spamming is P_PlayerThink: No body for player "# "

I couldnt find a way to edit the ticket.
User avatar (0014215)
Empyre (reporter)
2016-01-27 20:25

Does the server have either skulltag_actors + skulltag_data or skulltag_content loaded? If not, maybe it should (preferably skulltag_content2.1a.pk3, which combines a more up-to-date skulltag_actors with skulltag_data in one file).
User avatar (0014216)
EnsaladaDeTomate (reporter)
2016-01-27 22:13

Yes, the servers were using skulltag stuff
User avatar (0014226)
cruduxy (reporter)
2016-01-29 19:00

This mostly happens when a death state infinite loop while the actor is used in an ongoing ACS Process\Function. The client crashes and the server complains that it is gone. Only way (currently) to stop these is to add checks if that actor still exists. It stops when the client gets timed out.
User avatar (0014227)
Dusk (developer)
2016-01-29 20:43

If you know how it happens, can you make a testcase?
User avatar (0014231)
EnsaladaDeTomate (reporter)
2016-01-29 21:07

@Cruduxy, yeah, i had been told and aware of that, but i checked every death states of all the playerpawns, and there doesnt seem to be any 0 tic loop
User avatar (0014234)
Empyre (reporter)
2016-01-29 23:05

If I interpret what they're saying correctly, the problem isn't specifically a 0 tic loop, but the presence of any loop at all in the death state of a player, or at least a loop that doesn't end.
User avatar (0014236)
ZzZombo (reporter)
2016-01-30 01:28

Zombie Horde has this problem too but I know for sure it doesn't have any loops in player classes.
User avatar (0014427)
EnsaladaDeTomate (reporter)
2016-02-12 18:21
edited on: 2016-06-14 04:03

I checked all the playerpawns, and there doesn't seem to be any loops in player classes too.

User avatar (0015281)
arkore (reporter)
2016-07-11 17:56

From my experience, it's not a real crash. But, we also do get real crashes.

From what I've seen, there are two separate issues, where only one of those issues causes a real crash, and the other (this particular Issue) keeps you connected but your entire game becomes a HOM effect, and it's my understanding that the P_PlayerThink spam will continue for as long as you keep zandronum open and you're looking at this entire HOM effect, the other people will continue to see P_PlayerThink spam about your player #.

This issue can occur for players in spectator mode, where they too would suddenly have their entire game become a HOM effect, and the other players will see P_PlayerThink spam for that. It can also occur for multiple players simultaneously.
User avatar (0015303)
arkore (reporter)
2016-07-13 02:26

FYI, this issue occurs roughly 20 times per day, on the Complex LCA/RM/HAF/Ark server.

One more detail is when the P_PlayerThink spam stops, you immediately see that player get timed out.
User avatar (0015549)
Ivan (reporter)
2016-08-31 02:05

I think this bug got forgotten in time but it needs more research done to it as it's become quite a plague. It shows its ugly face in DnD servers these days and it still has the same symptoms. It's hard to make an example wad too because the provided information does not directly cause the crash.
User avatar (0015550)
Torr Samaho (administrator)
2016-08-31 06:15

Did anybody ever try what happens if the server is running in debug mode?
User avatar (0015606)
EnsaladaDeTomate (reporter)
2016-09-10 06:20

how do you enable such debug mode thing?
User avatar (0015611)
Torr Samaho (administrator)
2016-09-11 14:54

The server needs to be compiled differently. I think TSPG has an option to use debug instead of release binaries for the server.

BTW: Does anybody have a client side demo of this problem, preferably from the latest 3.0 beta build?
User avatar (0015765)
unknownna (updater)
2016-10-05 23:28
edited on: 2016-10-06 17:05

Quote from Torr Samaho
Does anybody have a client side demo of this problem, preferably from the latest 3.0 beta build?

Yes, recorded with 3.0-alpha-160814-2010. In the demo I've managed to crash one client with 4 spectators present to trigger the P_PlayerThink error. After the client crashed I made 2 of the spectators join the game before connecting to the server with the demo recorder, so there are 2 players and 2 spectators present in the demo in addition to the demo recorder. In the end I exit the map to crash the demo recorder. Let me know if you need a demo without a crash in it.

You'll need hubs2.wad to view it.

zandronum -file hubs2.wad -playdemo 2016.10.06_01.15.27_doom2.hubs2.cld


Edit:

One thing I noticed recently while watching the demo is that there seems to be a difference between the renderers. In software mode, you get the P_PlayerThink error message for all the other player bodies whereas in OpenGL you only get the message for one player body.

Software:

[...]
P_PlayerThink: No body for player 2!
P_PlayerThink: No body for player 3!
P_PlayerThink: No body for player 4!
P_PlayerThink: No body for player 5!
[...]

OpenGL:

[...]
P_PlayerThink: No body for player 5!
P_PlayerThink: No body for player 5!
P_PlayerThink: No body for player 5!
P_PlayerThink: No body for player 5!
[...]

Though I tested it again and the message differences seem to be demo specific. It's the same for both renderers online.

User avatar (0015805)
Torr Samaho (administrator)
2016-10-08 13:13

Thanks! From the demo it looks like the server uses the same net ID for a player body and another actor, which makes the client delete the player body. I suspect that the IDs get messed up on the server when returning to an already visited map, this can't be seen from the demo though.

Can you try to reproduce the problem again with this binary and "sv_showwarnings 1", looking out for the warning "IDList<T>::useID is using an already used ID."?
User avatar (0015811)
unknownna (updater)
2016-10-08 17:42
edited on: 2016-10-09 02:42

I tried the binary and get no additional messages on either clients or server console with "sv_showwarnings 1". There's only the P_PlayerThink error for new clients that join the game after connecting after the initial crash.

Some more information from testing the binary:

1. The non-spectating player that initially triggers the crash appears as dead immediately after the map change to the surviving spectator before the non-spectating player crashes.
2. If the surviving spectator then joins the game and turns into a player, a new connecting client will first spawn into a void/HOM and then get the P_PlayerThink error when joining the game.
3. If the new client then decides to reconnect, he'll spawn into a different HOM, but see the former spectator as dead in the coopinfo.
4. If the new client joins the game after reconnecting, the former spectator might continue to appear as dead on the coopinfo or he might become invalid immediately or after some time (seems to be triggered randomly or by using "give all" cheat exactly 4 times). This step seems to work differently between each session. I only had to use "give all" once in another session. Note that in both cases the former spectator is alive on his end and is rendered invisible but solid on the new client.
5. If the new client turns into a spectator while the former spectator appears as dead on the coopinfo, the new client crashes. From here the cycle repeats and goes back to the latter part of step 2.
6. In addition to this, if the former spectator tries to select a different weapon while appearing dead on the coopinfo for the new client, the new client crashes. From here the cycle repeats and goes back to the latter part of step 2, however, with this step instead of 5, it seems that the connecting client might be greeted with the P_PlayerThink messages before even joining the game.

It's confusing, but it's always the same recurring patterns taking place. In addition to this, I couldn't make the former spectator appear as dead on the coopinfo in 2.1.2 compared to 3.0, so there already is a difference between 2.1.2 and 3.0 here.

User avatar (0015846)
Torr Samaho (administrator)
2016-10-09 16:44

Thanks for the detailed information!

Can you check if this fixes the issue or at least produces new warnings on the server with "sv_showwarnings 1"?
User avatar (0015862)
WaTaKiD (updater)
2016-10-09 20:06
edited on: 2016-10-09 20:27

using ZandroDev3.0-HubDebugTest2 and hub2.wad

i hosted a server and connected a single client
exiting the map the first 2 times seemed normal, but upon exiting a third time, this error showed in the server console:

IDList<T>::useID is using an already used ID.

it showed again when i exited a fourth time, but then a moment later i crashed (the crash report is uploaded to this ticket)

i was also recording a demo, but instead of crashing it simply ends, so im not sure if its of any use

edit: uploaded the demo anyways

User avatar (0015863)
Torr Samaho (administrator)
2016-10-09 20:44

Thanks! I can reproduce the problem and the warning locally now, looks like we are on the right track. Will have to investigate what's going on in more detail.
User avatar (0015864)
unknownna (updater)
2016-10-09 20:58
edited on: 2016-10-09 21:00

It initially seemed to have fixed the issue at first with 2 clients, but immediately after reconnecting to the server the client crashed when exiting the map for the first time.

Ok, it seems that it works until some other/new client connects to the server or until someone turns into a spectator or joins the game after the game has received an initial ID error.

However, 2 clients + and indefinite amount of initial spectators, and only 2, can seemingly survive the ID errors indefinitely provided that no new clients connect, that none of the spectators join the game or that none of the 2 clients turn into a spectator after the error has ocurred.

1 client with an endless amount of spectators can also seemingly survive indefinitely.

1 client alone can also seemingly survive indefinitely, provided that he doesn't reconnect or turn into a spectator and then rejoin the game after receiving an initial ID error.

With 3 non-spectating clients however, it always crashes after the 3rd map change.

The P_PlayerThink error is still there for spectator bodies on new clients, but the connect into dark void/HOM issue and the dead coopinfo problem for former spectators on new clients is seemingly fixed.

Anyway, this bug is extremely confusing and exhausting to test with all these different patterns taking place, but the key thing seems to be that the net IDs go out of sync very quickly between the map changes, as reported in another ticket earlier.

User avatar (0015886)
Torr Samaho (administrator)
2016-10-10 19:07

Can you check if this works better?
User avatar (0015888)
unknownna (updater)
2016-10-10 21:22
edited on: 2016-10-10 21:23

I tested it with 7 clients, with several of them having ping emulaton + ping spikes. I didn't crash or get a single P_PlayerThink error. There was also no net ID errors present anymore. I also tried to disconnect/reconnect with several clients, and received no errors or crashes. To finish it off, I added 3 bots into the game and had everyone telefrag each other. It still didn't crash, so it seemingly fixed this particular P_PlayerThink error. Great work, Torr!

All I noticed was that bots seemingly sped up their movement for a few tics after map changes on telefragged clients, though this seemingly happens in 2.1.2 as well and is a separate issue (I'm not sure whether it's even a bug at all).

In conclusion, I can't say for sure whether this'll fix the P_PlayerThink error on non-hub "nointermission" maps since I only know how to reproduce the error with hub maps, but so far it's looking very good.

User avatar (0015889)
WaTaKiD (updater)
2016-10-10 21:52
edited on: 2016-10-10 21:52

ZandroDev3.0-HubDebugTest3 seems to be a huge improvement

hubs2.wad:
first test i had 1 client connected and changed maps about 400 times, no errors or crashes
second test i had 4 clients connected (2 players (one of them demo recording) and 2 specs), another about 400 map changes, no errors or crashes

i then did nearly identical tests on hexen seven portals <-> guardian of steel and the results were the same, no errors or crashes

and finally i would randomly stop and aim at items and use the info cheat once in a while (along with another test on strife map01 <-> map02), and i didnt come across any more "server couldnt find the netid of the actor ur looking at" errors

so this build seems to have taken care of this ticket, ticket 2071, and ticket 2380 all at once

however, like unknownna, im unsure of how effective this will be outside of hub maps

User avatar (0015891)
Torr Samaho (administrator)
2016-10-11 06:05

I'm glad to hear that the fix seems to work! I still need to properly comment the changes before I push it to the repository. The fix should only have an effect though when a saved level snapshot is loaded, which happens in single player when loading a save game and both offline and online when re-entering an already visited map of a hub. So this should not have any effect online when no hubs is involved.
User avatar (0015901)
Torr Samaho (administrator)
2016-10-11 19:25

I had to slightly revise the fix and pushed the new version to the repository. Would be nice if you check again if it's still working as intended in the next beta build.
User avatar (0015909)
unknownna (updater)
2016-10-11 21:44
edited on: 2016-10-11 21:45

I tested WaTaKiD's 161011-1923 build and the revised fix seems to hold up well. Tested with 6 clients + 3 bots, with some clients having ping emulation and emulated ping spikes.

User avatar (0016490)
Ru5tK1ng (updater)
2016-12-13 17:40

Based on that ^; marking this as resolved.
User avatar (0017203)
EnsaladaDeTomate (reporter)
2017-04-18 19:55

Today, i was playing on TSPG (now its using zandronum 3.0), and the same issue happened again, with the same symptoms. I didnt got a crash report because i was the only one that didnt got kicked, because i did the trick mentioned above.
User avatar (0017623)
EnsaladaDeTomate (reporter)
2017-05-11 05:43

I have to point something that i just found out, today while i was playing (we were like 12 players), i remember seeing my coopinfo that everyone was alive, and had full hp, one of my friends was playing in the same server aswell, but he was spectating, and suddendly, one of the players in my coopinfo, out of nowhere, with full hp, was marked as "Dead", i remember him saying that he was out of the game and was spectating all of the sudden, and i was able to spectate him as if he was "Dead" ingame, but his corpse was still in, like lagging, and not dissapearing after a few seconds when someone dies while you are spectating it (as usual), then after a few seconds, he crashed, and everyone ingame started to crash, one by one, except me and 1 more player that were still alive...

Its hard to explain for me since my native language is not english, but i hope that what i wrote above was underestandable

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: AOSP ZzZombo EnsaladaDeTomate Combinebobnt S_Andrew_S Ivan unknownna FascistCat Korshun
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2015-12-20 05:43 EnsaladaDeTomate New Issue
2016-01-27 18:27 EnsaladaDeTomate Note Added: 0014214
2016-01-27 20:25 Empyre Note Added: 0014215
2016-01-27 22:13 EnsaladaDeTomate Note Added: 0014216
2016-01-29 19:00 cruduxy Note Added: 0014226
2016-01-29 20:43 Dusk Note Added: 0014227
2016-01-29 21:07 EnsaladaDeTomate Note Added: 0014231
2016-01-29 23:05 Empyre Note Added: 0014234
2016-01-30 01:28 ZzZombo Note Added: 0014236
2016-02-12 18:21 EnsaladaDeTomate Note Added: 0014427
2016-06-14 04:03 EnsaladaDeTomate Note Edited: 0014427 View Revisions
2016-07-11 17:56 arkore Note Added: 0015281
2016-07-13 02:26 arkore Note Added: 0015303
2016-08-31 02:05 Ivan Note Added: 0015549
2016-08-31 06:15 Torr Samaho Note Added: 0015550
2016-09-10 06:20 EnsaladaDeTomate Note Added: 0015606
2016-09-11 14:54 Torr Samaho Note Added: 0015611
2016-10-05 22:16 unknownna Relationship added related to 0002380
2016-10-05 23:17 unknownna File Added: 2016.10.06_01.15.27_doom2.hubs2.cld
2016-10-05 23:28 unknownna Note Added: 0015765
2016-10-06 16:58 unknownna Note Edited: 0015765 View Revisions
2016-10-06 17:05 unknownna Note Edited: 0015765 View Revisions
2016-10-08 13:13 Torr Samaho Note Added: 0015805
2016-10-08 17:42 unknownna Note Added: 0015811
2016-10-09 00:55 unknownna Note Edited: 0015811 View Revisions
2016-10-09 02:34 unknownna Note Edited: 0015811 View Revisions
2016-10-09 02:42 unknownna Note Edited: 0015811 View Revisions
2016-10-09 16:44 Torr Samaho Note Added: 0015846
2016-10-09 16:45 Torr Samaho Assigned To => Torr Samaho
2016-10-09 16:45 Torr Samaho Status new => needs testing
2016-10-09 19:44 WaTaKiD Relationship added related to 0002071
2016-10-09 20:04 WaTaKiD File Added: CrashReport-ticket2552.zip
2016-10-09 20:06 WaTaKiD Note Added: 0015862
2016-10-09 20:27 WaTaKiD File Added: 2016.10.09_13.02.57_hubs2.cld
2016-10-09 20:27 WaTaKiD Note Edited: 0015862 View Revisions
2016-10-09 20:44 Torr Samaho Note Added: 0015863
2016-10-09 20:58 unknownna Note Added: 0015864
2016-10-09 20:59 unknownna Note Edited: 0015864 View Revisions
2016-10-09 21:00 unknownna Note Edited: 0015864 View Revisions
2016-10-10 19:07 Torr Samaho Note Added: 0015886
2016-10-10 21:22 unknownna Note Added: 0015888
2016-10-10 21:23 unknownna Note Edited: 0015888 View Revisions
2016-10-10 21:52 WaTaKiD Note Added: 0015889
2016-10-10 21:52 WaTaKiD Note Edited: 0015889 View Revisions
2016-10-11 06:05 Torr Samaho Note Added: 0015891
2016-10-11 19:25 Torr Samaho Note Added: 0015901
2016-10-11 21:44 unknownna Note Added: 0015909
2016-10-11 21:45 unknownna Note Edited: 0015909 View Revisions
2016-10-11 21:47 unknownna Relationship added related to 0002342
2016-11-24 07:43 Edward-san Product Version => 2.1
2016-11-24 07:43 Edward-san Target Version => 3.0
2016-12-13 17:40 Ru5tK1ng Note Added: 0016490
2016-12-13 17:40 Ru5tK1ng Status needs testing => resolved
2016-12-13 17:40 Ru5tK1ng Resolution open => fixed
2016-12-13 17:40 Ru5tK1ng Fixed in Version => 3.0
2017-04-18 19:55 EnsaladaDeTomate Note Added: 0017203
2017-04-18 19:55 EnsaladaDeTomate Status resolved => feedback
2017-04-18 19:55 EnsaladaDeTomate Resolution fixed => reopened
2017-05-11 05:43 EnsaladaDeTomate Note Added: 0017623
2017-05-11 05:43 EnsaladaDeTomate Status feedback => assigned
2017-08-13 18:18 Dusk Target Version 3.0 =>






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker