To replicate:
Get this commit (though any recent one will do)
Find some place with no monsters
In the console type "give fire 100" to set yourself on fire
Try to put out the fire by crouching and spinning as fast as you can
The segfault should happen within the first few tries. I have not been able to get it to happen while the player is not on fire, or in GL.
[3.1.0] Segfault with Hideous Destructor fire
Moderator: GZDoom Developers
Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.
If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.
Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.
If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.
Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
Re: [3.1.0] Segfault with Hideous Destructor fire
Is there any possible way to have a more minimal example for this, or is this problem only reproducible with the entire mod?
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: [3.1.0] Segfault with Hideous Destructor fire
I wish I knew how to isolate it!
The same thing also seems to be causing a desync... seems like that doesn't have anything to do with turning at all. Let me see if I can resolve this desync and maybe this crash could be isolatable.
EDIT: Now that I've replaced DoEffect() with Tick() in the thing that was causng the desync, I can no longer replicate this crash. o_O Got it just fine in a netgame.
The same thing also seems to be causing a desync... seems like that doesn't have anything to do with turning at all. Let me see if I can resolve this desync and maybe this crash could be isolatable.
EDIT: Now that I've replaced DoEffect() with Tick() in the thing that was causng the desync, I can no longer replicate this crash. o_O Got it just fine in a netgame.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: [3.1.0] Segfault with Hideous Destructor fire
I think I've narrowed it down to what must be called to cause the segfault. (Commented-out portion, I've just highlighted an earlier line for reference)
Testing: start co-op game on map "range" with 2 instances, 1 GL (admin) and 1 software. Admin grabs plasma rifle from the side (hit use), hit altfire once to change modes, hit software player with 3 shots, switch to software player, crouch+spin until the numbers stop showing.
(EDIT: I can get this in singleplayer as well.)
I have not been able to get a segfault as long as I keep that SetOrigin() call commented out.
Replacing that call with "setorigin(target.pos,false);" still gets the segfault.
Using SetXYZ instead makes it crash even faster.
It seems like a matter of reading the target's position. This commit crashes, but the one right before it does not.
(I should add that adding an "if(target)" immediately before the offending setorigin call does nothing since the target is already being checked earlier.)
Moving the SetOrigin call out to another frame does not prevent the crash.
Using A_Warp inside the original anon function crashed almost the moment I started crouching.
Not even moving A_Warp to a different frame with an entire tic between them prevents the crash.
It may be a problem with my custom fire actor. Replacing it with my debris actor or BulletPuff (and then commenting out the smoke spawn) seems to prevent the crash.
Testing: start co-op game on map "range" with 2 instances, 1 GL (admin) and 1 software. Admin grabs plasma rifle from the side (hit use), hit altfire once to change modes, hit software player with 3 shots, switch to software player, crouch+spin until the numbers stop showing.
(EDIT: I can get this in singleplayer as well.)
I have not been able to get a segfault as long as I keep that SetOrigin() call commented out.
Replacing that call with "setorigin(target.pos,false);" still gets the segfault.
Using SetXYZ instead makes it crash even faster.
It seems like a matter of reading the target's position. This commit crashes, but the one right before it does not.
(I should add that adding an "if(target)" immediately before the offending setorigin call does nothing since the target is already being checked earlier.)
Moving the SetOrigin call out to another frame does not prevent the crash.
Using A_Warp inside the original anon function crashed almost the moment I started crouching.
Not even moving A_Warp to a different frame with an entire tic between them prevents the crash.
It may be a problem with my custom fire actor. Replacing it with my debris actor or BulletPuff (and then commenting out the smoke spawn) seems to prevent the crash.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: [3.1.0] Segfault with Hideous Destructor fire
It seems that I can never get the likelihood of the crash to zero, but the chances of it happening go up with each of the following:
- Spawning my custom fire actor (or anything inheriting from "HDPuff") instead of, say, BulletPuff or nothing at all.
- Having the setorigin call reference the target's position.
- Repositioning in any way with reference to the target.
- Running a netgame.
I am completely stumped as to what might be causing it or how I could replicate this behaviour outside this extremely narrow context.
EDIT: ...I'm starting to think it's my computer. It seems I just segfaulted for no reason at all in GL mode doing something totally unrelated.
EDIT: Somehow this does not crash:This would spawn the flames around (0,0,0) on the map instead of around the player.
Maybe it's got something to do with collision? When the player is spinning to put out the fire, the playerpawn is set up to move involuntarily and if the fire actor doesn't constantly warp to the player's positon to place the flame sprite, it could end up placing it quite far away.
Neither getting rid of the custom Tick() override nor setting +nointeraction prevents the crash.
EDIT: If I replace all instances of the SMOK sprites with PUFF, I can't replicate the segfault. Doesn't fix anything, at least not after using TEXTURES to resize and translate the PUFF into something remotely resembling what it was replacing.
- Spawning my custom fire actor (or anything inheriting from "HDPuff") instead of, say, BulletPuff or nothing at all.
- Having the setorigin call reference the target's position.
- Repositioning in any way with reference to the target.
- Running a netgame.
I am completely stumped as to what might be causing it or how I could replicate this behaviour outside this extremely narrow context.
EDIT: ...I'm starting to think it's my computer. It seems I just segfaulted for no reason at all in GL mode doing something totally unrelated.
EDIT: Somehow this does not crash:
Code: Select all
...
if(!target){
target=spawn("PersistentDamager",self.pos);
target.target=master;
if(stamina>20)stamina=20;
}
setorigin(target.pos,false);
...
setorigin(pos*0+(
random(-halfrad,halfrad),
random(-halfrad,halfrad),
random(minz,maxz)
),false);
actor sp=spawn("HDFlameRed",pos);
...
Maybe it's got something to do with collision? When the player is spinning to put out the fire, the playerpawn is set up to move involuntarily and if the fire actor doesn't constantly warp to the player's positon to place the flame sprite, it could end up placing it quite far away.
Neither getting rid of the custom Tick() override nor setting +nointeraction prevents the crash.
EDIT: If I replace all instances of the SMOK sprites with PUFF, I can't replicate the segfault. Doesn't fix anything, at least not after using TEXTURES to resize and translate the PUFF into something remotely resembling what it was replacing.