View Issue Details

IDProjectCategoryView StatusLast Update
0000077Gameplay + OpenGL[All Projects] Bugpublic2017-01-20 15:43
ReporterXaser 
Assigned To 
PrioritynormalSeveritycrashReproducibilitysometimes
Status resolvedResolutionnot fixable 
PlatformPCOSWindowsOS Version7
Summary0000077: [v2.3.2] ARGENT Rocket Suicide Crash
DescriptionIn the current ZScript-build of ARGENT (see here: http://static.angryscience.net/pub/doom/mods/argent/pre/xa-argen_0.4.0_pre-5aabc1f.pk3 ), suiciding via the the Rocket Launcher's Remote Detonate can sometimes crash the game with an Access Violation.

Probable self-diagnosis: Line 289 in zscript/argent/weapons/rocket.txt is suspect, since it's running on the same tic the A_Explode calls happen, meaning the player may die before the loop is complete; are the 'player.rockets' and 'player.numRockets' variables getting trashed when the player dies, causing shenanigans?

tl;dr: The actual crash source is likely a case of [User Error], but Crashes Suck(tm) so if there's any way to turn it into a VM abort or something similar, that'd be nice.


[Self-musing: I can likely work around this by delaying the A_Explode calls one tic, or just moving all the rocket handling out of the PlayerPawn like I've been planning on doing for a bit now.]
Steps To ReproduceSummon "ArgRocketLauncher" and an "ArgModKit"; use the kit (INVUSE) and select the Remote Detonation mod (+ATTACK with the Rocket Launcher selected). Fire a rocket (+ATTACK) and immediately detonate it in your face (+ALTATTACK); repeat until dead. The game will sometimes crash with an access violation when the player dies.
TagsNo tags attached.

Relationships

Activities

Graf Zahl

Graf Zahl

2017-01-20 13:32

administrator   ~0000165

This is a bad case of uncontrolled state function chaining due to having no delays. Sorry, but it's unfixable - I cannot even trace where the bogus value comes from, it looks like some things overwriting each other.

Surely are crashes bad, but with this setup they are inevitable. If you start an action that may kill the caller, there *MUST* be a one frame delay between the state jump and the action, otherwise all bets are off.

The crash doesn't even happen in the VM, it happens in the GL renderer because the weapon sprite data is broken, presumably because the death action interrupts the A_Overlay call that starts the detonation.
Xaser

Xaser

2017-01-20 15:43

developer   ~0000174

Well, color me stumped -- I still get the crash even after delaying the rocket's A_Explode calls by a tic. The Arg_A_DetonateRockets function won't retrigger more than once per +ALTATTACK hold, so it ought not be conflicting anymore; is the call to Arg_A_SynthAltFire 1 tic later ('Mod1DetonateHold' label) causing the blowup instead? That function causes a state jump if the player isholding +ALTATTACK... though that ought not be happening if they're dead. :P

I do plan on refactoring all this code anyway (including adding a little animation to the overlay when detonating), so hopefully that means the issue will go 'poof', but that leaves me with unease still as I don't yet know what's caused the problem (and how to avoid it in the future).

Issue History

Date Modified Username Field Change
2017-01-19 11:06 Xaser New Issue
2017-01-20 13:32 Graf Zahl Note Added: 0000165
2017-01-20 13:33 Graf Zahl Status new => resolved
2017-01-20 13:33 Graf Zahl Resolution open => not fixable
2017-01-20 15:43 Xaser Note Added: 0000174