higan icon indicating copy to clipboard operation
higan copied to clipboard

"longjmp causes uninitialized stack frame" on loading ROMs

Open kha84 opened this issue 2 years ago • 5 comments

Higan starts as normal, but whenever I open any rom file I get "*** longjmp causes uninitialized stack frame ***" For some reason it was working fine under "Orange PI OS 3.0.0" which is bullseye fork, but under Armbian it doesn't. Do you have any ideas? I gave it a try with all possible video driver settings - it's always the same

$ apt policy higan
higan:
  Installed: 106-2build2
  Candidate: 106-2build2
  Version table:
 *** 106-2build2 500
        500 http://ports.ubuntu.com jammy/universe arm64 Packages
        100 /var/lib/dpkg/status

$ higan
*** longjmp causes uninitialized stack frame ***: terminated
Aborted (core dumped)

$ neofetch 
                                 bugman@orangepi4-lts 
                                 -------------------- 
      █ █ █ █ █ █ █ █ █ █ █      OS: Armbian (22.05.4) aarch64 
     ███████████████████████     Host: OrangePi 4 LTS 
   ▄▄██                   ██▄▄   Kernel: 5.15.52-rockchip64 
   ▄▄██    ███████████    ██▄▄   Uptime: 4 hours, 38 mins 
   ▄▄██   ██         ██   ██▄▄   Packages: 1637 (dpkg) 
   ▄▄██   ██         ██   ██▄▄   Shell: bash 5.1.16 
   ▄▄██   ██         ██   ██▄▄   Resolution: 1920x1080 
   ▄▄██   █████████████   ██▄▄   DE: Xfce 4.16 
   ▄▄██   ██         ██   ██▄▄   WM: Xfwm4 
   ▄▄██   ██         ██   ██▄▄   WM Theme: NumixBlue 
   ▄▄██   ██         ██   ██▄▄   Theme: Numix [GTK2], Adwaita [GTK3] 
   ▄▄██                   ██▄▄   Icons: Numix [GTK2], Adwaita [GTK3] 
     ███████████████████████     Terminal: x-terminal-emul 
      █ █ █ █ █ █ █ █ █ █ █      CPU: (6) @ 1.416GHz 
                                 Memory: 1508MiB / 3863MiB 
                                                        

kha84 avatar Aug 07 '22 21:08 kha84

All of the emulation cores within higan use a library called libco to synchronise the emulation of the various parts of each system. libco has native support for AArch64 platforms, but if for some reason AArch64 support wasn't detected when the package was built, it would fall back to using the slow-but-fairly-portable longjmp() function.

The way libco uses longjmp() I think is not technically allowed, but it's been used this way by many applications for decades. It's quite possible that Armbian is (for whatever reason) stricter about these things than "Orange PI OS".

The most correct solution would be to ask the Armbian people to rebuild their higan package with proper AArch64 support.

The most practical solution would be to download the higan source-code and build it yourself, or switch to a different emulator.

Screwtapello avatar Aug 08 '22 06:08 Screwtapello

Thanks a lot, that makes sense. Will try to rebuild it + give a ping to armbian team. Any specific compiler flags I should consider?

kha84 avatar Aug 08 '22 09:08 kha84

libco uses the AArch64 implementation if the preprocessor symbol __aarch64__ is defined:

https://github.com/higan-emu/libco/blob/master/libco.c#L16-L17

...which I assume it should be on every AArch64 compiler. I don't know if there's compiler flags that would influence it one way or the other.

Screwtapello avatar Aug 08 '22 09:08 Screwtapello

It would be weird if libco was managing to be built without AArch64 support enabled; I have to imagine it would've been done intentionally, perhaps to fix a broken build. The sjlj version may build, but perhaps it doesn't work, bringing us here.

There is one other obvious place where longjmp could be coming into play: the deflate implementation. If all of your ROMs are zipped, try unzipping one and loading it. Though, I think the deflate implementation uses longjmp correctly, so this seems unlikely.

If it is neither of those two things, it is likely in another library, like GTK. If that's the case, a stack trace would be needed to figure out what's going on.

jchv avatar Aug 08 '22 19:08 jchv

Nah, my roms were all unzipped

kha84 avatar Aug 09 '22 06:08 kha84