Fatal "Signal 11" error when trying to load a ROM with the latest code

[DrUm78]

I get a fatal "Signal 11" error when trying to load any GB/GBC ROM (zipped or unzipped) with your latest code on Linux and on armv7. Maybe I do it wrong? Does it work for you?

Thanks!

[rofl0r]

i finally managed to create a test environment using a sabotage linux arm rootfs, and i built gnuboy like this:

CFLAGS="-O0 -g3" CC="/home/user/musl-cross-make-6.3.0/arm-linux-musleabi/bin/arm-linux-musleabi-gcc -L /home/user/x-prefix/arm/lib -isystem /home/user/x-prefix/arm/include" LDFLAGS="-Wl,-rpath-link=/home/user/x-prefix/arm/lib" ./configure --with-x --with-sound=no --without-sdl --without-sdl2 --host=arm-linux-musleabi

and then ran it via

qemu-arm -L ~/x-prefix/arm -E LD_LIBRARY_PATH=~/x-prefix/arm/lib -strace ./xgnuboy ~/games/gb/Wario.gbc

and the game runs fine. so either the problem is specific to glibc, to some CFLAGS you used, or requires a specific sound backend. it would be helpful if you could try the following:

CFLAGS="-fsigned-char -O0 -g3" ./configure ... and then run the resulting binary in gdb and when it crashes, provide the backtrace (using bt command).

[DrUm78]

@rofl0r Here is the gdb stack when launching the unstripped binary compiled with '-ggdb -O3 -fsigned-char':

Program received signal SIGSEGV, Segmentation fault.
inflate (data=0xb6b7873c "@P\267\266\270", p=0x0, callback=0x0)
    at inflate.c:397
397	inflate.c: No such file or directory.
#0  inflate (data=0xb6b7873c "@P\267\266\270", p=0x0, callback=0x0)
    at inflate.c:397
#1  0xb6de0b94 in ?? () from /usr/lib/libpng16.so.16
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
A debugging session is active.

	Inferior 1 [process 4607] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

I reproduced it on armv7 32-bit handheld device on which I use musl FYI.

[rofl0r]

it's odd that you have libpng in the trace, because we don't use it. can you figure out where it is pulled in from ?

anyway i suspect this patch can fix it: http://ix.io/4bdU - assuming some libpng startup code is running that's running our inflate function with wrong prototype, which assumes it uses libz's function of the same name instead.

[DrUm78]

Yeah the libpng thing is maybe because I compile it for FunKey S handheld device with armv7 (my code is an old one with some backports from your code though): https://github.com/DrUm78/gnuboy/commits/test

But even when compiling from your repo with your patch, that still fails.

[rofl0r]

ehm, your copying my commits there but i don't see myself mentioned as author. you can preserve authorship with git format-patch / git am or git commit --author="rofl0r <[email protected]>"

also it's kinda odd you're opening an issue here for a segfault that happens with another repo.

[DrUm78]

Yeah sorry, I just realized that after my last commit, will give you the credit you deserve or delete my commits, my bad. But please note that I ALWAYS give credit on my release page (not out yet) but indeed I understand your point.

The segfault also happens with your code on Linux 20.04 (WSL2), that was my point, so not only with my old code. I use the following command:

make -f Makefile.nix

Even when launching the configure before, that does not change anything here.

[rofl0r]

But please note that I ALWAYS give credit on my release page

that's precisely what the "author" field of git commits is for. but don't worry, you can turn your entire branch into patches using "git format-patch last-commit-hash-before-your-changes", then you can edit the author field in the patches with a quick sed run, then "git am" using the patches to import them to a new branch (in the same order).

make -f Makefile.nix

bad idea. that makefile is basically unmaintained and lacks some things. i should delete it.

Even when launching the configure before

you need to run configure, then use make (no Makefile.nix)

The segfault also happens with your code on Linux 20.04 (WSL2)

pls provide backtrace

[DrUm78]

Ok the segfault does not happen with ./configure&&make on Linux then I was using a deprecated method I guess.

On armv7, I am using Makefile.in, is it a bad idea too?

For the credit, I rebased my branch and added "Author: rofl0r" to each of my commit message, tell me if that's fine for you, otherwise I will change it again: https://github.com/DrUm78/gnuboy/commits/FunKey