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
0002067Zandronum[All Projects] Bugpublic2015-01-17 06:302017-07-09 23:23
ReporterRu5tK1ng 
Assigned To 
PriorityhighSeveritycrashReproducibilitysometimes
StatusresolvedResolutionunable to reproduce 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version1.3 
Target Version3.0Fixed in Version3.0 
Summary0002067: Strife Player "Burn" state crashes server
DescriptionWhen online, if a player dies by a flame weapon and goes into the burn state, there is a chance to crash the server. In each instance of the server crashing, the log has the following lines:

*** Fatal Error ***
Address not mapped to object (signal 11)
Address: 0xe2

The event before these lines is a player dying by fire. I have attached a test map that will illustrate the bug. Spawn, fire phosphorous rounds, spread the flames, and then respawn each time you die.
Attached Files? file icon strifeburntest.wad [^] (800 bytes) 2015-01-17 06:30
zip file icon CrashReport-Strife.zip [^] (16,056 bytes) 2015-01-17 07:27
? file icon burn_weap_crash.wad [^] (2,666 bytes) 2015-06-17 13:06
zip file icon CrashReport.zip [^] (15,445 bytes) 2015-06-17 13:06

- Relationships
related to 0000193resolvedTorr Samaho Able to fire weapon before it's passed A_Raise 

-  Notes
User avatar (0011403)
Ru5tK1ng (updater)
2015-01-17 07:27
edited on: 2015-01-17 07:28

I have attached the crash report for further information.

User avatar (0012672)
unknownna (updater)
2015-06-13 06:02

It seems to crash if you call weapprev/weapnext after dying. But it's apparently fixed in 2.1.
User avatar (0012746)
unknownna (updater)
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.

User avatar (0012747)
WaTaKiD (updater)
2015-06-17 15:53

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++
User avatar (0012751)
Edward-san (developer)
2015-06-18 10:13

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...
User avatar (0012752)
unknownna (updater)
2015-06-18 10:22

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.
User avatar (0012753)
Edward-san (developer)
2015-06-18 10:25

Actually, A_Lower is present in the Pistol_02 Deselect state. Somehow the server allows deselecting the pistol while the player burns out.
User avatar (0012754)
unknownna (updater)
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.

User avatar (0012757)
Edward-san (developer)
2015-06-20 12:02

unknownna, can you check this build:https://dl.dropboxusercontent.com/u/66055976/2015/builds/skulltag-r2994.7z [^] ?
User avatar (0012758)
unknownna (updater)
2015-06-20 12:29

It doesn't crash in r2994.
User avatar (0012763)
Edward-san (developer)
2015-06-20 16:50

Ok, what abouthttps://dl.dropboxusercontent.com/u/66055976/2015/builds/skulltag-r3089.7z [^] ?
User avatar (0012764)
Edward-san (developer)
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 .

User avatar (0013520)
Ru5tK1ng (updater)
2015-09-15 23:32

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.
User avatar (0013521)
DevilHunter (reporter)
2015-09-16 00:24

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.
User avatar (0013525)
DevilHunter (reporter)
2015-09-17 15:51

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
User avatar (0017997)
Ru5tK1ng (updater)
2017-07-09 23:23

WataKid couldn't reproduce this crash with today's build. I'd say this was fixed eventually somewhere down the line.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: Soul Argentum Combinebobnt Razgriz Mobius unknownna Ru5tK1ng
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2015-01-17 06:30 Ru5tK1ng New Issue
2015-01-17 06:30 Ru5tK1ng File Added: strifeburntest.wad
2015-01-17 07:27 Ru5tK1ng File Added: CrashReport-Strife.zip
2015-01-17 07:27 Ru5tK1ng Note Added: 0011403
2015-01-17 07:28 Ru5tK1ng Note Edited: 0011403 View Revisions
2015-06-13 06:02 unknownna Note Added: 0012672
2015-06-13 06:02 unknownna Reproducibility sometimes => always
2015-06-13 06:02 unknownna Status new => confirmed
2015-06-13 06:03 unknownna Status confirmed => feedback
2015-06-17 09:50 unknownna Note Added: 0012746
2015-06-17 09:50 unknownna Status feedback => confirmed
2015-06-17 09:53 unknownna Note Edited: 0012746 View Revisions
2015-06-17 09:54 unknownna Priority normal => urgent
2015-06-17 09:59 unknownna Note Edited: 0012746 View Revisions
2015-06-17 10:18 unknownna Note Edited: 0012746 View Revisions
2015-06-17 13:05 unknownna Note Edited: 0012746 View Revisions
2015-06-17 13:06 unknownna File Added: burn_weap_crash.wad
2015-06-17 13:06 unknownna File Added: CrashReport.zip
2015-06-17 13:07 unknownna Priority urgent => high
2015-06-17 13:07 unknownna Reproducibility always => sometimes
2015-06-17 13:11 unknownna Note Edited: 0012746 View Revisions
2015-06-17 15:53 WaTaKiD Note Added: 0012747
2015-06-18 10:13 Edward-san Note Added: 0012751
2015-06-18 10:22 unknownna Note Added: 0012752
2015-06-18 10:25 Edward-san Note Added: 0012753
2015-06-18 11:11 unknownna Note Added: 0012754
2015-06-18 11:12 unknownna Note Edited: 0012754 View Revisions
2015-06-18 11:24 unknownna Note Edited: 0012754 View Revisions
2015-06-18 12:31 unknownna Note Edited: 0012754 View Revisions
2015-06-20 12:02 Edward-san Note Added: 0012757
2015-06-20 12:29 unknownna Note Added: 0012758
2015-06-20 16:50 Edward-san Note Added: 0012763
2015-06-20 17:38 Edward-san Note Added: 0012764
2015-06-20 17:38 Edward-san Note Edited: 0012764 View Revisions
2015-06-20 17:44 Edward-san Note Edited: 0012764 View Revisions
2015-06-20 17:47 Edward-san Relationship added related to 0000193
2015-06-20 17:47 Edward-san Note Edited: 0012764 View Revisions
2015-06-20 17:48 Edward-san Note Edited: 0012764 View Revisions
2015-06-20 17:48 Edward-san Note Edited: 0012764 View Revisions
2015-06-20 17:48 Edward-san Note Edited: 0012764 View Revisions
2015-06-20 17:49 Edward-san Note Edited: 0012764 View Revisions
2015-06-20 17:49 Edward-san Note Edited: 0012764 View Revisions
2015-06-20 17:51 Edward-san Note Edited: 0012764 View Revisions
2015-09-15 23:32 Ru5tK1ng Note Added: 0013520
2015-09-16 00:24 DevilHunter Note Added: 0013521
2015-09-17 15:51 DevilHunter Note Added: 0013525
2017-07-09 23:23 Ru5tK1ng Note Added: 0017997
2017-07-09 23:23 Ru5tK1ng Status confirmed => resolved
2017-07-09 23:23 Ru5tK1ng Resolution open => unable to reproduce
2017-07-09 23:23 Ru5tK1ng Fixed in Version => 3.0
2017-07-09 23:23 Ru5tK1ng Target Version => 3.0






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker