Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Random crashing #730

Open
buvk opened this issue Apr 2, 2021 · 8 comments
Open

Random crashing #730

buvk opened this issue Apr 2, 2021 · 8 comments
Labels

Comments

@buvk
Copy link

buvk commented Apr 2, 2021

Background

Version of Crispy Doom: Release Crispy Doom 5.10.1

Operating System and version: Win 10 20H2 19042.867

Game: (Doom/Heretic/Hexen/Strife/other): Doom 2 v1.9

Any loaded WADs and mods (please include full command line):

  • btsx_e1.deh btsx_e1a.wad btsx_e1b.wad
    autoload\doom2.wad
  • d2spfx18.wad
  • doom2_widescreen.wad (custom wad containing widescreen replacements for BOSSBACK, CREDIT, HELP, INTERPIC, TITLEPIC)
    autoload\doom-all
  • dssecret.wad (custom wad containing replacement DSSECRET)
  • stbar.wad (custom wad containing replacement STBAR)

Bug description

Observed behavior: I have been playing through BTSX E1 using the latest Crispy release. I've probably played about 3-4 hours so far, and have encountered 4 crashes (game just exists completely, no error). I have not been able to replicate the crashing at specific areas; it just seems to happen randomly.

Expected behavior: No crashing

@fabiangreffrath
Copy link
Owner

Oh, crap! Does this also happen without the custom content PWADs loaded? Could you probably make them available somewhere?

@buvk
Copy link
Author

buvk commented Apr 3, 2021

Unfortunately I am not sure. I do not play very often either, so I don't know this is a new issue or not. I will try playing without autoloading the 4 PWADs.

autoload.zip

@JNechaevsky
Copy link
Collaborator

I think I've caught it... It takes about ~30 minutes, here's what I have done:

  1. gdb --args ./crispy-doom.exe -file doom2_widescreen.wad dssecret.wad stbar.wad btsx_e1a.wad btsx_e1b.wad
  2. Then let demo sequence to be run for about 10 minutes.
  3. Then started a new game (UV), and stared to run through the every map with IDDT, IDCLIP and IDFA while constantly firing chaingun, and once it's run out of ammo - with plasmagun.
  4. Finally, on MAP09 I've got a lock-up. Here's gdb output:
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00fdf4af in R_DrawColumn () at r_draw.c:173
173             *dest = dc_colormap[dc_brightmap[source]][source];

... and backtrace:

(gdb) bt
#0  0x00fdf4af in R_DrawColumn () at r_draw.c:173
#1  0x00fe2f05 in R_RenderSegLoop () at r_segs.c:437
#2  0x00fe38ab in R_StoreWallRange (start=236, stop=374) at r_segs.c:897
#3  0x00ff68a7 in R_AddLine (line=line@entry=0x4c79674) at r_bsp.c:381
#4  0x00ff6af3 in R_Subsector (num=156) at r_bsp.c:579
#5  0x00ff6be1 in R_RenderBSPNode (bspnum=151) at r_bsp.c:617
#6  0x00ff6be1 in R_RenderBSPNode (bspnum=153) at r_bsp.c:617
#7  0x00ff6be1 in R_RenderBSPNode (bspnum=154) at r_bsp.c:617
#8  0x00ff6be1 in R_RenderBSPNode (bspnum=168) at r_bsp.c:617
#9  0x00ff6be1 in R_RenderBSPNode (bspnum=178) at r_bsp.c:617
#10 0x00ff6be1 in R_RenderBSPNode (bspnum=179) at r_bsp.c:617
#11 0x00ff6be1 in R_RenderBSPNode (bspnum=325) at r_bsp.c:617
#12 0x00ff6be1 in R_RenderBSPNode (bspnum=326) at r_bsp.c:617
#13 0x00ff6be1 in R_RenderBSPNode (bspnum=526) at r_bsp.c:617
#14 0x00ff6be1 in R_RenderBSPNode (bspnum=956) at r_bsp.c:617
#15 0x00ff6be1 in R_RenderBSPNode (bspnum=1026) at r_bsp.c:617
#16 0x00ff6be1 in R_RenderBSPNode (bspnum=1201) at r_bsp.c:617
#17 0x00fe1be3 in R_RenderPlayerView (player=0x112ea80 <players>)
    at r_main.c:1119
#18 0x00fb4b47 in D_Display () at d_main.c:246
#19 0x00fb526d in D_RunFrame () at d_main.c:535
#20 0x00fb534d in D_DoomLoop () at d_main.c:597
#21 0x00fb6a48 in D_DoomMain () at d_main.c:2264
#22 0x00f9277a in SDL_main (argc=7, argv=0xd00008) at i_main.c:79
#23 0x00f925dc in main_getcmdline ()
#24 0x00f92648 in WinMain@16 ()
#25 0x0100e5cd in main (flags=7, cmdline=0xdb1a70, inst=0xdb1ce8)
    at C:/_/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18
(gdb)

...erm... 😨

Here's a full output (output.txt), but it's showing incorrect P_SetupLevel: MAP02. For some reason, gdb is a bit laggy on Windows. And here's where I've a lock-up (screenshot).

@turol
Copy link
Collaborator

turol commented Apr 4, 2021

I tested this on Linux with Valgrind. Let the demos play, started a new game, warped to level 09 and ran around a bunch. No errors. Needs a simpler repro.

@JNechaevsky
Copy link
Collaborator

In my case it was a way through map01 -> map02 -> map03 ... map09. Direct warping to map09 does not give any errors, matters no how the level is IDCLIPed.

@fabiangreffrath
Copy link
Owner

Does it make a difference if brightmaps are enabled?

@turol
Copy link
Collaborator

turol commented Apr 4, 2021

Let the demos play once through, new game, warped through levels 1-9. Ran around level 9 a bunch with IDDQD and IDCLIP on. No crashes or Valgrind errors.

@JNechaevsky
Copy link
Collaborator

Now I don't have a crash either with this scenario (brightmaps are always enabled to "both" at me).
Was it a cockroach running over my CPU? 😞 The only thought I have for now - need to check huge amount of brightmapped textures in one frame.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants