Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"longjmp causes uninitialized stack frame" on loading ROMs #190

Open
kha84 opened this issue Aug 7, 2022 · 5 comments
Open

"longjmp causes uninitialized stack frame" on loading ROMs #190

kha84 opened this issue Aug 7, 2022 · 5 comments

Comments

@kha84
Copy link

kha84 commented Aug 7, 2022

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 
                                                        
@Screwtapello
Copy link
Contributor

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.

@kha84
Copy link
Author

kha84 commented Aug 8, 2022

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

@Screwtapello
Copy link
Contributor

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.

@jchv
Copy link
Contributor

jchv commented Aug 8, 2022

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.

@kha84
Copy link
Author

kha84 commented Aug 9, 2022

Nah, my roms were all unzipped

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants