[Redneck.RidesAgain] Always Crashes on specific area

[LkMax]

Hello,

I've had a unavoidable crash in "Redneck Rampage Rides Again", in a specific area (on the Refinery map) that's not allowing me to progress.
I've attached the auto-generated zip and the save game. If any other file may be useful to investigate this bug, just tell me.
Also below are screenshots of the area that's giving me problem.

https://i.imgur.com/XrduqlU.png
https://i.imgur.com/JZegH87.png

Regards.

[LkMax]

PS: Additional info, I loaded the game from a very early save (from just starting the map), played all the way to that area without saving or loading, and managed to pass through it without crashing.

[Guest]

Dear LkMax:
I did what you sugested. and still crashes when i try to go through, i think raze develpers should fix this issue.

Sincerely ELJUAN5663.

[Graf Zahl]

The problem is known - at some point a texture index becomes invalid - unfortunately I have no idea where this happens and the crash seems to be intermittent and not reliably to reproduce so I haven't been able to further debug it. The main problem is that at the point where it crashes it's already too late to do something about it.

[Oet]

I compiled Raze on Arch Linux. My game crashes at this exact same spot: https://i.imgur.com/XrduqlU.png

You might already know this, but the error is as follows:

Code: Select all

~/Raze/source/common/utility/tarray.h:307: T& TArray<T, TT>::operator[](size_t) const [with T = int; TT = int; size_t = long unsigned int]: Assertion `index <= Count' failed.

At that point jackalopes should be dropping on the boxes nearby.

[Graf Zahl]

That line does not help, I'd,need the entire call trace.

[Oet]

My debugging knowledge only goes so far:

Code: Select all

~/source/common/utility/tarray.h:307: T& TArray<T, TT>::operator[](size_t) const [with T = int; TT = int; size_t = long unsigned int]: Assertion `index <= Count' failed.

��signal

Thread 1 "raze" received signal SIGABRT, Aborted.

��frame-begin 0 0x7ffff73be4dc
0x00007ffff73be4dc in ?? () from /usr/lib/libc.so.6

��stopped

I can help if you know what commands I should give gdb.

[Graf Zahl]

But that does not help as the crash occurs in a generic utility class. That class is fine, but it's used incorrectly.

[_mental_]

I can help if you know what commands I should give gdb.

Use bt command to get a stack trace.

[Oet]

I can help if you know what commands I should give gdb.

Use bt command to get a stack trace.

Code: Select all

(gdb) bt
#0  0x00007ffff73b94dc in  () at /usr/lib/libc.so.6
#1  0x00007ffff7369998 in raise () at /usr/lib/libc.so.6
#2  0x00007ffff735353d in abort () at /usr/lib/libc.so.6
#3  0x00007ffff735345c in  () at /usr/lib/libc.so.6
#4  0x00007ffff73624c6 in  () at /usr/lib/libc.so.6
#5  0x0000555555aaaf5f in TArray<int, int>::operator[](unsigned long) const
    (this=0x555556e6e750 <Duke3d::ScriptCode>, index=1463816864)
    at ~/source/common/utility/tarray.h:307
#6  0x0000555555f160ed in Duke3d::CreateActor(sectortype*, TVector3<double> const&, int, signed char, signed char, signed char, int, int, int, Duke3d::DDukeActor*, signed char)
    (whatsectp=0x5555640673d0, pos=..., s_pn=-19029, s_s=0 '\000', s_xr=0 '\000', s_yr=0 '\000', s_a=0, s_ve=0, s_zv=0, s_ow=0x55555eed8750, s_ss=0 '\000')
    at ~/source/games/duke/src/spawn.cpp:109
#7  0x0000555555f21058 in Duke3d::EGS(sectortype*, int, int, int, int, signed char, signed char, signed char, int, int, int, Duke3d::DDukeActor*, signed char)
    (whatsectp=0x5555640673d0, s_x=-29248, s_y=72128, s_z=28672, s_pn=-19029, s_s=0 '\000', s_xr=0 '\000', s_yr=0 '\000', s_a=0, s_ve=0, s_zv=0, s_ow=0x55555eed8750, s_ss=0 '\000') at ~/source/games/duke/src/funct.h:178
#8  0x0000555555f168aa in Duke3d::spawn(Duke3d::DDukeActor*, int)
    (actj=0x55555eed8750, pn=-19029)
    at ~/source/games/duke/src/spawn.cpp:220
#9  0x0000555555ec4d21 in Duke3d::movefx() ()
   duke/src/actors.cpp:541
#10 0x0000555555f77528 in Duke3d::think_r() () at ~/source/games/duke/src/actors_r.cpp:4052
#11 0x0000555555f0142f in Duke3d::GameInterface::Ticker() (this=0x5555572c8240) at ~/source/games/duke/src/gameloop.cpp:89
#12 0x0000555555b890c1 in GameTicker() () at ~/source/core/mainloop.cpp:357
#13 0x0000555555b89aa8 in TryRunTics() () at ~/source/core/mainloop.cpp:657
#14 0x0000555555b89c3e in MainLoop() () at ~/source/core/mainloop.cpp:715
#15 0x0000555555b927c6 in RunGame() () at ~/source/core/gamecontrol.cpp:1139
#16 0x0000555555b9079e in GameMain() () at ~/source/core/gamecontrol.cpp:598
#17 0x00005555559cc7fa in main(int, char**)Python Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0x7fffffffd6cc

Will this suffice to pinpoint the cause of the crash? (I replaced my custom folders by '~'.)

[Black Hand Inn]

Has a solution for this bug been found? I'm having the exact same issue. Trying to go through the level from an earlier save (the auto-save from the beginning of the level) doesn't work either. It still crashes at that exact same spot.

[Rachael]

Has a solution for this bug been found? I'm having the exact same issue. Trying to go through the level from an earlier save (the auto-save from the beginning of the level) doesn't work either. It still crashes at that exact same spot.

No, and pestering is not going to bring about a solution any faster.

[Talon1024]

It looks like the problem is a RESPAWN sprite (picnum 9) with a bad hitag. Using these GDB commands, I think I found the offending actor:

Code: Select all

set $actor = statList[STAT_FX].firstEntry
define nextstat
y
if $actor.spr.picnum == 9
p "picnum"
p $actor.spr.picnum
p "hitag"
p $actor.spr.hitag
p "index"
p $actor.time
end
set $actor = $actor.nextStat
if $actor == statList[STAT_FX].lastEntry
p "Reached end of statList[STAT_FX]"
set $actor = statList[STAT_FX].firstEntry
end
end

And this is some information (picnum, hitag, index) about the offending actor:

Code: Select all

$44 = "picnum"
$45 = 9
$46 = "hitag"
$47 = -19029
$48 = "index"
$49 = 383

[Graf Zahl]

Thanks for pointing that one out. In the original it produced an unregistered out of bounds access, but this surely trips the stronger validation checks.