#1299 closed defect (invalid)
ALL: Crash in launcher
| Reported by: | SF/lechimp | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | high | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
ScummVM 0.5.4cvs (Nov 5 2003 05:08:05)
I am running MacOS X and ScummVM crashes everytime I try to configure a SCUMM game using the built-in game launcher ( I haven't tried the command line).
What happens is I press Add Game and select the game file directory. The popup dialog requests that I select a file. In the file list several files with the same name (typically 00.LFL or 000.LFL) show up. No matter which I select, ScummVM crashes ("unexpectedly quits")
Console reports : common/config-manager.cpp:392: failed assertion `!domain.isEmpty()'
It happens with any SCUMM game I select. Beneath a Steel Sky and Flight of the Amazon Queen both work fine since they don't draw the popup dialog.
Ticket imported from: #836261. Ticket imported from: bugs/1299.
Attachments (1)
Change History (22)
comment:1 by , 20 years ago
| Priority: | normal → high |
|---|
comment:2 by , 20 years ago
comment:3 by , 20 years ago
| Owner: | set to |
|---|---|
| Summary: | ScummVM quits upon selecting game file → ALL: Crash in launcher |
comment:4 by , 20 years ago
I am using the latest CVS tarball (November 5th, downloaded just a few hours ago).
The problem was also present with the previous tarball, so I figured it was a temporary thing during the GUI rewrite and waited for this one. I haven't used any of the CVS builds between Oct. 25th and Nov. 3rd.
I am attaching a screenshot where I have just selected the directory containing the PC version of Loom, 16 colors and the launcher says I should pick a file. After selecting 'Choose' the program crashes.
comment:5 by , 20 years ago
Sorry, it was the 256 Color CD version of Loom in the screenshot - not that I think it matters much . It does the same no matter which SCUMM game I try.
I've tried trashing ScummVM preferences, restarting, the usual rituals when things don't work. And it still crashes on me - weird.
comment:6 by , 20 years ago
That's extremly strange.
How are you compiling ScummVM? I.e., in particular: * What SDL version do you use? * Which gcc version (gcc -v will tell the version and build ID, in my case that's 3.3, build 1493) * Do you do anything special besides "./configure && make" ?
Also it might be interesting to learn what data the directory you point ScummVM at before it crashes contains. I.e. maybe you can attach a list of files in the directory.
comment:7 by , 20 years ago
This output from gcc -v :
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420 (prerelease)
I am using the latest version of SDL (1.2.6 I think) and running MacOS X 10.2.8. I haven't changed any of these things for along time. The change happened with a new tarball, I'm sure.
I always point at the directory that contains the .LA0, .000, .LFL or similar files. Passing any other directory will result in the "ScummVM could not find any game in the specified directory"
I can give you an example of the contents of Passport to Adventure (PC) folder : 000.LFL 901.LFL 902.LFL 904.LFL DISK01.LEC INSTALL.BAT README.TXT SAMPLER.EXE
Selecting this folder will list a couple of 000.LFL files and again, if I select one of them and click 'Choose' ScummVM crashes...
comment:8 by , 20 years ago
Oh, and no I just do as the README suggests : uncomment the two lines and add an INCLUDES directive in build.rules. Run "./configure" and "make bundle".
comment:9 by , 20 years ago
"will list a couple of 000.LFL files" ... Uhm, it's not supposed to list *any* files, only directories. Very strange.
How did you install SDL?
BTW, the gcc version you have is rather buggy. I recommend getting the update to 3.3 from http://connect.apple.com.
comment:10 by , 20 years ago
Did you see the attached PDF file? - the 000.LFL files are shown allright.
I used fink to install SDL in the usual /sw directory and I'm downloading the gcc 3.3 updater right now. But gcc 3.1 has worked fine so far, so I doubt that's the problem.
But surely if I'm the only one who experiences these problems, it must be my configuration. I just don't understand, I didn't change anything important between two CVS versions..
I'll look at it tonight (GMT +1) and may possibly try to build all the last tarballs from the past week to see if any of them work.
comment:11 by , 20 years ago
I get the same bug here. Same OS, same GCC version. Downloading the GCC update now. Apple's server sure is slow today.
It should be noted however, that all non-scumm games I have tried (Simon, BASS, Queen) work fine.
(Broken Sword 2 exits with the message "open cannot *OPEN* TEXT.CLU" when trying to run from CD.)
When trying to add a game without ambiguous .LFL files, such as CMI, the interpreter will exit right away with the error message "common/config-manager.cpp:404: failed assertion `!domain.isEmpty()' Abort".
When the game files are ambiguous, I first get the 000.LFL list and then the above error message when trying to choose one of them.
comment:12 by , 20 years ago
Yes I saw your screenshot. It's not that I doubt your words, it's just that this is not at all what should happen.
Well I have encountered about 5 serious bugs in Apple GCC 3.1 which rendered some software either uncompilable (due to the compiler crashing), or produced incorrect non-working code. For "normal" code.
And of course something in your configuration changed: you got youself a newer copy of the ScummVM source code. Compiler bugs usually only occur in very specific constellation (otherwise the manufaturer would have discovered it earlier and fixed it). Hence it a seemingly "harmless" change to the source may trigger a compiler bug which wasn't an issue before.
Anyway, I don't claim that this is a compiler bug, but it very well *might* be one. Apple GCC 3.3 fixes all the serious bugs I encountered in Apple GCC 3.1 (but there is at least one new one in it, which makes it produce invalid code for ScummVM when -O3 is used. Oh well).
comment:13 by , 20 years ago
Forgot to mention: trying to start a scumm game from the command line directly doesn't work at all. I just get the "Usage:" list. Non-scumm games work from the command line, however.
I remember that before I deleted the preferences and tried choosing a game from the list generated with an older, working, version, Scummvm would say something like "'comi' is not a valid target. Please type scummvm --list-targets to see a list of valid targets."
Oh, and I think this behaviour started with a CVS version from some time last week.
comment:14 by , 20 years ago
I'd be curious to know if you can reproduce the problem with my personal build: <http://dev.quendi.de/scummvm/ScummVM- 20031105.tar.bz2>
comment:15 by , 20 years ago
All seems to work fine with your build (except that Broken Sword 2 still won't start). I suppose it is a GCC bug after all. I'll try to update GCC later tonight if Apple's server is feeling better.
comment:16 by , 20 years ago
Hooray! gcc 3.3 does the trick! SCUMM games now work again.So it was a compiler bug.
I haven't been able to test BS2, since I don't have it, but give it a try ignalina.
Perhaps a note in the Compiling section in the README about "if you use gcc, version 3.3 or above is required" would be good to avoid this or other issues happening to others.
Thanks for the help
comment:17 by , 20 years ago
Great.
BTW I can confirm that bs2 doesnt work anymore. Odd, I'll investigate (you might want to file a bug report).
comment:18 by , 20 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:19 by , 20 years ago
I found the cause for the BS2 crash, too, it's fixed in CVS - so no need to report it :-)
comment:20 by , 20 years ago
Hmm... Only works here if run from HD (I copied the entire contents of the CD), when I try to run it from the CD directly, I still get the "open cannot *OPEN* TEXT.CLU" error. Is it meant to be like that? I can run COMI right off the CD.
This is with 0.5.5cvs (Nov 6 2003 18:30:35), OS X 10.2.8 and Broken Sword II (alt) version. Compiled with GCC 3.3.
comment:21 by , 5 years ago
| Component: | --Unset-- → GUI |
|---|
I can't reproduce this with latest CVS on Mac OS X. When did you make your checkout (the date/time you print is just the build time; the version you have could be 1 day or 1 month old, I can't tell).
Note: nowhere should things like "00.LFL" or "000.LFL" appear. That is really strange...