Notes |
|
(0011403)
|
Ru5tK1ng
|
2015-01-17 07:27
(edited on: 2015-01-17 07:28) |
|
I have attached the crash report for further information.
|
|
|
|
It seems to crash if you call weapprev/weapnext after dying. But it's apparently fixed in 2.1. |
|
|
(0012746)
|
unknownna
|
2015-06-17 09:50
(edited on: 2015-06-17 13:11) |
|
Actually, I'm for some reason now able to reproduce it in the latest beta build. It still happens in 2.1-alpha-150611-2305.
In 2.0 it crashes when you rapidly call weapprev/weapnext when dying.
In 2.1 it crashes when you rapidly call weapprev/weapnext and +use when dying.
It's important to have this fixed since it's related to the crashes in CTF caused by weapprev/weapnext.
I made an example WAD for Doom and managed to make it crash there a few times as well. It crashes very rarely in 2.1 compared to 2.0 though.
|
|
|
|
this is the backtrace i got from the uploaded 2.1 crash report
> zandronum.exe!P_SetPsprite(player_t * player=0x011f19b8, int position=0, FState * state=0x00000070, bool nofunction=false) Line 108 C++
zandronum.exe!AF_A_CrispyPlayer(AActor * self=0x00000000, AActor * stateowner=0x00000000, FState * __formal=0x04921c7c, FState * __formal=0x04921c7c, StateCallData * statecall=0x00000000) Line 723 C++
zandronum.exe!AActor::SetState(FState * newstate=0x04921c7c, bool nofunction=false) Line 670 C++
zandronum.exe!AActor::Tick() Line 4346 + 0xa bytes C++
zandronum.exe!GAMEMODE_IsTimelimitActive() Line 498 + 0x1c bytes C++
user32.dll!_NtUserMessageCall@28() + 0xc bytes
user32.dll!SendMessageWorker() + 0xf3 bytes
user32.dll!SendMessageA() + 0x50 bytes
zandronum.exe!SERVERCONSOLE_UpdateStatistics() Line 1755 C++
zandronum.exe!SERVER_ProcessCommand(long lCommand=0, BYTESTREAM_s * pByteStream=0x00000000) Line 4359 C++
zandronum.exe!SERVER_ParsePacket(BYTESTREAM_s * pByteStream=0x00000000) Line 4262 + 0x9 bytes C++
zandronum.exe!SERVER_GetPackets() Line 1104 C++
zandronum.exe!SERVER_Tick() Line 563 C++
zandronum.exe!D_DoomLoop() Line 1246 C++ |
|
|
|
I found that 'self->player->psprites[ps_weapon].state' is NULL when 'P_SetPsprite' is called in A_CrispyPlayer, making the 'state' parameter completely wrong.
So I checked when it could happen, so I found out this:
Hardware watchpoint 3: *((FState **)0x3d51d10)
Old value = (FState *) 0x61200004c3e8
New value = (FState *) 0x0
P_SetPsprite (player=0x3d51b80 <players>, position=0, state=0x0,
nofunction=false)
at /home/edward-san/zdoom/zandronum/sandbox-stable/src/p_pspr.cpp:104
104 break;
And this is the backtrace:
#0 P_SetPsprite (player=0x3d51b80 <players>, position=0, state=0x0,
nofunction=false)
at /home/edward-san/zdoom/zandronum/sandbox-stable/src/p_pspr.cpp:104
psp = 0x3d51d10 <players+400>
#1 0x0000000000a593b3 in AF_A_Lower (self=0x619000318d80,
stateowner=0x6190002de680, statecall=0x0)
at /home/edward-san/zdoom/zandronum/sandbox-stable/src/p_pspr.cpp:678
player = 0x3d51b80 <players>
psp = 0x3d51d10 <players+400>
0000002 0x0000000000a4553f in FState::CallAction (this=0x61200004c3e8,
self=0x619000318d80, stateowner=0x6190002de680, statecall=0x0)
at /home/edward-san/zdoom/zandronum/sandbox-stable/src/./info.h:124
No locals.
0000003 0x0000000000a55799 in P_SetPsprite (player=0x3d51b80 <players>,
position=0, state=0x61200004c3e8, nofunction=false)
at /home/edward-san/zdoom/zandronum/sandbox-stable/src/p_pspr.cpp:140
psp = 0x3d51d10 <players+400>
0000004 0x0000000000a5b117 in P_MovePsprites (player=0x3d51b80 <players>)
at /home/edward-san/zdoom/zandronum/sandbox-stable/src/p_pspr.cpp:975
i = 0
psp = 0x3d51d10 <players+400>
state = 0x61200004c3e8
0000005 0x0000000000b2ef1c in P_PlayerThink (player=0x3d51b80 <players>, pCmd=0x0)
---Type <return> to continue, or q <return> to quit---
at /home/edward-san/zdoom/zandronum/sandbox-stable/src/p_user.cpp:3504
cmd = 0x3d51b8c <players+12>
totallyfrozen = false
0000006 0x0000000000cdf920 in server_ProcessMoveCommand (ClientMoveCmd=...,
ulClient=0)
at /home/edward-san/zdoom/zandronum/sandbox-stable/src/sv_main.cpp:5045
savedCurrentClient = 4050815679581454848
pPlayer = 0x3d51b80 <players>
pCmd = 0x3d51b8c <players+12>
0000007 0x0000000000cde8e1 in server_ClientMove (
pByteStream=0x3d86e98 <g_NetworkMessage+24>)
at /home/edward-san/zdoom/zandronum/sandbox-stable/src/sv_main.cpp:4939
clientMoveCmd = {cmd = {ucmd = {
dummy = "\177\000\000\001;\305\000\000\060\305\377\377\000\177\000\000\222\370\377\377\377\017\000\000\220\304\377\377\377\177\000\000\240\305\377\377\377\177\000\000[\204", buttons = 0, pitch = 0, yaw = 0, roll = 0,
forwardmove = -12800, sidemove = 0, upmove = 0},
consistancy = 0}, angle = 0, pitch = 0, usWeaponNetworkIndex = 0,
ulGametic = 4484, ulServerGametic = 5463}
pCmd = 0x7fffffffc450
ulBits = 24
A_Lower is not present in the strifeplayer's decorate code, so I don't know what's going on... |
|
|
|
Here's some info from the ZDoom wiki:
Quote from ZDoom wiki A_CrispyPlayer
(no parameters)
This codepointer declares the calling player dead and causes the player "weapon" state to jump from its place in the FireHands state sequence to the corresponding FireHandsLower state. (For example, if the player weapon is in the FireHands+2 state, it will jump to the FireHandsLower+2 state.) This will only work correctly if the player class declares the FireHands state sequence first, followed by the FireHandsLower state sequence, and with exactly as many states in both sequences. Notably, it means that inheritance cannot be relied upon: if the FireHandsLower state is redefined, then the FireHands state needs to be redefined as well, and vice-versa.
Note that it changes the "weapon" state, not the "player" state, even though it is not meant to be called from a "weapon" state.
This codepointer is restricted to StrifePlayer and actors inheriting from it.
And here are the corresponding states in StrifePlayer:
Burn:
BURN A 3 Bright A_ItBurnsItBurns
BURN B 3 Bright A_DropFire
BURN C 3 Bright A_Wander
BURN D 3 Bright A_NoBlocking
BURN E 5 Bright A_DropFire
BURN FGH 5 Bright A_Wander
BURN I 5 Bright A_DropFire
BURN JKL 5 Bright A_Wander
BURN M 5 Bright A_DropFire
BURN N 5 Bright A_CrispyPlayer
BURN OPQPQ 5 Bright
BURN RSTU 7 Bright
BURN V -1
Stop
Firehands:
WAVE ABCD 3
Loop
Firehandslower:
WAVE ABCD 3 A_HandLower
Loop
Quote from ZDoom wiki A_HandLower
(no parameters)
This codepointer lowers the HUD sprite, after it has reached the bottom of the screen, the graphic is cleared.
This codepointer is restricted to StrifePlayer and actors inheriting from it. |
|
|
|
Actually, A_Lower is present in the Pistol_02 Deselect state. Somehow the server allows deselecting the pistol while the player burns out. |
|
|
(0012754)
|
unknownna
|
2015-06-18 11:11
(edited on: 2015-06-18 12:31) |
|
So far I managed to make it crash in:
* 98e r3152
* 98e r3283M
* 98e r3287
* 98e r3296
* 1.0
* 1.1
* 1.2
* 1.3
* 2.0
* 2.1
However, for some reason it doesn't seem to crash in 98d.
|
|
|
|
|
|
|
It doesn't crash in r2994. |
|
|
|
|
|
(0012764)
|
Edward-san
|
2015-06-20 17:38
(edited on: 2015-06-20 17:51) |
|
Ok, thanks to unknownna and Dusk via IRC, this issue seems to be a regression of r3090:
changeset 779daffa4c21 (0. 110206-2124, 69 hops from 0.98d): committed by Torr Samaho on 2011-02-06 21:24:24, 6: +45/-18
Fixed client / server weapon sync issues after spawning / respawning.
SVN r3090 (latestzdoom)
url:'https://bitbucket.org/Torr_Samaho/zandronum-stable/commits/779daffa4c21 [^]'
[edit] I and unknownna think it's because of the fix mentioned in 0000193:0000966 .
|
|
|
|
I tried to replicate this bug with 3.0-alpha-150831-1814 repeatedly. I was unable to crash the server by spawning and dying in fire repeatedly. Seems this is fixed now. |
|
|
|
I have a feeling this is also why Doomcenter crashes.. I seen similar things in the crashlog, and the last line before it crashes is someone burning to death. |
|
|
|
On second thought.. I tried this in doomcenter.. using the gas can, spread the gas around, lite it, and watched myself die, all while spamming +use and weapnext/prev.
Server didn't crash. so yea... nvm what I said |
|
|
|
WataKid couldn't reproduce this crash with today's build. I'd say this was fixed eventually somewhere down the line. |
|