I possess a 2-CD version of T7G (The Seventh Guest).
On Windows 7 64-Bit, ScummVM successfully starts the game from the files I copied from the CDs to my HDD.
Meanwhile, ScummVM on Android crashes upon starting the very same files.
Nexus 10 Tablet / Android 4.3
ScummVM 1.5.0
ScummVM Plugin: groovie 1.5.0
I only receive a popup (german language) "ScummVM wurde beendet" (ScummVM exited).
No clue where to find additional hints or what the problem is.
Any help appreciated.
mschomburg: Thank you for the bug report.
This could be a subtle corrupted, missing or variant datafile issue.
Please could you attach a text file to this bug containing a file listing of your T7G datafiles, preferably with file md5sums? The output of a tool such as this: http://md5summer.org or other tool from http://wiki.scummvm.org/index.php/Reporting_unknown_MD5_checksums would be optimal. This can be done on the PC.
I would also suggest that you try using the latest v1.6.0 stable and/or v1.7.0git development build on Android to see if the crash disappears. These can be found here:
http://buildbot.scummvm.org/builds.html
You will need to download the relevant zip and using a file manager such as Ghostcommander, decompress the zip to apks, then uninstall the marketplace/play store version of ScummVM and all plugins and install the version from the APKs supplied (You will need to enable third party installation in settings temporarily).
Apart from that, you can help us by providing the relevant section of the Android Debug Log:
http://wiki.scummvm.org/index.php/Debugging_ScummVM#Android
Installed Android SDK and enabled USB debugging.
Output gave
E/ScummVM (25311): Groovie::Music: fat.ad not found!
F/libc (25311): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 25324 (ScummVM)
Among the files, I have fat.mt and fat.opl, but not fat.ad.
Therefore I changed the game options to override the generic settings:
Audio
Override global audio settings
Music Driver: Embedded Audio Synthesis
Now it works.
Thanks for giving the hint concerning adb and logcat (I somehow had the impression I needed a
rooted device for that ... now I know how to get such info, and here it gave the necessary clue.)
It still shouldn't crash, this is still a bug.
This is not a crash per se. The engine is erroring out when the file "fat.ad" is not found.
This is being triggered from line 496 which calls error() in the file engines/groovie/music.cpp from within the function:
void MusicPlayerXMI::loadTimbres(const Common::String &filename)
scott_t: Any idea/POV about this?
I haven't seen a variant without that file yet - even GoG and DotEmu have the three fat files (mt, opl and ad) - so not sure why it could be missing. Accidentally missed when copying from the discs or to the Android device perhaps?
That said, personal preference for Android is to use EAS as it sounds awesome anyway, but I know clone2727 will argue for Adlib all night ;)
My apologies, guys.
Double-checked it.
Must have been some copy problem - fat.ad is indeed on my original CD-ROMs.
Cannot explain yet how it was missing after the copy process.
@tdhs: Considering there was a segfault, I really hope we can consider this a crash.
@mthreepwood: AH... I see your point i.e.
E/ScummVM (25311): Groovie::Music: fat.ad not found!
F/libc (25311): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread
25324 (ScummVM)
The second shouldn't happen.. It should error, but then exit cleanly.
scott_t: Maybe try removing that file on a desktop build, and then seeing if you can replicate this error out and segfault crash and then see why it is happening...
If I have time, I will try that with Valgrind...
Right... No replication of the segfault and no critical warnings from valgrind running on Linux x86_64 with latest Git master, with a set of T7G datafiles with fat.ad removed.
However, the error call does cause a number of minor leaks, which could be provoking this by OOM?
These are mainly from MidiDriver_ADLIB::open() and the T7G font loading:
==19778== 7,248 bytes in 1 blocks are possibly lost in loss record 805 of 849
==19778== at 0x4C2A462: calloc (vg_replace_malloc.c:593)
==19778== by 0x536240: OPL::MAME::OPLCreate(int, int, int) (mame.cpp:1118)
==19778== by 0x536659: OPL::MAME::makeAdLibOPL(int) (mame.cpp:1243)
==19778== by 0x534511: OPL::MAME::OPL::init(int) (mame.cpp:56)
==19778== by 0x52EF20: MidiDriver_ADLIB::open() (adlib.cpp:1436)
==19778== by 0x41C907: Groovie::MusicPlayerXMI::MusicPlayerXMI(Groovie::Groov
ieEngine*, Common::String const&) (music.cpp:390)
==19778== by 0x41A9B3: Groovie::GroovieEngine::run() (groovie.cpp:178)
==19778== by 0x409460: runGame(PluginSubclass<MetaEngine> const*, OSystem&, Common::String const&) (main.cpp:229)
==19778== by 0x40A456: scummvm_main (main.cpp:474)
==19778== by 0x4080D7: main (posix-main.cpp:45)
==19778==
==19778== 7,256 bytes in 1 blocks are possibly lost in loss record 806 of 849
==19778== at 0x4C2C037: operator new(unsigned long) (vg_replace_malloc.c:298)
==19778== by 0x53180B: AdLibEmuMusicPlugin::createInstance(MidiDriver**, unsigned int) const (adlib.cpp:2302)
==19778== by 0x517AA1: MidiDriver::createMidi(unsigned int) (mididrv.cpp:371)
==19778== by 0x41C8AE: Groovie::MusicPlayerXMI::MusicPlayerXMI(Groovie::GroovieEngine*, Common::String const&) (music.cpp:387)
==19778== by 0x41A9B3: Groovie::GroovieEngine::run() (groovie.cpp:178)
==19778== by 0x409460: runGame(PluginSubclass<MetaEngine> const*, OSystem&, Common::String const&) (main.cpp:229)
==19778== by 0x40A456: scummvm_main (main.cpp:474)
==19778== by 0x4080D7: main (posix-main.cpp:45)
==19778== 10,799 bytes in 37 blocks are possibly lost in loss record 821 of 849
==19778== at 0x4C2B8C7: operator new[](unsigned long) (vg_replace_malloc.c:363)
==19778== by 0x4337B8: Groovie::T7GFont::load(Common::SeekableReadStream&) (font.cpp:101)
==19778== by 0x41A5DB: Groovie::GroovieEngine::run() (groovie.cpp:142)
==19778== by 0x409460: runGame(PluginSubclass<MetaEngine> const*, OSystem&, Common::String const&) (main.cpp:229)
==19778== by 0x40A456: scummvm_main (main.cpp:474)
==19778== by 0x4080D7: main (posix-main.cpp:45)
I'm beginning to suspect the segfault an Android backend issue relating to the error() call. Out of curiosity I tried BASS and had similar outcome if I omitted sky.dnr:
E/ScummVM (24295): Could not open sky.dnr!
F/libc (24295): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 24308 (ScummVM)
As for memory leaks, wouldn't all engines do that if they hit an error() ?
scott_t: I concur with your conclusion that this is an issue with the Android backend dealing with error() calls.
Reassigning to Android maintainer...
clone2727: Do you concur?