Duke3D: Crash to desktop when saving game (related to savegame labels)
Most likely starts with revision 687000e2, but this is an educated guess.
I cannot reproduce this myself, but this has been reported in two separate instances, leading me to believe this is an engine issue.
- https://forums.duke4.net/topic/11422-demon-throne-released/page__view__findpost__p__350759
- https://forums.duke4.net/topic/11420-release-cosmetic-duke-version-18-is-up/page__view__findpost__p__350813
Now contrary to what is said in one of the two threads, I'm pretty sure this has nothing to do with userbyteversion
especially since the other mod made no use of this struct member. The revision used in both cases was r9257.
A common aspect of the crash is that the message "couldn't find savegame label"
appears at the end of the log, notably without any actual label being printed (i.e. there's just whitespace where there is supposed to be a label string). These printf statements originate from the "savegame format update WIP" commit (687000e2) and are found in savegame.cpp : static void sv_postactordata(void)
. There are 3 separate instances of this command, don't know which one is being executed as their structure is identical.
My best guess is that there's a segfault occurring, probably in that same function as the printf itself.
EDIT: Further information: crash report
Crash apparently occurs at the assert in savegame.cpp:2033
. It cannot find the label index. r8942 supposedly works fine for the user, but as aforementioned, I don't experience the same issues with the current revision (r9269) when playing "Cosmetic Duke".
// translate anything in actor[] that holds an offset into compiled CON into a label index
static void sv_preactorsave(void)
{
for (int i = 0; i < MAXSPRITES; i++)
{
actor_t &a = actor[i];
if ((unsigned)AC_MOVE_ID(a.t_data) + 3 < (unsigned)g_scriptSize && apScript[AC_MOVE_ID(a.t_data) + 3] == CON_MOVE)
{
int const index = sv_findlabelindex(AC_MOVE_ID(a.t_data), LABEL_MOVE | LABEL_DEFINE);
Bassert(index != -1);
AC_MOVE_ID(a.t_data) = index;
a.flags |= SFLAG_RESERVED;
}
...
EDIT 2: It turns out that I actually did encounter this issue before, on September 12th this year. Back then I attributed the crash to a different problem but I know now that this is not the case.
Backtrace I took when this occurred: