Segfault in shemup mode during fighting in the hunting land

[l29ah]

(gdb) bt
#0  0x000055f99e4acf62 in hr::clearfrom (at=0x55f9fdf2f750) at cell.cpp:726
#1  0x000055f99e41a99a in hr::hrmap_hyperbolic::~hrmap_hyperbolic (this=0x55f9eafc9a10)
    at /var/tmp/portage/games-roguelike/hyperrogue-9999/work/hyperrogue-9999/cell.cpp:135
#2  0x000055f99e41a9c6 in hr::hrmap_hyperbolic::~hrmap_hyperbolic (this=0x55f9eafc9a10)
    at /var/tmp/portage/games-roguelike/hyperrogue-9999/work/hyperrogue-9999/cell.cpp:136
#3  0x000055f99e4b3dea in hr::clearCellMemory () at cell.cpp:1584
#4  0x000055f99e1dc9d3 in std::__invoke_impl<void, void (*&)()> (__f=@0x55f9de657798: 0x55f99e4b3d6e <hr::clearCellMemory()>)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/invoke.h:63
#5  0x000055f99e1dc7a0 in std::__invoke_r<void, void (*&)()> (__fn=@0x55f9de657798: 0x55f99e4b3d6e <hr::clearCellMemory()>)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/invoke.h:152
#6  0x000055f99e1dc33a in std::_Function_handler<void(), void (*)()>::_M_invoke (__functor=...)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std_function.h:292
#7  0x000055f99e23d926 in std::function<void()>::operator() (this=0x55f9de657798)
    at /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std_function.h:593
#8  0x000055f99e238294 in hr::hookset<void ()>::callhooks<>() const (this=0x55f99f30f840 <hr::hooks_clearmemory>)
    at /var/tmp/portage/games-roguelike/hyperrogue-9999/work/hyperrogue-9999/hyper.h:536
#9  0x000055f99e2348e9 in hr::callhooks<void()> (h=...)
    at /var/tmp/portage/games-roguelike/hyperrogue-9999/work/hyperrogue-9999/hyper.h:781
#10 0x000055f99e6e9afe in hr::clearMemory () at system.cpp:1772
#11 0x000055f99e605237 in hr::teleportToLand (l=hr::laHunting, make_it_safe=true) at game.cpp:257
#12 0x000055f99e605340 in hr::activateSafety (l=hr::laHunting) at game.cpp:271
#13 0x000055f99e9cedcf in hr::shmup::turn (delta=19) at shmup.cpp:2888
#14 0x000055f99ea6355d in hr::mainloopiter () at control.cpp:982
#15 0x000055f99ea6612e in hr::mainloop () at control.cpp:1633
#16 0x000055f99ec201e0 in hr::hyper_main (argc=1, argv=0x7ffd6f06b908) at hyper-main.cpp:91
#17 0x000055f99ec202df in main (argc=1, argv=0x7ffd6f06b908) at hyper-main.cpp:103

[josephcsible]

A few questions:

• What's the Git commit hash of the version you built from?
• Does this happen even if you build "vanilla" rather than through Portage?
• Can you give steps that will consistently reproduce this?
• Are lines 725 and 726 of your cell.cpp the same as this?

  hyperrogue/cell.cpp

  Lines 725 to 726 in dda35e7

  	for(int i=0; i<edges; i++) if(at->move(i) && at->move(i) != at) {
  	if(at->move(i)->alt != &deletion_marker)

[l29ah]

dda35e7
Never tried building it outside Portage; shouldn't differ much tho, as the build script is trivial: https://github.com/l29ah/booboo/blob/master/games-roguelike/hyperrogue/hyperrogue-9999.ebuild
No repro yet, it is my first day of playing shemup, and i got three crashes already (ony one with a backtrace), might only occur when a lot of orbs are active (my gut feeling says it is related to having both orb of speed and vaulting at the same time).
Yes.

[josephcsible]

On the same commit as you, picking up an Orb of Safety in the Hunting Ground in shmup mode with Orb of Speed and Orb of Vaulting both active doesn't trigger it.

I also don't understand what could be crashing on that particular line.

Can you try applying this patch, rebuilding, and then getting a new backtrace if it still crashes with it?

diff --git a/cell.cpp b/cell.cpp
index 2a9b7e88..cf956e09 100644
--- a/cell.cpp
+++ b/cell.cpp
@@ -722,17 +722,24 @@ EX void clearfrom(heptagon *at) {
       }
     int edges = at->degree();
     if(bt::in() && WDIM == 2) edges = at->c7->type;
-    for(int i=0; i<edges; i++) if(at->move(i) && at->move(i) != at) {
-      if(at->move(i)->alt != &deletion_marker)
-        q.push(at->move(i));    
-      unlink_cdata(at->move(i));
-      at->move(i)->alt = &deletion_marker;
-      if(debug_memory_cell) println(hlog, "!mov ", at->move(i), " [", at->move(i)->move(at->c.spin(i)), "]");
-      if(at->move(i)->move(at->c.spin(i)) != NULL &&
-        at->move(i)->move(at->c.spin(i)) != at)
+    for(int i=0; i<edges; i++) {
+      heptagon *&atmovei = at->move(i);
+      if(!atmovei)
+        continue;
+      if(atmovei == at)
+        continue;
+      heptagon *atmoveialt = atmovei->alt;
+      heptagon *deletion_marker_address = &deletion_marker;
+      if(atmoveialt != deletion_marker_address)
+        q.push(atmovei);
+      unlink_cdata(atmovei);
+      atmovei->alt = &deletion_marker;
+      if(debug_memory_cell) println(hlog, "!mov ", atmovei, " [", atmovei->move(at->c.spin(i)), "]");
+      if(atmovei->move(at->c.spin(i)) != NULL &&
+        atmovei->move(at->c.spin(i)) != at)
           throw hr_exception("hept error");
-      at->move(i)->move(at->c.spin(i)) = NULL;
-      at->move(i) = NULL;
+      atmovei->move(at->c.spin(i)) = NULL;
+      atmovei = NULL;
       }
     clearHexes(at);
     tailored_delete(at);

(Note that I don't expect that patch to fix the problem, just to make the line number give a more clear indication of what exactly is causing it.)

And/or if it crashes again, in addition to the backtrace, can you also do print at->move(i) and print *at->move(i) at the gdb prompt?

[zenorogue]

Judging by your other bug report, and the weirdness of the crash, it appears to be some memory corruption.

Memory corruption can sometimes happen if you compile a new version of the source code using "mymake" and it uses some old *.o files while the struct layouts have been changed in the meantime (mymake is not perfect). I do not know how portage works, so I do not know if this could happen, but I see the build script is using mymake. (If portage can reuse old build files, rm -rf mymake_files should be added to force a clean build, or make should be used instead.)

If the problem persists in a clean build, a good way to debug memory corruption is to compile with -fsanitize=address (although it makes the program much slower so I am not sure if shmup would still be playable).

Also some comments on the build script:

• you probably want to do mymake -O3 for an optimized build, although then you can no longer debug with gdb.
• flags HYPERROGUE_USE_GLEW=1 and HYPERROGUE_USE_PNG=1 are not used by mymake (only when the standard make is used to compile the whole game rather than just mymake).

(I have added a more detailed explanation of mymake quirks to README.md.)

[l29ah]

It never reuses old objects as it checks out git to a fresh directory every time.

I'll try using the address sanitizer. My computer is already struggling with drawing the dice reserve smoothly for some puzzling reason tho.

Optimizations are configured in other places, they are customizable by end-user and don't belong in the build script. I use -Og -ggdb3 now to produce the best core dumps for you.

[l29ah]

Ah, mymake ignores $CXXFLAGS. How to specify the compiler flags so it uses them? Apparently it doesn't like just putting them in arguments: file not found: -O2 -pipe -march=skylake -mtune=native -ftree-vectorize -malign-data=cacheline -mtls-dialect=gnu2 -Og -ggdb3 -fsanitize=address.cpp.

[josephcsible]

As a quick hack, you can edit mymake.cpp and add them to the set_linux function.

[zenorogue]

As another quick hack, mymake passes options starting with -f or -m to the compiler (so -fsanitize=address works), and it is possible to use " " to smuggle other options. So this seems to work:
./mymake "-march=skylake -O2 -pipe -mtune=native -ftree-vectorize -malign-data=cacheline -mtls-dialect=gnu2 -Og -ggdb3 -fsanitize=address"