0002380: Client crash when exiting map in hexen/hexdd.wad

Notes
(0013136) WaTaKiD (updater) 2015-08-09 09:07	here is the backtrace from the attached crash report: > zandronum.exe!AActor::FindInventory(const PClass * type=0x040dd610, bool subclass=false) Line 1052 C++ zandronum.exe!AWeapon::AddAmmo(AActor * other=0x00000000, const PClass * ammotype=0x00010000, int amount=0) Line 435 + 0xe bytes C++ zandronum.exe!AWeapon::AttachToOwner(AActor * other=0x0c42aa58) Line 323 + 0x23 bytes C++ zandronum.exe!AInventory::TryPickup(AActor * & toucher=0x0c42aa58) Line 1531 C++ zandronum.exe!AWeapon::TryPickup(AActor * & toucher=0x0c42aa58) Line 90 + 0xc bytes C++ zandronum.exe!AFighterWeapon::TryPickup(AActor * & toucher=0x0c42aa58) Line 41 C++ zandronum.exe!AInventory::CallTryPickup(AActor * toucher=0x0c42aa58, AActor * * toucher_return=0x00000000) Line 1554 + 0x11 bytes C++ zandronum.exe!AActor::GiveInventoryType(const PClass * type=0x013a0170) Line 1090 + 0xa bytes C++ zandronum.exe!client_WeaponChange(BYTESTREAM_s * pByteStream=0x00000000) Line 8714 C++ zandronum.exe!CLIENT_ProcessCommand(long lCommand=0, BYTESTREAM_s * pByteStream=0x00000000) Line 2069 C++ zandronum.exe!CLIENT_ParsePacket(BYTESTREAM_s * pByteStream=0x00000000, bool bSequencedPacket=false) Line 1367 C++ zandronum.exe!CLIENT_GetPackets() Line 1101 C++ zandronum.exe!D_DoomLoop() Line 1221 C++

(0013186) unknownna (updater) 2015-08-10 08:26 edited on: 2015-08-10 08:28	I got it to crash again when attempting to exit a level right after a new client joined the game (same as last time).

(0013204) WaTaKiD (updater) 2015-08-10 19:08	this is the backtrace of the 2nd report: > zandronum.exe!AWeapon::AttachToOwner(AActor * other=0x0ca3bfb8) Line 327 + 0x14 bytes C++ zandronum.exe!AInventory::TryPickup(AActor * & toucher=0x0ca3bfb8) Line 1531 C++ zandronum.exe!AWeapon::TryPickup(AActor * & toucher=0x0ca3bfb8) Line 90 + 0xc bytes C++ zandronum.exe!AFighterWeapon::TryPickup(AActor * & toucher=0x0ca3bfb8) Line 41 C++ zandronum.exe!AInventory::CallTryPickup(AActor * toucher=0x0ca3bfb8, AActor * * toucher_return=0x00000000) Line 1554 + 0x11 bytes C++ zandronum.exe!AActor::GiveInventoryType(const PClass * type=0x0406b178) Line 1090 + 0xa bytes C++ zandronum.exe!client_WeaponChange(BYTESTREAM_s * pByteStream=0x00000000) Line 8714 C++ zandronum.exe!CLIENT_ProcessCommand(long lCommand=0, BYTESTREAM_s * pByteStream=0x00000000) Line 2069 C++ zandronum.exe!CLIENT_ParsePacket(BYTESTREAM_s * pByteStream=0x00000000, bool bSequencedPacket=false) Line 1367 C++ zandronum.exe!CLIENT_GetPackets() Line 1101 C++ zandronum.exe!D_DoomLoop() Line 1221 C++

(0013205) Edward-san (developer) 2015-08-10 20:51	Does it crash with latest 3.0 build?

(0013213) unknownna (updater) 2015-08-11 21:20	Quote from Edward-san Does it crash with latest 3.0 build? I don't know. Something strange happened right now on a Hexen server: Several clients including mine crashed when one client exited the map. I reconnected and it worked fine until a new client connected to the server. It crashed immediately when the new client connected to the server. I reconnected to the server and was for some reason spawned into a dark void as a spectator (this also happened to someone else as well). It quickly crashed a few seconds later. I reconnected and crashed again a few times until the "dark void spawn" issue corrected itself. As I type this, it crashed again.

(0013627) WaTaKiD (updater) 2015-10-07 20:25	uploaded a crash report using 3.0-151004-2012 it happened just as i arrived at seven portals from guardian of fire

(0014753) Edward-san (developer) 2016-04-24 22:27	So, here it is what we found out with WaTaKiD's help: The crash happens this way: when the server tells the client to change the weapon, the player's inventory is NULL for some reason, leading to a crash when the weapon inventory is given to the player.

(0014766) WaTaKiD (updater) 2016-04-28 18:51 edited on: 2016-04-28 19:02	uploaded a crash report using 3.0-r160229-1221, this is the backtrace: > zandronum.exe!AActor::FindInventory(const PClass * type, bool subclass) Line 957 C++ zandronum.exe!AWeapon::AddAmmo(AActor * other, const PClass * ammotype, int amount) Line 475 C++ zandronum.exe!AWeapon::AttachToOwner(AActor * other) Line 373 C++ zandronum.exe!AInventory::TryPickup(AActor * & toucher) Line 1636 C++ zandronum.exe!AWeapon::TryPickup(AActor * & toucher) Line 138 C++ zandronum.exe!AInventory::CallTryPickup(AActor * toucher, AActor * * toucher_return) Line 1682 C++ zandronum.exe!AActor::GiveInventoryType(const PClass * type) Line 995 C++ zandronum.exe!client_WeaponChange(BYTESTREAM_s * pByteStream) Line 8694 C++ zandronum.exe!CLIENT_ProcessCommand(long lCommand, BYTESTREAM_s * pByteStream) Line 2085 C++ zandronum.exe!CLIENT_ParsePacket(BYTESTREAM_s * pByteStream, bool bSequencedPacket) Line 1369 C++ zandronum.exe!CLIENT_GetPackets() Line 1104 C++ zandronum.exe!D_DoomLoop() Line 1308 C++ zandronum.exe!D_DoomMain() Line 3251 C++ the hubs2.wad i uploaded can be used to reproduce the crash using the doom2 iwad, just load them up online and repeatedly run into the bloodfall in front of u to change maps it takes me roughly 2-3 mins to change maps 40 something times and finally crash ive also done some testing with varying map sizes and thing counts and it seems that while the size of the map doesnt matter, the thing count does the maps HUB and MAP01 in hubs2.wad are very small maps but have roughly 2k things out in the void, removing all those things will prevent the crash, but adding more may or may not make the crash happen faster (it seems random, sometimes it happens faster, sometimes not) other tidbits: ive tried adding tons of sectors, big and small, and it didnt seem to affect the crash at all, so since this involves hubs and things, this might just be a side effect of:'http://zandronum.com/tracker/view.php?id=2071 [^]' ive tried waiting for the teleport fog to disappear and my weapon to fully raise after each map change, doesnt seem to affect the crash at all i have not tried to remove things to the point where adding/removing 1 thing can result in the crash happening or not, but if this is a step i should take then let me know

(0014767) WaTaKiD (updater) 2016-04-28 19:31 edited on: 2016-04-28 20:24	my apologies but it seems that i had sv_nomonsters 1 during all my testing, which apparently can change the results somewhat what i mean is that if i have sv_nomonsters 0, instead of crashing after so many map changes, i will freeze in place and my screen will become a hom i will record and upload 2 demos using 3.0-r160229-1221, the first will be with sv_nomonsters 1, and it will end with me crashing, the second will be with sv_nomonsters 0, showing the freeze/hom screen edit: uploaded the demo with sv_nomonsters 1, however it seems that with demo recording enabled with sv_nomonsters 0, i crash instead of getting a hom screen, so uh yea, heres a youtube video instead, i guess:'https://www.youtube.com/watch?v=UU-K-qvvOn4&feature=youtu.be [^]' (just skip to about 1:08) edit2: regarding the video, for wutever its worth, if i wait too long to spectate and rejoin, my client will time out

(0014768) Edward-san (developer) 2016-04-28 20:23 edited on: 2016-04-28 20:24	Incidentally, on my Ubuntu 64bit machine I get neither crashes or freezes, but after a certain number of map changes, I get these messages on console in map01: CLIENT_SpawnThing: WARNING! Tried to delete console player's body! lNetID = 1233 at the next map change I get: CLIENT_SpawnThing: WARNING! Tried to delete console player's body! lNetID = 3141 then it stop reporting, except after a certain number of times, then it repeats at regular intervals.

(0015761) unknownna (updater) 2016-10-05 22:15 edited on: 2016-10-05 22:46	With WaTaKiD's example WAD I was able to reproduce the crashes, the "connect into dark void" issue and one variant of the P_PlayerThink: No body for "Player #" issue. It was not necessary to use any ping emulation to reproduce the issues. Spectators present seem to be immune to the crashes. When exiting back and forth often enough to trigger the initial crash, all non-spectating players crash. The spectators survive this, but their view turns into a HOM and they can still talk and interact with other players (Coop spy doesn't work and automap crashes their game) for a while before being forced to time out. In addition to this, the spectator bodies become the initial cause for the P_PlayerThink error for new clients connecting to the server after the initial crash has occurred. Any new client will from here on connect to a dark void and then see all other players/spectators as invalid once they join the game, and they will render all non-spectating players as invisible but solid. If an invalid spectator joins the game, the P_PlayerThink error stops for his particular body on the other clients, but he will still be invalid and invisible to even newer clients joining the game after he himself has joined. A map exit from this point will crash all players except any spectators present. The only thing that seemingly fixes this issue and snaps all clients out of it is when every 2nd client joins the game and exits the map once all clients have crashed. Like WaTaKiD, I noticed that sv_nomonsters seem to have an effect here. If true, it only takes the inital crash before it corrects itself. If false, it takes 2 crashes, so thing count might have something to say here. Once the server decides that the clients have crashed enough, it starts all over and resumes until the crashes start to appear again after enough map changes. So the recurring pattern seems to work like this in WaTaKiD's example WAD with sv_nomonsters 0: 1. Players exit back and forth between hubs to crash themselves. 2. 1st spectator or new client joins the game and exits the map crashing himself. 3. 2nd spectator or new client joins the game and exits the map and doesn't crash anymore. 4. repeat step 1. With sv_nomonsters 1: 1. Players exit back and forth between hubs to crash themselves. 2. 1st spectator or new client joins the game and exits the map and doesn't crash anymore. 3. repeat step 1. One final thing: It seems that clients are still in the game even when they have received a fatal error. They don't disconnect fully until they've either saved/discarded the report or have closed the error window, as the invalid body of a client was still present in the game for other players until I closed its fatal error window. Edit: The HOM/dark void effect differs between the renderers. The dark void effect is simply a HOM in the OpenGL renderer. Quote from Edward-san Does it crash with latest 3.0 build? It also crashes in 3.0-alpha-160814-2010.

(0016000) Edward-san (developer) 2016-10-14 19:34	'https://bitbucket.org/Torr_Samaho/zandronum/commits/e5d074b4020b [^]'

(0016438) Ru5tK1ng (updater) 2016-12-08 02:38	With those changes, I wasn't able to crash despite repeatedly running around in the example hub. Spectators joining and exiting to the next area didn't cause a crash. Moving back and forth didn't cause any homs to spectators either.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2015-08-09 08:43	unknownna	New Issue
2015-08-09 08:43	unknownna	File Added: CrashReport.zip
2015-08-09 09:07	WaTaKiD	Note Added: 0013136
2015-08-10 08:26	unknownna	Note Added: 0013186
2015-08-10 08:27	unknownna	File Added: CrashReport_02.zip
2015-08-10 08:28	unknownna	Note Edited: 0013186	View Revisions
2015-08-10 19:08	WaTaKiD	Note Added: 0013204
2015-08-10 20:51	Edward-san	Note Added: 0013205
2015-08-11 21:13	unknownna	File Added: CrashReport_03.zip
2015-08-11 21:13	unknownna	File Added: CrashReport_04.zip
2015-08-11 21:13	unknownna	File Added: CrashReport_05.zip
2015-08-11 21:13	unknownna	File Added: CrashReport_06.zip
2015-08-11 21:20	unknownna	Note Added: 0013213
2015-08-11 21:20	unknownna	File Added: CrashReport_07.zip
2015-10-07 20:22	WaTaKiD	File Added: CrashReport-hexen3.0.zip
2015-10-07 20:25	WaTaKiD	Note Added: 0013627
2016-04-24 22:27	Edward-san	Note Added: 0014753
2016-04-24 22:28	Edward-san	Status	new => confirmed
2016-04-28 18:29	WaTaKiD	File Added: hubs2.wad
2016-04-28 18:29	WaTaKiD	File Added: CrashReport-hubs2-doom2-3.0.zip
2016-04-28 18:51	WaTaKiD	Note Added: 0014766
2016-04-28 19:02	WaTaKiD	Note Edited: 0014766	View Revisions
2016-04-28 19:31	WaTaKiD	Note Added: 0014767
2016-04-28 19:40	WaTaKiD	File Added: ticket2380-nomonsters1.cld
2016-04-28 20:20	WaTaKiD	Note Edited: 0014767	View Revisions
2016-04-28 20:23	Edward-san	Note Added: 0014768
2016-04-28 20:24	WaTaKiD	Note Edited: 0014767	View Revisions
2016-04-28 20:24	Edward-san	Note Edited: 0014768	View Revisions
2016-10-05 22:15	unknownna	Note Added: 0015761
2016-10-05 22:15	unknownna	Note Edited: 0015761	View Revisions
2016-10-05 22:16	unknownna	Relationship added	related to 0002552
2016-10-05 22:16	unknownna	Relationship added	related to 0000124
2016-10-05 22:20	unknownna	Reproducibility	unable to reproduce => always
2016-10-05 22:34	unknownna	Note Edited: 0015761	View Revisions
2016-10-05 22:46	unknownna	Note Edited: 0015761	View Revisions
2016-10-14 19:34	Edward-san	Note Added: 0016000
2016-10-14 19:34	Edward-san	Assigned To	=> Torr Samaho
2016-10-14 19:34	Edward-san	Status	confirmed => needs testing
2016-10-14 19:34	Edward-san	Target Version	=> 3.0
2016-12-08 02:38	Ru5tK1ng	Note Added: 0016438
2016-12-08 02:38	Ru5tK1ng	Status	needs testing => resolved
2016-12-08 02:38	Ru5tK1ng	Resolution	open => fixed
2016-12-08 02:38	Ru5tK1ng	Fixed in Version	=> 3.0
2018-09-30 21:56	Blzut3	Status	resolved => closed