#7060 closed defect (fixed)
DIG: Crash with 'Unable to find Steam executable from detection pattern'
Reported by: | SF/jamiemarchant | Owned by: | criezy |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | ||
Cc: | Game: | The Dig |
Description
VERION: Version 1.7.0(binary downloaded from http://scummvm.org/downloads/) GAME VERSION: Macintosh/English(CD-ROM) PLATFORM: Mac OX X.5(PowerPC) BUG: ScummVM crashes when I try and run 'The Dig'. 1. Open ScummVM 2. Add a game and select the directory where the game files are. 3. When you hit choose you get a dailog asking you weather you want "Steam/Macintosh" or "Macintosh/English". 4. I choose "Macintosh/English" 5. Hit 'satart' 5. The program quits. When run though a terminal I get this error: 'Unable to find Steam executable from detection pattern!'
Ticket imported from: bugs/7060.
Attachments (2)
Change History (26)
comment:1 by , 9 years ago
Summary: | Crash with 'Unable to find Steam executable from detection pattern' → DIG: Crash with 'Unable to find Steam executable from detection pattern' |
---|
comment:2 by , 9 years ago
comment:3 by , 9 years ago
I am running off of the game CD. The folder contents(including hidden files) is "CD ROM Software 5.1.1 Read Me Desktop The Dig Desktop DB The Dig Data Desktop DF The Dig ?? Icon? Trash Items for your System Folder "
comment:4 by , 8 years ago
Priority: | normal → high |
---|
Update also happens with latest Git builds on Linux.(Fedora Core 23).I think this should be 'high' priority since I can't run the game at all.(at lest with the Mac copy I have.)
comment:5 by , 8 years ago
Priority: | high → normal |
---|
comment:6 by , 8 years ago
I'm not too familiar with the SCUMM detection code, but at first glance it seems the problem is having an error
call inside generateFilenameForDetection
. I would expect an error there to mean it didn't find this game variant, rather than being a fatal error.
comment:7 by , 8 years ago
Actually, never mind that. The above thing _would_ be an error()
since all Steam GameFilenamePattern
s have a corresponding SteamIndexFile
.
What could really cause this crash is the call to generateFilenameForDetection
with a kPlatformUnknown
in ScummMetaEngine::createInstance
which is clearly not handled by lookUpSteamIndexFile
.
That would mean it's the "Your game version appears to be unknown" log message that's triggering it.
comment:8 by , 8 years ago
Hmm the game worked in scummvm version 6. This page says it should work:
https://www.scummvm.org/compatibility/DEV/dig/.(though it could be outdated.)
Why does it not work now?
comment:9 by , 8 years ago
Because of a bug introduced when adding support for the Steam version of The Dig, presumably.
Are you able to compile ScummVM yourself? If so, could you try (as a debugging test rather than a fix) to change line 1127 of engines/scummvm/detection.cpp
from
generateFilenameForDetection(res.fp.pattern, res.fp.genMethod, Common::kPlatformUnknown).c_str(),
into
generateFilenameForDetection(res.fp.pattern, res.fp.genMethod, Common::kPlatformMacintosh).c_str(),
and let us know which log messages you get when run from a terminal?
comment:10 by , 8 years ago
The Dig is the only SCUMM Mac CD game I don't have. But I experimented a bit by creating dummy 'The Dig Data' and 'The Dig' files, adding this game (which let's me choose between a few variants of the game) and starting it.
I then reproduce you error:
WARNING: Engine_SCUMM_create: No unique game candidate found, using first one! Using gameid dig, variant Steam, extra Steam SCUMM version 7, HE version 0 ERROR: Unable to find Steam executable from detection pattern!
It looks like it doesn't respect the choice we make when we select a variant when adding the game. I didn't select the Steam one, but this is still the one it tries to start!
Another issue is that it exits before it gets to the part where it reports this is an unknown variant (when it tries to generate the file name for the unknown variant message) . If I change kPlatformUnknown into kPlatformMacintosh as suggested by wjp the error goes away and it then goes a bit further (I can also change the error in a warning with almost the same result):
WARNING: Engine_SCUMM_create: No unique game candidate found, using first one! Using gameid dig, variant Steam, extra Steam SCUMM version 7, HE version 0 Your game version appears to be unknown. If this is *NOT* a fan-modified version (in particular, not a fan-made translation), please, report the following data to the ScummVM team along with name of the game you tried to add and its version/language/etc.: SCUMM gameid 'dig', file 'The Dig', MD5 '0a1c49df28dc7a9534f1cf38850eadfb' Bad ID 837F0000('....') found in index file directory!
It looks like it is still trying to use the steam version though.
I also removed the 'The Dig' file from my test directory and only keep 'The Dig Data'. Then I get something different as candidates are different and the first one is not the Steam version:
WARNING: Engine_SCUMM_create: No unique game candidate found, using first one! Using gameid dig, variant , extra SCUMM version 7, HE version 0 Your game version appears to be unknown. If this is *NOT* a fan-modified version (in particular, not a fan-made translation), please, report the following data to the ScummVM team along with name of the game you tried to add and its version/language/etc.: SCUMM gameid 'dig', file 'The Dig Data', MD5 '0a1c49df28dc7a9534f1cf38850eadfb' Couldn't find known subfile inside container file 'The Dig Data'!
It still crashes for me, which is normal since as I mentioned above I don't own this version and this is a dummy file. But it crashes in a different way.
So it looks like your game is an unknown version, and we have a bug that causes the issue you see. Which language of the game do you have? It looks like we only have entries for the English and French version (but I only looked quickly).
Note: In your case, removing the dummy 'The Dig' file and keeping only 'The Dig Data' might work around the issue. So you could try to copy the 'The Dig Data' file (and only this file) onto your disk and playing the disk from there rather than from the CD. There is no guarantee but it might work.
Note: I don't understand how the SCUMM game detection work, so I have no idea how to properly fix this.
comment:11 by , 8 years ago
Aha, that's very interesting. The SteamIndexFile
is making the detector jump between different filename patterns, which the variant order doesn't keep into account.
These are the entries for The Dig:
{ "dig", "dig.la%d", kGenDiskNum, UNK_LANG, UNK, 0 }, { "dig", "dig.la%d", kGenDiskNumSteam, UNK_LANG, Common::kPlatformWindows, "Steam" }, { "dig", "dig.la%d", kGenDiskNumSteam, UNK_LANG, Common::kPlatformMacintosh, "Steam" }, { "dig", "thedig.la%d", kGenDiskNum, UNK_LANG, UNK, "Demo" }, // Used by an alternate version of the demo { "dig", "The Dig Data", kGenUnchanged, UNK_LANG, Common::kPlatformMacintosh, 0 }, { "dig", "The Dig Demo Data", kGenUnchanged, UNK_LANG, Common::kPlatformMacintosh, "Demo" },
I expected the first variant (dig.la%d
with unknown platform and without Steam) would always be found *too* if one of the Steam variants was found (and so the first variant would get picked if there were multiple options.)
However, in this case the Steam variant changes the file used for detection from the dig.la%d
pattern to a file called The Dig
, which makes this Steam variant show up _before_ the real variant with the The Dig Data
, _without_ the non-Steam dig.la%d
also being found.
So maybe the fix is to reorder the variants into the following?
{ "dig", "dig.la%d", kGenDiskNum, UNK_LANG, UNK, 0 }, { "dig", "thedig.la%d", kGenDiskNum, UNK_LANG, UNK, "Demo" }, // Used by an alternate version of the demo { "dig", "The Dig Data", kGenUnchanged, UNK_LANG, Common::kPlatformMacintosh, 0 }, { "dig", "The Dig Demo Data", kGenUnchanged, UNK_LANG, Common::kPlatformMacintosh, "Demo" }, { "dig", "dig.la%d", kGenDiskNumSteam, UNK_LANG, Common::kPlatformWindows, "Steam" }, { "dig", "dig.la%d", kGenDiskNumSteam, UNK_LANG, Common::kPlatformMacintosh, "Steam" },
I can't quite judge if that also has negative consequences, though.
comment:12 by , 8 years ago
(Although independently from that, we might also want to fix this generateFilenameForDetection
call in the unknown md5 message.)
comment:13 by , 8 years ago
It's been awhile since Steam support was added, and it appears that nobody noticed this bug :/
Reordering the entries does seem to make sense, however the case for Steam files would be reached anyway, right? I can't look through the code atm since I'm on a mobile device
comment:14 by , 8 years ago
jamie-marchant, please let us know if you are able to test the two changes above (change the platform in the generateFilenameForDetection
call in engines/scumm/detection.cpp from my comment:9, and change the order of the "dig"
entries in engines/scumm/detection_tables.h from my comment:11), and what the result when running it from the terminal is then.
bluegr: I think it's not really a problem if the case for the Steam files is reached, as long as it isn't picked by default because it is first.
comment:15 by , 8 years ago
Result of running comment#9
ALSA lib pcm_dmix.c:1079:(snd_pcm_dmix_open) unable to open slave WARNING: Could not open audio device: ALSA: Couldn't open audio device: File descriptor in bad state! WARNING: You are missing a valid 'translations.dat' file. GUI translation will not be available! WARNING: Could not find theme 'scummclassic' falling back to builtin! User picked target 'dig-mac' (gameid 'dig')... Looking for a plugin supporting this gameid... SCUMM [all games] Starting 'The Dig' WARNING: Engine_SCUMM_create: No unique game candidate found, using first one! Segmentation fault (core dumped)
Please ignore the ALSA warning, not sure why it could not access my sound card that time. (It was probally 'in use'.)
So I will revert comment 9 and try comment 11...
It works, here is the output:
WARNING: SDL mixer output buffer size: 940 differs from desired: 4096! WARNING: You are missing a valid 'translations.dat' file. GUI translation will not be available! WARNING: Could not find theme 'scummclassic' falling back to builtin! ALSA lib pcm.c:7963:(snd_pcm_recover) underrun occurred User picked target 'dig-mac' (gameid 'dig')... Looking for a plugin supporting this gameid... SCUMM [all games] Starting 'The Dig' WARNING: Engine_SCUMM_create: No unique game candidate found, using first one! WARNING: Language file is forced to be ignored!
As you can see there is the same warning as before. So I think we fixed the Mac version but broke the Steam version.
comment:16 by , 8 years ago
jamie-marchant: Thank you for testing.
The issue is that we detect the Mac CD version with the file 'The Dig Data' and the Mac Steam version with the file 'The Dig'. But in both version the executable is actually named 'The Dig' so the Steam version is detected as a possible candidate for the Mac CD version if you kept the executable around. The Steam version doesn't contain a file named 'The Dig Data' though, so the reverse is not true and when using the Steam version, there is no ambiguity. Thus moving the CD version first fixes the issue with the CD version but doesn't break the Steam version.
To make sure I did test the changes from comment 11 with my Steam Mac version of the game and it indeed still works. I am now downloading the Steam Windows version to check that one as well. If it still works I will commit the change as I agree with wjp and md5 that it makes sense.
I am surprised that you don't get the unknown version warning though. Your initial error ('Unable to find Steam executable from detection pattern!') indicates that you do get into the code that should print that message. Could you check your scummvm log file as well (on Linux, if the XDG_CACHE_HOME environment variable is set it should be in there, and otherwise it should be in $HOME/.cache/). You can also try to run scummvm with '-d 1' from the terminal to get more messages. Getting the language and MD5 for your version would allow us to add a proper detection entry for it.
comment:17 by , 8 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
I committed the changes, so it should not be fixed and I confirmed it still works with the Steam Mac and Windows version.
comment:18 by , 8 years ago
You mean "NOW be fixed" right ;).
Here is my log after a successful run:
[2016-09-30 21:50:34] ScummVM 1.10.0git (Sep 30 2016 19:24:54)
[2016-09-30 21:50:34] Vorbis MP3 ALSA SEQ TiMidity RGB zLib FluidSynth Theora AAC FreeType2 JPEG$
[2016-09-30 21:50:34] --- Log opened.
[2016-09-30 21:50:34] WARNING: Could not open audio device: ALSA: Couldn't open audio device: Fi$
[2016-09-30 21:50:35] WARNING: You are missing a valid 'translations.dat' file. GUI translation $
[2016-09-30 21:50:35] WARNING: Could not find theme 'scummclassic' falling back to builtin!
[2016-09-30 21:50:46] WARNING: Engine_SCUMM_create: No unique game candidate found, using first $
[2016-09-30 21:50:46] WARNING: Sound initialization failed. This may cause severe problems in so$
[2016-09-30 21:50:46] WARNING: Sound mixer initialization failed!
[2016-09-30 21:50:46] WARNING: Language file is forced to be ignored!
Are you talking about the 'Your game version appears to be unknown' message on line 1120 of detection.cpp. If so it makes sense that it does not print this as it does find the game. Before the bug was fixed it just found the wrong one. Did you want to look into this further maybe in another bug report?
comment:19 by , 8 years ago
Yes, I meant NOW (the T on my keyboard seems to have a tendency to migrate toward the W when I type 'now') :P
And yes I was talking about the message on line 1120. The message 'Unable to find Steam executable from detection pattern!' comes from the call to generateFilenameForDetection() on line 1127 when generating that unknown version message. This happens when it does find the game (based on the file names) but this is not a know version (based on the file hash - the known hashes are in scum-md5.h).
Before the bug was fixed it found the correct game, but several candidate versions (because your version is unknown). Changing the order of the detection means it now takes the correct version, but you still have several candidates as your version is still unknown and it should still go over the message on line 1120 and print it.
Could you please change the line 1130 from
g_system->logMessage(LogMessageType::kWarning, md5Warning.c_str());
to
warning("%s", md5Warning.c_str());
to see if you get the message then?
comment:20 by , 8 years ago
Still no 'your game version appears to be unknown. If this is *NOT* a fan-modified\' message. Hmmm...
comment:21 by , 8 years ago
I'm a bit worried that the change from comment:9 didn't fix the original crash. That might mean we're still missing something.
comment:22 by , 8 years ago
I had to revert the changes to comment:9 since I got a Segmentation fault. I said above in comment 16 but you must have missed that part.
by , 8 years ago
Attachment: | detection.h added |
---|
My 'detection.h' file to make sure we are on the same page.
comment:23 by , 8 years ago
Ah, right, I indeed missed that the error()
changed into a segfault. So that did at least pinpoint the cause of the error()
call.
by , 8 years ago
Attachment: | detection.cpp added |
---|
In case you want to view this file as I have it configured.
Can you please attach a list of files in the game directory?