Crashes, most often when starting or finishing levels?

Found a bug in R'n'D? Report it here!

Moderators: Zomis, Flumminator

BryanFRitt
Posts: 77
Joined: Mon Nov 13, 2017 4:16 pm

Re: Crashes, most often when starting or finishing levels?

Post by BryanFRitt » Sat Jan 04, 2020 5:18 am

So there's the question: Do you have "game engine snapshot mode" (unter "setup" -> "game & menu") set to anything other than "off"?
This was set to 'Every Step'.
Just tried it set to off, it still crashes.
Based on the name and 'off' it sounds like it won't be able to save game playback even if that isn't what it does. What does it do?
Here's a copy of my ~/.rocksndiamonds/setup.conf file:
setup.conf
(10.59 KiB) Downloaded 41 times
---
By the way, I've noticed that a lot of playbacks the character ends up one space away from where it should be, even when the 'QUICK LOAD GAME FROM TAPE' of a save from the same run of Rocks'n'Diamonds is in the right place.
---
After setting "game engine snapshot mode" to off, and saving settings then exiting and restarting RnD, I think I was going back and forth between playing and the menu during this crash, it ended with them menu showing...
free(): double free detected in tcache 2

Thread 1 "rocksndiamonds" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff789f535 in __GI_abort () at abort.c:79
#2 0x00007ffff78f6508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7a0128d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff78fcc1a in malloc_printerr (str=str@entry=0x7ffff7a02f58 "free(): double free detected in tcache 2") at malloc.c:5341
#4 0x00007ffff78fe6fd in _int_free (av=0x7ffff7a38c40 <main_arena>, p=0x55555fb088c0, have_lock=<optimized out>) at malloc.c:4193
#5 0x0000555555712553 in checked_free (ptr=0x55555fb088d0) at misc.c:1275
#6 0x0000555555711550 in setString (old_value=0x555558608050 <tape+16>, new_value=0x55555c72cc60 "rnd_martijn_mooij_ii") at misc.c:844
#7 0x00005555556eb9da in TapeErase () at tape.c:530
#8 0x00005555556ebb96 in TapeStartRecording (random_seed=1580583585) at tape.c:584
#9 0x00005555556a6e90 in StartGameActions (init_network_game=0, record_tape=1, random_seed=0) at game.c:11320
#10 0x0000555555662557 in HandleMainMenu (mx=0, my=0, dx=0, dy=0, button=0) at screens.c:2107
#11 0x0000555555648597 in HandleKey (key=13, key_status=1) at events.c:2272
#12 0x0000555555646b75 in HandleKeyEvent (event=0x7fffffffda30) at events.c:1445
#13 0x0000555555644a98 in HandleEvents () at events.c:233
#14 0x0000555555644c6e in EventLoop () at events.c:328
#15 0x00005555556381aa in main (argc=1, argv=0x7fffffffdb88) at main.c:7762

BryanFRitt
Posts: 77
Joined: Mon Nov 13, 2017 4:16 pm

Re: Crashes, most often when starting or finishing levels?

Post by BryanFRitt » Tue Jan 07, 2020 4:05 pm

Just found another program that has the "double free detected in tcache 2". `xbindkeys-config` it would crash this way right at startup. I renamed it's config file* and it no longer crashes this way at startup. Perhaps this is a similar issue that RnD is having with me?

*(so it won't use it, renaming from ~/.xbindkeysrc to something else)
UPDATE: changing the escaping characters in some of the parts of the config got it to keep the config and still use it. (well at least with the editor)
(gdb) run
Starting program: /usr/bin/xbindkeys-config
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
free(): double free detected in tcache 2

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff72bf7bb in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff72aa535 in __GI_abort () at abort.c:79
#2 0x00007ffff7301508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff740c28d "%s\n")
at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff7307c1a in malloc_printerr (str=str@entry=0x7ffff740df58 "free(): double free detected in tcache 2")
at malloc.c:5341
#4 0x00007ffff73096fd in _int_free (av=0x7ffff7443c40 <main_arena>, p=0x5555558d7510, have_lock=<optimized out>) at malloc.c:4193
#5 0x0000555555559c4b in ()
#6 0x0000555555559da1 in ()
#7 0x0000555555557141 in ()
#8 0x00007ffff72ac09b in __libc_start_main (main=
0x555555556e60, argc=1, argv=0x7fffffffdcf8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdce8) at ../csu/libc-start.c:308
#9 0x000055555555730a in ()

BryanFRitt
Posts: 77
Joined: Mon Nov 13, 2017 4:16 pm

Re: Crashes, most often when starting or finishing levels?

Post by BryanFRitt » Sun Jan 12, 2020 4:22 am

Still happens[for me] with the new 4.1.4.0 same system...
run from
gdb rocksndiamonds
set args --debug
run
...
rocksndiamonds: debug mode disabled
rocksndiamonds: frame delay == 20 ms (max. 50 fps / 100 %)
corrupted double-linked list

Thread 1 "rocksndiamonds" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff78a2535 in __GI_abort () at abort.c:79
#2 0x00007ffff78f9508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7a0428d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff78ffc1a in malloc_printerr (str=str@entry=0x7ffff7a02393 "corrupted double-linked list") at malloc.c:5341
#4 0x00007ffff78ffe64 in malloc_consolidate (av=av@entry=0x7ffff7a3bc40 <main_arena>) at malloc.c:4488
#5 0x00007ffff790179a in _int_free (av=0x7ffff7a3bc40 <main_arena>, p=0x55555b3e3b70, have_lock=<optimized out>) at malloc.c:4392
#6 0x0000555555713b23 in checked_free (ptr=0x55555b3e3b80) at misc.c:1275
#7 0x0000555555705cb7 in FreeSnapshotBuffer (bi_raw=0x55555c1ddcb0) at snapshot.c:72
#8 0x0000555555714fda in deleteNodeFromList (node_first=0x7fffffffd918, key=0x0, destructor_function=0x555555705c6d <FreeSnapshotBuffer>) at misc.c:2084
#9 0x0000555555705cec in FreeSnapshotBuffers (snapshot_buffers=0x55555f807e90) at snapshot.c:79
#10 0x0000555555705d26 in FreeSnapshotSingle () at snapshot.c:93
#11 0x0000555555705ebb in SaveSnapshotSingle (snapshot_buffers=0x55555b13f160) at snapshot.c:177
#12 0x00005555556b3e03 in SaveEngineSnapshotSingle () at game.c:15383
#13 0x00005555556ed81f in TapeQuickSave () at tape.c:1023
#14 0x000055555564a4ae in HandleKey (key=1073741891, key_status=1) at events.c:2241
#15 0x0000555555648c63 in HandleKeyEvent (event=0x7fffffffda10) at events.c:1462
#16 0x0000555555646b84 in HandleEvents () at events.c:249
#17 0x0000555555646d67 in EventLoop () at events.c:348
#18 0x000055555563a1ca in main (argc=2, argv=0x7fffffffdb68) at main.c:7762
running again...
I think I was trying to do a save tape... I'm thinking this is when a lot of these crashes occurs. [like save tape at end of level...]
double free or corruption (out)

Thread 1 "rocksndiamonds" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff78a2535 in __GI_abort () at abort.c:79
#2 0x00007ffff78f9508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7a0428d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x00007ffff78ffc1a in malloc_printerr (str=str@entry=0x7ffff7a05ff8 "double free or corruption (out)") at malloc.c:5341
#4 0x00007ffff7901730 in _int_free (av=0x7ffff7a3bc40 <main_arena>, p=0x55555fedeb30, have_lock=<optimized out>) at malloc.c:4306
#5 0x0000555555713b23 in checked_free (ptr=0x55555fedeb40) at misc.c:1275
#6 0x0000555555705cc3 in FreeSnapshotBuffer (bi_raw=0x55555fedeb40) at snapshot.c:73
#7 0x0000555555714fda in deleteNodeFromList (node_first=0x7fffffffd918, key=0x0, destructor_function=0x555555705c6d <FreeSnapshotBuffer>) at misc.c:2084
#8 0x0000555555705cec in FreeSnapshotBuffers (snapshot_buffers=0x55555c132e10) at snapshot.c:79
#9 0x0000555555705d26 in FreeSnapshotSingle () at snapshot.c:93
#10 0x0000555555705ebb in SaveSnapshotSingle (snapshot_buffers=0x55555c1d2870) at snapshot.c:177
#11 0x00005555556b3e03 in SaveEngineSnapshotSingle () at game.c:15383
#12 0x00005555556ed81f in TapeQuickSave () at tape.c:1023
#13 0x000055555564a4ae in HandleKey (key=1073741891, key_status=1) at events.c:2241
#14 0x0000555555648c63 in HandleKeyEvent (event=0x7fffffffda10) at events.c:1462
#15 0x0000555555646b84 in HandleEvents () at events.c:249
#16 0x0000555555646d67 in EventLoop () at events.c:348
#17 0x000055555563a1ca in main (argc=2, argv=0x7fffffffdb68) at main.c:7762

filbo
Posts: 405
Joined: Fri Jun 20, 2014 10:06 am

Re: Crashes, most often when starting or finishing levels?

Post by filbo » Mon Jan 20, 2020 6:09 am

`sudo cpupower frequency-set -u 3000MHz`
That would not change the speed of the memory bus, which is where I think the problem lies. The necessary troubleshooting steps in that direction are: see whether the BIOS offers any RAM speed controls; if so, significantly detune them; if not, try omitting one memory stick from config, cycle through them all (hopefully >1!)

Seeing the same failure in a system utility reaffirms my sense that it's a hardware stability problem, not Holger's bug.

BryanFRitt
Posts: 77
Joined: Mon Nov 13, 2017 4:16 pm

Re: Crashes, most often when starting or finishing levels?

Post by BryanFRitt » Sat Jan 25, 2020 3:01 am

I can't test if it's a particular RAM stick on this laptop
"Two SODIMM slots, customer non-accessible/non-upgradeable"

I think, but I'm not sure I ran
`sudo cpupower frequency-set -u 2200MHz`
before starting the attached dbg session.

This bug maybe related to the other bug I posted.
"Level completion coloring for finished levels gets reset for a levelset after finishing a level"
viewtopic.php?f=7&t=3087
After a crash(not in the attached file*) seems to have caused the level coloring bug on another levelset.
*I wasn't running gdb when this happened.

The vast majority of these crashes are when going out or going into a level. No other program on my computer seams to be crashing. It even happens when I go back on the original 'artwork'.

I wonder if it could be a driver related issue? There's a keyboard issue with repeating characters at times(usually after a suspend?). If I try to type the same letter again I have to do it an extra time for every additional one. like to get 'tt' I have to type 'ttt', to get 'ttt' I have to type 'ttttt'. After a few times of doing this, it'll just keep repeating the same letter like I'm holding down the key even though I'm not 'tttttttttttttt'... until I type the letter again 't'. I've seen this happen while playing R'n'D, and text editor(s).
Attachments
rocksndiamondsCrashesDBG.txt
(18.32 KiB) Downloaded 39 times

BryanFRitt
Posts: 77
Joined: Mon Nov 13, 2017 4:16 pm

Re: Crashes, most often when starting or finishing levels?

Post by BryanFRitt » Sat Jan 25, 2020 4:58 am

I forgot to add ... When it crashes at the end of a level it often doesn't save the high score, and/or change the level completion highlighting.

filbo
Posts: 405
Joined: Fri Jun 20, 2014 10:06 am

Re: Crashes, most often when starting or finishing levels?

Post by filbo » Sat Jan 25, 2020 8:24 am

You said that `xbindkeys-config` also failed that way. That should never happen and still indicates a hardware issue. The fact that renaming its config file 'fixed' it only means that you changed it to perform less complicated behavior, thus avoiding the danger area.

I googled for the exact phrase you used, "Two SODIMM slots, customer non-accessible/non-upgradeable", and found that it's some sort of HP. Discussions among HP users indicate that this phrase 'customer non-accessible/non-upgradeable' is mostly a marketing term meaning 'actually, we sell a model which is identical except with more memory, and the profit margins are far higher if you buy that rather than the cheaper one and field-upgrade it yourself'. However, _some_ models actually have the memory soldered on, so you would have to open up the machine to check. There is a wealth of information on the Internet about doing that.

For instance, https://manualslib.com/manual/1527051/H ... Bc300.html is a manual for some set of HP notebooks. It says 'non-accessible/non-upgradeable', and at the same time gives detailed instructions on replacing memory modules (page 50)! The manual for your exact model should give similar guidance. (A photo of the main page of your machine's BIOS Setup would go a long way towards resolving this...)

BryanFRitt
Posts: 77
Joined: Mon Nov 13, 2017 4:16 pm

Re: Crashes, most often when starting or finishing levels?

Post by BryanFRitt » Sat Jan 25, 2020 5:02 pm

filbo wrote:
Sat Jan 25, 2020 8:24 am
You said that `xbindkeys-config` also failed that way. That should never happen and still indicates a hardware issue. The fact that renaming its config file 'fixed' it only means that you changed it to perform less complicated behavior, thus avoiding the danger area.
This one turned out to be an escaping characters issue. It even happened on my old computer. I only mentioned it since it also gave a "free(): double free detected in tcache 2" like some of the crashes I was getting from R'n'D, and this xbindkeys-config crash was clearly repeatable.
It says 'non-accessible/non-upgradeable', and at the same time gives detailed instructions on replacing memory modules (page 50)!
Yep... mine's an HP(different model than the one you linked to) and despite the fact that it says "non-accessible/non-upgradeable" RAM it "gives detailed instructions on replacing memory modules". I'll give it a try and see what happens.
UPDATE: Mine's not user upgradable even if the instructions show a way to replace the RAM. I'm guessing this part of the instructions is just generic.

BryanFRitt
Posts: 77
Joined: Mon Nov 13, 2017 4:16 pm

Re: Crashes, most often when starting or finishing levels?

Post by BryanFRitt » Tue Jun 30, 2020 12:02 am

Attached is a zip of more crashes that have happened. For the I used gdb on rocksndiamonds-4.1.4.1. When rocksndiamonds crashed I would do `bt` and then do like a comment with a description of the problem.
Attachments
RND_GDB_LOGS.tar.gz
(51.57 KiB) Downloaded 19 times

BryanFRitt
Posts: 77
Joined: Mon Nov 13, 2017 4:16 pm

Re: Crashes, most often when starting or finishing levels?

Post by BryanFRitt » Tue Jun 30, 2020 12:10 am

Several times during playing there were these crashes where it lost old save data, old high scores, and/or list of completed levels. Instead of writing directly to files it should finish a temp file and then rename that. This would minimize the likelihood of data loss if something were to happen during writing. (If RnD already does so, I never found out about it during my playing)
viewtopic.php?f=7&t=3113

User avatar
Holger
Site Admin
Posts: 3330
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Crashes, most often when starting or finishing levels?

Post by Holger » Tue Jun 30, 2020 10:59 pm

Attached is a zip of more crashes that have happened.
Just had a quick look at them (not all, as they are too many) -- as far as I can see, it mostly happens in "malloc()" or "free()".

For now (and as I had no reports of such crashes by other people so far, and R'n'D apparently runs fine on your second computer), I assume that these crashes are really the symptoms of memory problems.
Several times during playing there were these crashes where it lost old save data, old high scores, and/or list of completed levels. Instead of writing directly to files it should finish a temp file and then rename that. This would minimize the likelihood of data loss if something were to happen during writing. (If RnD already does so, I never found out about it during my playing)
No, R'n'D doesn't write temporary files, then renaming them, when writing to files. And yes, you're right that this could reduce the possibility for data loss in such situations.

But then, trying to minimize data loss that may be caused by bad memory seems to be the wrong way to me, as this may cause data loss even when trying to work around it. Fixing the root cause (bad memory or hardware) seems to be the better approach than trying to cure the symptoms... :?

Post Reply