Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Big Ol Billy

Bizarre, Inconsistent Signal 11 Crashes (PrB+ 2.5.1.4)

Recommended Posts

Some of you may have seen me mention this issue in the release thread for DBP16, but I wanted to put out a specific call for help. In 3+ weeks of investigating this bug, I've... not made a lot of progress on solving it. But I now have more information that might help a clever soul figure out this problem.

 

What problem? Well, to put it simply, we have a limit-removing wad that causes inconsistent Signal 11 crashes on some computers but not others (running with identical settings).

 

The issue seems entirely confined to PrB+ (2.5.1.4)--no apparent problems on Crispy, Eternity -vanilla, ZDoom 2.8.1, or GZDoom. Interestingly, the issue does not appear in the corresponding GlBoom+ version, either, which strikes me as particularly curious. I'm no stranger to Signal 11 errors, so I've checked the usual things like accidental PNGs, A_SkullAttack with no attack sound, etc. Unfortunately, it seems like Signal 11 is a very generic error message--as I understand it, it just means that the engine's trying to access something that isn't there.

 

Over the past few weeks, we've gotten enough people to play the wad that we now have a better idea of the basic pattern. It's pretty complicated to explain, but at this point I feel like I need to lay out the known behavior as extensively as possible. So apologies for the wall of text, but I think it's warranted in this case.

 

  • To reiterate the basic situation, several testers have experienced crashes in PrB+ -cl 2, with everyone's favorite cryptic error message: "I_SignalHandler: Exiting on signal 11"
  • The crashes are unpredictable but not totally random. Some maps and areas seem more likely to produce them (for example the opening of MAP10 in the set is a pretty common culprit). Sometimes they happen as quickly as 30-45 seconds into a map, sometimes you'll get a crash 15+ minutes after starting a map. Crash points can vary quite a bit within the same map--on one try you might get a crash in the first encounter, but then on the next you might nearly complete the map before crashing, or even make it through without one. No one has been able to reproduce any particular crash very reliably. Demos, admittedly, will crash consistently in the same spots, but no one's been able to identify a common denominator that leads to the crash behavior. 
  • The crashes don't seem to be the fault of particular maps or DeHackEd behavior. In fact, removing all maps and the DEHACKED lump in the wad produces the same behavior (i.e. inconsistent, unpredictable Signal 11 crashes on IWAD maps, with just the wad's graphic resources loaded).
  • Even when using the exact same configuration (PrB+ 2.5.1.4 -cl 2), some testers get no crashes on any maps even after extensively playing the wad. Only some setups, in other words, seem to have the problem. For example: Catpho recorded this MAP02 demo, which plays fine on their computer but crashes consistently midway through on my PrB+. (Interestingly, Cat's demo also plays fine on my GlB+.)
  • Some degree of activity seems necessary to trigger the crashes. On a computer that does produce crashes, just waiting around (standing still without activating any monsters or firing your weapon) doesn't seem to ever produce a crash, no matter how long you wait. Again, though, there doesn't seem to be any particular monster, weapon, item, decoration, texture, etc. that can be definitively linked to the crashes. At least not that we've been able to figure out.
  • One tester found that the crashes don't seem to happen with -nodraw, reinforcing the suspicion that this is some peculiar, setup-specific (?), graphics-based error.

 

I'm just about at a loss at this point about what to do next. Any ideas or suggestions?

Share this post


Link to post

What I usually do in these kind of situations (for the Eternity Engine) is to test the same version of the engine against older development builds of the mod, and see if any changes in the mod triggers this crash. If not, I'd test the latest mod version against older development builds of the engine, and see at which point this behavior got introduced. This usually helps the developers pin down the (what I think is a ) memory leak a lot faster.

Share this post


Link to post

prboom+ must be hooking some system stuff that windows update changes. this is my recent theory? doing the major update this year fixed a bunch of transparency issues i was having

don't know if that helps, i've only ever seen signal 11 crashes in test wads of my own and i don't know why they occurred either lol

Share this post


Link to post
15 hours ago, yakfak said:

rboom+ must be hooking some system stuff that windows update changes

I think the OP is using Linux, signal 11 is a unix-type error generally caused by trying to use a NULL pointer, whereas Windows produces a different message (General Protection Fault or something like that).

 

If you are compiling PrBoom from source, then you can enable debugging symbols (add -g3 to GCC options) and disable optimisations (use -O0 instead of -O2 or whatever) and then run the program in gdb.  When it crashes, it will show exactly where in the program it crashed.

 

gdb --args myprboom -file blah.wad

 

Share this post


Link to post

This is a long shot, but for anyone who can reproduce a signal 11 crash on command, have you tried running the game with the -nosound parameter? If that avoids a crash, how about playing with the -nomusic parameter? Years ago, I was experiencing frequent signal 11 crashes in PrBoom+, but it seemed only my particular setup was susceptible to it. The -nosound parameter did circumvent my crashing problem, but that's obviously not ideal. Ultimately, entryway released an update which fully solved my particular crashing issue, but these sound disabling parameters may at least help you narrow down a cause right now.

 

Also, entryway told me to use the -devparm parameter when looking out for crashes as that will force the engine to produce an address during crashes rather than the generic signal 11 message.

Share this post


Link to post

if it is not the maps or the DEHACKED lump, then it must be the additional resources.

 

So try removing all flats and all maps and see if the crash in IWAD maps still occurs.  If it does, remove the TEXTURE1 and PNAMES and try again.  Still crashing, try removing all sprites.

 

Unfortunately I couldn't trigger the crash here on my Linux computer.

 

P.S. it is possible that screen resolution is a factor.  Maybe there is a bug that affects very big window widths or heights.

Edited by andrewj

Share this post


Link to post
On vendredi 25 octobre 2019 at 11:04 PM, Big Ol Billy said:

The crashes don't seem to be the fault of particular maps or DeHackEd behavior. In fact, removing all maps and the DEHACKED lump in the wad produces the same behavior (i.e. inconsistent, unpredictable Signal 11 crashes on IWAD maps, with just the wad's graphic resources loaded).

Have you tried dichotomy search on the graphic resources? That is to say, remove half of them. If crash no longer happens, test the other half, or add back half of what you've removed so far. If crash still happens, remove half of what you've still got. Doing this approach is the most efficient way to find the files that cause problems when you have no idea what the problem with them actually is.

Share this post


Link to post

Hi, I saw your talk about a problem with this wad in Not Jabba's review thread and decided to investigate.

 

The problem appears to be the statubar face graphics. Specifically STFST30, STFST31, STFST32, STFTL30, STFLR30 are what gave me problems with Catpho's demo.

 

Changing the vertical offset on the STFST3x graphics to be -1, and STFTx30 to be 0, made that demo no longer crash for me. I have no idea why the offsets are causing a problem since the graphics look to be the same dimensions as the normal Doom ones.

 

Other statusbar face graphics may also cause problems if they didn't appear in Catpho's demo; I didn't examine the issue further. An alternative solution might be just to put all the face graphics in a separate wad and warn people that they might crash PrBoom+.

 

Also, I didn't get any crashes in PrB+ 2.4.1.7um on Linux, I had to get 2.4.1.4 for Windows and run it in Wine to cause a crash.

Edited by plums

Share this post


Link to post

OMG Plums, I can't check this at the moment, but it sounds like you might really be on to something here! If I can carve out some time in my Doomtime soon (still catching up on some DBP26 stuff in progress) I'll do a proper investigation. Thanks for looking into this, I really appreciate it!

Share this post


Link to post

You're welcome!

 

Looking at the face graphics in doom2.wad, it seems like some of those have different offsets than the ones you have in the DBP wad. Matching all of the offsets up should probably eliminate the chance for any of them to cause crashes.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×