DevilutionX 1.4.0 does not start on OD Beta (RG280V)
Important information OpenDingux Beta (RG280V) / DevilutionX 1.4.0 / Downloaded release
Newest release of DevilutionX doesn't start.
To Reproduce Steps to reproduce the behavior:
- Set up device & .mpq files as per install guide
- Start OPK
Expected behavior Game starts to splash screen or title screen, but screen goes black and returns to OD browser
Additional context Version 1.3.0 starts fine on same device & OS.
Anything in the log?
The log appears completely blank. I've deleted the log and tried opening the Log Viewer a few times and it always appears empty for DevilutionX 1.4.0. The log for 1.3.0 shows up fine, indicating several "INFO" lines, mainly about video mode settings.
I don't have a device to debug with at the moment.
Does the build from here work for you?
https://github.com/diasurgical/devilutionX/actions/runs/2646338005
No, this build doesn't work either - same result. Blank log file as well.
What version of OD beta are you using?
2022-04-03 (version 5.17) that is packaged with the Adam Image 2.0 update.
I'm not sure about the Adam Image. I've asked on the OpenDingux Discord if somebody can test with the actual OD firmware on RG280v.
In the meantime, can you try this build https://github.com/glebm/devilutionX/actions/runs/2651114384
Also, can you try launching directly from the terminal instead of the UI (e.g. using opkrun)? Sometimes you get better error messages this way (e.g. if the error happens before the log stuff got initialized).
Attempting to run the OPK you linked shows basically nothing happening in the terminal.
For reference, running the OPK for 1.3.0 (I renamed the file to differentiate) via the terminal works fine.
Looks like it tries to render the log and intro video and then the menu at which point it exits.
The lines that show earlier in the terminal before running "devilutionx-rg350.opk" (the link recently provided by glebm) are from me testing the 1.3.0 version ("devilutionx-rg350-130.opk") before I took the two photos - sorry for any confusion.
When using opkrun on this 1.4.0 build, literally nothing happens in the terminal or on the device when hitting enter (what I tried to show with the first photo). The second photo is me running 1.3.0 a second time to show that it works.
OpenDingux folks confirmed that it segfaults on startup with vanilla OD Beta firmware. We're using a March 2021 toolchain to build DevilutionX, let me see if updating to the latest toolchain helps.
@Creamynips Thanks for testing. Can you please try https://github.com/glebm/devilutionX/suites/7309298017/artifacts/295315822? It's built with the October 2021 OD toolchain instead of the March 2021 one.
Nothing, unfortunately. Same results with opkrun from before.
Can confirm, nothing except 1.3.0 works, I've got the very same results as @Creamynips
I've no idea what the cause is and don't have a device to test with, hopefully someone else can debug this at some point.
I think @citral23 looked at it but not sure whether he's discovered something.
I've no idea what the cause is and don't have a device to test with, hopefully someone else can debug this at some point.
I think @citral23 looked at it but not sure whether he's discovered something.
Isn't there some way to get direct console output? Like, not the (empty) result of opkrun but some segfault messages? I'd like to help with it
I would suggest doing a debug build. Maybe look in to attatching a debug console
Here is how someone with a device can debug this.
- Recompile OpenDingux with
BR2_ENABLE_DEBUG. - Compile DevilutionX in
RelWithDebInfomode:- Change
build_releasetobuild_relwithdebinfoin Packaging/OpenDingux/build.sh:131 - Build DevilutionX:
TOOLCHAIN=/opt/gcw0-toolchain Packaging/OpenDingux/build.sh rg350
- Change
- Use a remote debugger (see below).
Once you've installed the BR2_ENABLE_DEBUG version of OpenDingux, copy the opk to the device.
Then, enable terminal mode, and run this via ssh:
# Unpack the OPK
unsquashfs devilutionx-rg350.opk
cd squashfs-root
# Start devilutionx with a gdbserver
gdbserver 10.1.1.1:8001 devilutionx
In VS Code, add a launch configuration (in .vscode/launch.json) for remote debugging:
{
"name": "rg350 remote debug",
"type": "cppdbg",
"request": "launch",
"program": "build-rg350/devilutionx",
"stopAtEntry": true,
"miDebuggerPath": "/opt/gcw0-toolchain/bin/mipsel-linux-gdb",
"miDebuggerArgs": "-ix /opt/gcw0-toolchain/mipsel-gcw0-linux-uclibc/sysroot/usr/share/buildroot/gdbinit",
"MIMode": "gdb",
"miDebuggerServerAddress": "10.1.1.3:8001",
"targetArchitecture": "mips",
"additionalSOLibSearchPath": "/opt/gcw0-toolchain/mipsel-gcw0-linux-uclibc/sysroot",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"externalConsole": false,
"cwd": "${workspaceFolder}"
},
Now you can use VS code to debug remotely!
Thanks to the amazing @pcercuei we've discovered that disabling LTO makes it work! :tada:
It'd be good to enable it again in the future but at least it's playable again.
Glad you guys figured it out :) I'll include it in the 1.4.1 release which hopefully will be out this weekend.
In the meantime, feel free to try out this build from the latest master https://github.com/diasurgical/devilutionX/suites/7485166754/artifacts/307094526
Just tried the latest devilutionx-rg350.opk (1.4.1) on my RG350M with OD-beta, but it won't start (Segmentation fault).
So I compiled it myself (following the github actions steps as close as possible), and that version did work. I did use an slightly older toolchain (Oct. 2020) with compiler version 10.2 instead of 11.1 as used in github actions. But I doubt this has any impact.
There are also some differences in the resulting shared object dependencies (just for the record):
ldd on my compiled version:
libz.so.1 => /lib//libz.so.1 (0x77e3f000)
libSDL-1.2.so.0 => /lib//libSDL-1.2.so.0 (0x77dea000)
libc.so.0 => /lib//libc.so.0 (0x77d37000)
ld-uClibc.so.1 => /lib/ld-uClibc.so.0 (0x77e65000)
libiconv.so.2 => /lib//libiconv.so.2 (0x77c45000)
libdrm.so.2 => /lib//libdrm.so.2 (0x77c24000)
libudev.so.1 => /lib//libudev.so.1 (0x77bef000)
libts.so.0 => /lib//libts.so.0 (0x77bdb000)
ldd on github version:
libSDL_image-1.2.so.0 => /lib//libSDL_image-1.2.so.0 (0x77eb1000)
libz.so.1 => /lib//libz.so.1 (0x77e8b000)
libSDL-1.2.so.0 => /lib//libSDL-1.2.so.0 (0x77e36000)
libc.so.0 => /lib//libc.so.0 (0x77d83000)
ld-uClibc.so.1 => /lib/ld-uClibc.so.0 (0x77ecb000)
libpng16.so.16 => /lib//libpng16.so.16 (0x77d42000)
libjpeg.so.9 => /lib//libjpeg.so.9 (0x77cfd000)
libiconv.so.2 => /lib//libiconv.so.2 (0x77c0b000)
libdrm.so.2 => /lib//libdrm.so.2 (0x77bea000)
libudev.so.1 => /lib//libudev.so.1 (0x77bb5000)
libts.so.0 => /lib//libts.so.0 (0x77ba1000)
Maybe it is just me, as I do not see any other new error reports here.
I also didn't have any luck with the new version, but I thought it was just me as others sounded pretty confident the issue was fixed.
@Creamynips meanwhile you could try my build from a few days ago and see it if works for you https://github.com/a-dekker/repackaged-opks/raw/main/devilutionx-rg350.opk
That build works! Thanks a-dekker.
Just tested, https://github.com/diasurgical/devilutionX/pull/5116/commits/4bff36cae760d7793f0aa3ad56850f87c1804b1f is indeed needed to prevent a segmentation fault. So the issue seems to be in the build process itself over here.
Looks like perhaps we didn't reupload the correct release after pushing through the fix. Does the build from here work? https://github.com/diasurgical/devilutionX/actions/runs/2915256726
No, this build also does not work unfortunately.
Odd, is the CI perhaps using a different version of the toolchain? https://github.com/diasurgical/devilutionX/actions/runs/2915256726/workflow#L21
It is, that is what I already mentioned in my first comment here.