maemo-leste / bugtracker

Issue tracking repository
62 stars 3 forks source link

ScummVM segfaults on launch #353

Closed buzztiaan closed 3 years ago

buzztiaan commented 4 years ago

Ever since the new beowulf maemo-extra package for scummvm, its been segfaulting on launch ;

user@devuan-droid4:~$ dpkg -l | grep scummvm | head -n1
ii  scummvm                                        2.2.0~git+2m7            
user@devuan-droid4:~$ scummvm
awk: cannot open /proc/component_version (No such file or directory)
WARNING: You are missing a valid 'translations.dat' file. GUI translation will not be available!
Virtual keyboard pack 'vkeybd_default' loaded successfully
Segmentation fault
user@devuan-droid4:~$ 
MerlijnWajer commented 4 years ago

Seems to crash here:

(gdb) bt
#0  Common::String::compareTo(char const*) const () at ./common/str.h:208
#1  0x00005555567808f8 in Common::String::equals(Common::String const&) const () at common/str.cpp:747
warning: (Internal error: pc 0x5555566b9e95 in read in CU, but not in symtab.)
warning: (Internal error: pc 0x5555566b9e95 in read in CU, but not in symtab.)
#2  0x00005555566b9e96 in Common::HardwareInputSet::removeHardwareInput(Common::HardwareInput const*) ()
    at backends/keymapper/hardware-input.cpp:276
warning: (Internal error: pc 0x5555566b9f92 in read in CU, but not in symtab.)
warning: (Internal error: pc 0x5555566b9f92 in read in CU, but not in symtab.)
#3  0x00005555566b9f93 in Common::HardwareInputSet::addHardwareInput(Common::HardwareInput const*) ()
    at backends/keymapper/hardware-input.cpp:197
warning: (Internal error: pc 0x5555566ba23e in read in CU, but not in symtab.)
warning: (Internal error: pc 0x5555566ba23e in read in CU, but not in symtab.)
#4  0x00005555566ba23f in Common::HardwareInputSet::addHardwareInputs(Common::KeyTableEntry const*, Common::ModifierTableEntry const*) () at ./backends/keymapper/hardware-input.h:75
warning: (Internal error: pc 0x5555558cd9f3 in read in CU, but not in symtab.)
warning: (Internal error: pc 0x5555558cd9f3 in read in CU, but not in symtab.)
#5  0x00005555558cd9f4 in Maemo::OSystem_SDL_Maemo::getHardwareInputSet() ()
    at backends/platform/maemo/maemo.cpp:196
warning: (Internal error: pc 0x5555558cf740 in read in CU, but not in symtab.)
warning: (Internal error: pc 0x5555558cf740 in read in CU, but not in symtab.)
#6  0x00005555558cf741 in scummvm_main () at base/main.cpp:355
#7  0x00005555558cba58 in main () at backends/platform/maemo/main.cpp:40
warning: (Internal error: pc 0x5555566b9e95 in read in CU, but not in symtab.)

Will investigate over the weekend.

android-808 commented 4 years ago

I can confirm this on fresh virtual box image using latest Leste image.

I'm trying to get a repo set up using based on ScummVM 2.1 as that's the version I tested previously and I believe still the current stable release. I'm rebasing the packaging on the Debian Salsa repo in a debian-leste folder within the maemo backend rather than editing the existing pre-Leste Debian folder. That way it could be merged upstream without breaking Maemo 5 support. If it works out I'll post link here to the repo.

android-808 commented 4 years ago

Some progress, it starts. Basic answer, fetch upstream. 2.1.0 or whatever git revision was sitting in my existing repo experiences same problem. 2.1.1/2.1.2 (for Windows) is latest stable, I haven't tried that. I would give one of these a shot first to see if it fixes the issue. Theres a few GUI fixes in it that might help.

I pulled latest master from upstream, merged and built with a WIP debian folder. devtools/create_prince is now a subproject and I don't know how to deal with that if at all. Upstream merge creates 2 conflicts in configure. One you just have to remove the moto???? platform/backends, the other is 2 android entries at the beginning of a switch.

I can't get mouse to work in VirtualBox so maybe someone will have more luck on a real device.

A wip update to the debian directory for the reasons given above is in debian-leste folder here: https://github.com/android-808/scummvm/tree/master/backends/platform/maemo I'm aware I missed a \ in configure params in the rules file to disable the gob engine. I've only partially removed or commented some parts like references to scummvm-data in case it would be preferred to keep it to mirror Devuan/Debian approach.

clort81 commented 4 years ago

Thanks android-808. I didn't see your reply here. For my experiments, I just apt-get source scumvm (the beowulf sources) and configured with:

./configure --host=arm-linux-gnueabihf --datadir=/usr/share/scummvm 
--disable-eventrecorder  --prefix=/usr --disable-all-engines 
--enable-engine-dynamic=sword1 --disable-hq-scalers 
--disable-translation --disable-cloud --opengl-mode=none

and got a running build.

scummvmD4 (The --opengl-mode=gles gave me segfault on startup) scummvm.ini is here http://0x0.st/iwRm.ini

Ingame isn't responding to keyboard input (common sdl2 prob we have) and i cannot 'double click' any objects. This is probably because a second tap with finger is too far away from x,y of first click.

[EDIT] removed erroneous comment.

I didn't have to edit anything to remove any other platforms/backends - the configure options let you specify particular engines.

Copying the binary to the target bin makes it launcheable from the hildon menu cp scummvm /opt/scummvm/bin/scummvm

Of course we will want gles scaling to fullscreen, to make the game most visible, and a nice hildon/maemo frontend. Sorry I haven't found out more yet.

[EDIT] building with debug info gives:

Program received signal SIGILL, Illegal instruction.
0xb5c89966 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1
(gdb) bt
#0  0xb5c89966 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1
#1  0xb5c840ee in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Ok witnout sdlnet and curl, there's other badness...

Reading symbols from ./scummvm...done.
(gdb) run
Starting program: /big/src/scummvm/scummvm 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
==29621==AddressSanitizer: failed to intercept '__isoc99_printf'
==29621==AddressSanitizer: failed to intercept '__isoc99_sprintf'
==29621==AddressSanitizer: failed to intercept '__isoc99_snprintf'
==29621==AddressSanitizer: failed to intercept '__isoc99_fprintf'
==29621==AddressSanitizer: failed to intercept '__isoc99_vprintf'
==29621==AddressSanitizer: failed to intercept '__isoc99_vsprintf'
==29621==AddressSanitizer: failed to intercept '__isoc99_vsnprintf'
==29621==AddressSanitizer: failed to intercept '__isoc99_vfprintf'
==29621==AddressSanitizer: libc interceptors initialized
|| `[0x38000000, 0xbfffffff]` || HighMem    ||
|| `[0x27000000, 0x37ffffff]` || HighShadow ||
|| `[0x24000000, 0x26ffffff]` || ShadowGap  ||
|| `[0x20000000, 0x23ffffff]` || LowShadow  ||
|| `[0x00000000, 0x1fffffff]` || LowMem     ||
MemToShadow(shadow): 0x24000000 0x247fffff 0x24e00000 0x26ffffff
redzone=16
max_redzone=2048
quarantine_size_mb=256M
thread_local_quarantine_size_kb=256K
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 0x20000000
==29621==Installed the sigaction for signal 11
==29621==Installed the sigaction for signal 7
==29621==Installed the sigaction for signal 8
==29621==T0: stack [0xbe800000,0xbf000000) size 0x800000; local=0xbefff184
==29621==AddressSanitizer Init done
[New Thread 0xad4ff250 (LWP 29624)]
==29621==T1: stack [0xacd00000,0xad4ff710) size 0x7ff710; local=0xad4fec0c
[New Thread 0xacaff250 (LWP 29625)]
==29621==T2: stack [0xac300000,0xacaff710) size 0x7ff710; local=0xacafec0c
[New Thread 0xac2fe250 (LWP 29626)]
==29621==T3: stack [0xabaff000,0xac2fe710) size 0x7ff710; local=0xac2fdc0c
PVR:(Warning): LoadWSModule: Window system module libpvrws_KMS.so did not validate native display [98, /generic_ws.c]
PVR:(Warning): LoadWSModule: Window system module libpvrws_WAYLAND.so did not validate native display [98, /generic_ws.c]
PVR:(Warning): PVRSRVOpenDCDevice: Warning - 138 returned [80, /bridged_pvr_dc_glue.c]
PVR:(Warning): PVRDRMSetFD: DRM fd already set [57, /pvr_bridge_u.c]
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  4 (X_DestroyWindow)
  Resource id in failed request:  0x1200007
  Serial number of failed request:  164
  Current serial number in output stream:  180
==29628==Could not attach to thread 29621 (errno 1).
==29628==Could not attach to thread 29624 (errno 1).
==29628==Could not attach to thread 29625 (errno 1).
==29628==Could not attach to thread 29626 (errno 1).
==29628==Failed suspending threads.
==29621==LeakSanitizer has encountered a fatal error.
==29621==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==29621==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
[Thread 0xac2fe250 (LWP 29626) exited]
[Thread 0xad4ff250 (LWP 29624) exited]
[Thread 0xb57b0dc0 (LWP 29621) exited]
[Inferior 1 (process 29621) exited with code 01]

Git Master: Configured with:

./configure --disable-libcurl --disable-sdlnet  --disable-eventrecorder
 --disable-all-engines --default-dynamic --enable-engine=sword1 
--disable-hq-scalers --disable-translation --disable-cloud 
--opengl-mode=gles --enable-verbose-build --enable-asan 
--enable-profiling
MerlijnWajer commented 3 years ago

I think the latest build should work (still building in CI), I tested it with the Neverhood. Does someone want to work with upstream to get proper Leste support upstreamed in their configure?

https://github.com/maemo-leste-extras/scummvm/commits/master

There's also a fix to the maemo backend, it wasn't building anymore: https://github.com/maemo-leste-extras/scummvm/commit/a90d3081cadb9ea9775cd52acde4b9678d8b36cc

(EDIT: Build failed, wait a bit.)

clort81 commented 3 years ago

Currently scummvm is unsable for me due to unreadable GUI font size. I've learned enough of the 'xml' theme format to reposition elements and resize font, but scummvm refuses to recognize modified themes, inconsistently, based on criteria I haven't yet figured-out.

This might be the reason nobody has made themes compliant with the updated theme engine yet.

MerlijnWajer commented 3 years ago

Maybe file a bug with them? I think we can close this ticket though.