Let's play Commander Keen

[Gerhard_Stein]

Can you let it run with gdb? I’m very courious why you get these segfaults and corruptions.

[Oet]

Here are a few:

Thread 1 "CGeniusExe" received signal SIGABRT, Aborted.
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47	../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.

[New Thread 0xac6ff310 (LWP 29794)]
Thread 2 "threadItem1" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb54f2310 (LWP 29780)]
0xafdfdcb0 in llvm::StringMapImpl::RemoveKey(llvm::StringMapEntryBase*) () from /usr/lib/arm-linux-gnueabihf/libLLVM-3.9.so.1

[New Thread 0xac6ff310 (LWP 29810)]
*** Error in `/home/cpi/Commander-Genius/build/src/CGeniusExe': double free or corruption (out): 0xac96ee78 ***
[Thread 0xac6ff310 (LWP 29810) exited]
Thread 2 "threadItem1" received signal SIGABRT, Aborted.
[Switching to Thread 0xb54f2310 (LWP 29796)]
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47	../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.

[New Thread 0xac6ff310 (LWP 29876)]
[Thread 0xac6ff310 (LWP 29876) exited]
[New Thread 0xac6ff310 (LWP 29877)]
Thread 1 "CGeniusExe" received signal SIGSEGV, Segmentation fault.
0xafec7bde in llvm::Value::getName() const () from /usr/lib/arm-linux-gnueabihf/libLLVM-3.9.so.1

[New Thread 0xac6ff310 (LWP 29927)]
Thread 1 "CGeniusExe" received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x6c9) at malloc.c:2966
2966	malloc.c: No such file or directory.

[New Thread 0xac6ff310 (LWP 29994)]
*** Error in `/home/cpi/Commander-Genius/build/src/CGeniusExe': double free or corruption (out): 0xac96ee78 ***
Thread 1 "CGeniusExe" received signal SIGSEGV, Segmentation fault.
0xac9712be in ?? ()

[Thread 0xac6ff310 (LWP 2268) exited]
n: Finished downloading from "http://downloads.sourceforge.net/project/clonekeenplus/Downloads/gameCatalogue.xml", destination: "tempgameCatalogue.xml"
n: Loading catalogue file in the background [finished]
Thread 2 "threadItem1" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb54f2310 (LWP 2248)]
0xb1e24b3e in ?? () from /usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so

At least the numbner 0xac6ff310 keeps coming back as the only constant?

[Oet]

This GameShell has 500 MB of RAM. It gives me 388 MB free to test with memtester. All 388 MB OK.

[Gerhard_Stein]

Let me try to build a similar system and see if I can reproduce that.

[Gerhard_Stein]

I will try this on a Raspian System. Got some HW here now…

[Oet]

It’s time to order a GameShell.

I can also do two more things:

1. Try to reproduce it on an arm64 device I have (instead of GameShell’s armhf)
2. Try to see if I if an “old” 2.2.5 build still works on my more up-to-date armhf (concerning debian packages) .

Let me know if you want me to do either of those two.

By the way… The GameShell (armhf) uses Debian Stretch and my other device (arm64) Ubuntu Xenial.

[Oet]

I reproduced it on my Pine64 with 512 MB.
Had to build with cmake 3.5 and without python.

It did not boot without gameCatalogue.xml, so I manually put the file there.

After that, it sometimes boots, but usually different errors!

Starting to think the software claims more memory than the OS of the ARM provides…

[Gerhard_Stein]

No problems here with Raspbian and Raspberry Pi 3. It takes about 120 MB. Was it better with with version 2.2.5? What about threads? In order to download the catalogue a second thread is opened in the background.

Previously the download happened before anything else started, which took much longer.

I find it strange, that it runs so badly on your systems right now…

What Cmake Parameters did you set/use? Is it Debug or Release?

[Gerhard_Stein]

I pushed another update (master branch) by optimizing the thread management a bit. Let’s hope it helps on your situation. I might try it a Banana Pi M64, but this one has 2 GB of RAM. I will take a closer look on memory consumption.

[Oet]

@Gerhard_Stein

Was it better with with version 2.2.5?

I had no boot failures with my released v2.2.5-gameshell version. It just took long offline.

@Gerhard_Stein

What about threads?

Were there threads in v2.2.5? To me it looks like v2.2.7 fixed the boot time, but often causes boot errors on my ARM-devices.

@Gerhard_Stein

What Cmake Parameters did you set/use?

cmake -DUSE_PYTHON3=0 ..
make

@Gerhard_Stein

Is it Debug or Release?

It crashes often whether or not I use -DCMAKE_BUILD_TYPE=Debug, assuming the default is Release?

@Gerhard_Stein

I pushed another update (master branch) by optimizing the thread management a bit.

I will try again on my devices with the new master. If it keeps giving problems I can try again on a 2 GB ARM device (instead of 512 MB).

How much internal memory does your Raspberry Pi 3 have?

[Oet]

Report for builds:
Commit 999e1ce0 runs fine.
Commit cb754285 and newer have the “boots sometimes” issues (like on the GameShell).

Tested on:

• Pine64 512MB
• Pine64+ 2GB

I don’t understand how you got it working 100% on the Raspberry. Why don’t my ARM devices like this background downloader code.

[Oet]

I think this snippet in CGameLauncher.cpp is the cause:

auto *pRetryButton = new GsButton("Retry", new GMSwitchToGameLauncher());
mpMsgDialog->addControl(pRetryButton, GsRect<float>(0.2f, 0.85f, 0.2f, 0.05f));

By commenting this out, it seems to boot every time.

[Gerhard_Stein]

Wow, really? Hard to imagine it is just another button that makes the whole app crash. That really make me puzzling now.

Let me take a closer look. Hmm, I think the cause is somewhere else. Maybe something thread related. The problem about missing the “retry” button is that the user won’t have a chance to recheck if the catalog was downloaded in the mean time. It is a first time problem anyways. Maybe not so much to worry about…

I found some other code flaws which now are removed. I also optimized the build time a bit.

When I start CG 33,4 MB are occupied. Starting Keen4 Coop Edition, where you have 4 different characters to choose I get up to max 120 MB. This is my Manjaro 64-bit Machine.

[Oet]

@Gerhard_Stein

Hard to imagine it is just another button that makes the whole app crash.

I can go back to building the master on my GameShell again. Next build I will test whether the pRetryButton or new GMSwitchToGameLauncher() still causes the GameShell to crash (if this code remains in the master).

[Gerhard_Stein]

ok. can’t wait to see what you will find out. If these two lines really are the problem I will have to dig deeper into the code checking what this behaviour it is causing…

Co-relations of segfaults can be hard sometimes.

Hope you had some nice resting days during these holidays

[Oet]

@Gerhard_Stein

I will have to dig deeper into the code checking what this behaviour it is causing…

I have done so. I think new GMSwitchToGameLauncher() in this line causes the first game launcher, and it ends up here:

gInput.mpVirtPad.reset(new VirtualKeenControl);

    if( gInput.mpVirtPad->init() )
    {
        const std::string err = "Error loading the Virtual Gamepad!";

        gLogging.textOut(err);
    }

As soon as it wants to do something with gInput.mpVirtPad it seems to crash, even though I have VirtPad = false. I took the master, uncommented this code. It seems to solve the problem.

[Gerhard_Stein]

In your quote an exclamation mark is missing:

gInput.mpVirtPad.reset(new VirtualKeenControl);

if( !gInput.mpVirtPad->init() )
{
    const std::string err = "Error loading the Virtual Gamepad!";

    gLogging.textOut(err);
}

I have it disabled as well. The object is constructed, so it can be turn on while CG is running. It always created but is kept unused while turned off. No crashes.

I had that missing exclamation mark missing in the past, but fixed some time. Are you sure you are using the Master branch? I refer to the one of Gitlab (not Github).

I can add a macro which compiles CG without the Virtual Gamepad. That way no one would try to enable it. On a Gameshell it doesn’t make sense, because you have real controls.

Dringgstein/Commander-Genius/blob/master/src/engine/CGameLauncher.cpp

[Oet]

@Gerhard_Stein

In your quote an exclamation mark is missing:

I did not copy-paste the code, so I just mistyped. Sorry for the confusion. I indeed have the gitlab master with an exclamation mark.

This line will crash:
gInput.mpVirtPad.reset(new VirtualKeenControl);

I have not dug into why this line crashes. I can try to see where it happens during the reset.
And if that line is totally disabled, this line will crash:
if( !gInput.mpVirtPad->init() )

Might as well take a look now I am this far, if a macro means a workaround instead of a solution.

[Gerhard_Stein]

Okay, I added another switch to CMAKELISTS:

with cmake -DUSE_VIRTUAL=0 it will remove all the related virtual gamepad code and the user won’t be able to toggle it on.

[Oet]

Okay, I used:
cmake -DUSE_PYTHON3=0 -DUSE_VIRTUAL=0 ..

The current master:

• Always boot fast.
• You can disable internet in CG (to force an error when you try to download).
• You can enable internet again in the same session (to download again like nothing happened).

This means I can now make an improved version for the GameShell!

Some minor points for improvement:

• The progress bar when downloading a game goes to 90% and after that from 0% to 100%.
• Pulling out internet during the first 90% makes CG hang (yeah, I am making it really “idiotensicher”).
• KeenDreams seems to do PC Speaker sound as a default (instead of SB/Adlib).
• Quitting KeenDreams on the GameShell does not show CG menu. It seems to try to show some other screen which is not 320x240.
• Document the -DUSE_PYTHON3=0 flag (for users having cmake lower than v3.12).
• Document the -DUSE_VIRTUAL=0 (for users having an ARM with segmentation faults).
• Update documentation Run "cmake ../CGeniusSrc" to Run "cmake .." (relative paths in build steps need update).

Question:
What part of CG uses libogg-dev and libvorbis-dev?

Tell me when you want me to update to a new version for the GameShell and which branch (master/tag) I should use!