#10534 closed defect (fixed)

MADE: RTZ - Failure to manually extract necessary files from GOG release results in assertion without further explanation

Reported by: raziel- Owned by: bonki
Priority: normal Component: Engine: MADE
Keywords: Cc:
Game: Return to Zork

Description

ScummVM 2.1.0git (May 18 2018 11:24:32)
Features compiled in: Vorbis FLAC MP3 RGB zLib MPEG2 Theora AAC FreeType2 JPEG PNG cloud (servers, local)

On starting the game
Return to Zork (V1.1, 12/7/93, installed, CD/DOS/English)
i get the error
assertion "_handle" failed: file "common/file.cpp", line 137

AmigaOS4 - PPC - SDL - BE
gcc (adtools build 5.4.0) 5.4.0

Attachments (5)

Debug 101 v1.1.2 - this is the_000.png (204.5 KB ) - added by raziel- 19 months ago.
Debug 101 v1.1.2 - this is the_001.png (194.2 KB ) - added by raziel- 19 months ago.
line break 137
Debug 101 v1.1.2 - this is the_002.png (196.4 KB ) - added by raziel- 19 months ago.
line break 138
Debug 101 v1.1.2 - this is the_003.png (197.6 KB ) - added by raziel- 19 months ago.
line break 139
Debug 101 v1.1.2 - this is the_004.png (199.9 KB ) - added by raziel- 19 months ago.
error("foo") in place

Download all attachments as: .zip

Change History (24)

comment:1 by bonki, 19 months ago

I'm unable to reproduce this on Windows, could you provide a backtrace?

comment:2 by raziel-, 19 months ago

I'm afraid not.
GDB is locking up when the assertion happens.
As this isn't a crash i also don't have anything on the serial log.

Woiuld there be a debugger switch to provide more info?
Or maybe i could add some printf's to my local branch to give more insight?

comment:3 by bonki, 19 months ago

Can you try setting a conditional breakpoint, e.g. b file.cpp:137 if (!_handle)? That should enable you to print a backtrace before the assert() happens.

comment:4 by raziel-, 19 months ago

I'm trying but i don't think you'll get any usable "back"trace from my system.

I can't make gdb to work, but i tried with db101 (local graphical debugger) and attach a screenshot with the information.
If you need more, just shout.

Some more questions:

1) I can't find if (!_handle) anywhere in the code, i did find assert(_handle) on line 137 in common/file.cpp, so that's where i set the breakpoint
2) There is no file.cpp in engines/made, but a few with the same name in different places, could you elaborate which file you mean?

Sorry, still a noob here

comment:5 by bonki, 19 months ago

b file.cpp:137 if (!_handle) is gdb syntax for "set a breakpoint on file.cpp (common/file.cpp) line 137 but trigger only if _handle is null".

The screenshot is useful but is the backtrace really from right before the assert happens or from the first time the breakpoint on file.cpp:137 triggered? If it's the former I would find this strange because right before the call to sourceS.skip(20) (which does a seek() under the hood which is why it triggers the breakpoint) there's a sourceS.read(...) which has an identical assert on _handle. I don't see how _handle can be valid on L609 and L613 but not L615.
Can you double check and provide a screenshot from right before the assert triggers?

comment:6 by raziel-, 19 months ago

Sorry that you have to deal with noobs...

Expect strange crashes from me, i have a system that tend to reveal all kind of bugs :-/

I did another run (my local gdb seems to not be feature rich, either that or i'm too dumb to understand how it works - i get a "symbol table not load" or something)

Anyway, i set another two breakpoints at lines 138 and 139 in common/file.cpp.
I don't know if the state of the backtrace is BEFORE or AFTER the break line, but i guess it's before.

So, first screenie is the break at line 137, second is line 138, third is line 139.

Hopefully that helps

edit: I need to add that none of those lines trigger the assertion

Last edited 19 months ago by raziel- (previous) (diff)

by raziel-, 19 months ago

line break 137

by raziel-, 19 months ago

line break 138

by raziel-, 19 months ago

line break 139

comment:7 by bonki, 19 months ago

No worries :-)

Adding breakpoints on lines 138/139 isn't really helpful unfortunately, the problem is that your breakpoint triggers every time the engine does a seek and it seems that the _handle isn't immediately invalid so the first call is not relevant/interesting.
We are only interested in the call to seek when _handle actually is invalid. So you would have to step through all calls and find the one which triggers the assertion if you can't make the debugger you're using provide a backtrace when the assertion already has happened (weird).

As an easy workaround you could remove the line assert(_handle) (L137) and add

if (!_handle)
    error("foo");

then recompile and add a breakpoint on the second line (now L138).

Last edited 19 months ago by bonki (previous) (diff)

comment:8 by raziel-, 19 months ago

I hope i understand correctly
I set the breakpoint at line 139, as i didn't remove the original line, so the break is on the "error" line, correct?

	//assert(_handle);
	if (!_handle)
		error("foo");

comment:9 by bonki, 19 months ago

Yes!

by raziel-, 19 months ago

error("foo") in place

comment:10 by raziel-, 19 months ago

Above screenshot shows the state before "foo" is printed, do you need the backtrace from when the foo has been printed too?

comment:11 by bonki, 19 months ago

No that's fine, thanks! Apparently it can't find RTZCD.PRJ which is part of the CD release (see also http://wiki.scummvm.org/index.php/Datafiles).

comment:12 by raziel-, 19 months ago

Wow...that is one evil way to tell the user it can't find a file :-)
Can the assertion be enhanced to tell that, and if, what file is missing?

btw: I do have RTZCD.DAT in the game files dirs
RTZCD.DAT 536064 bytes
f5c3c3740e9a20bbb26f7f952cf020bd RTZCD.DAT

comment:13 by raziel-, 19 months ago

Ah, sorry, wrong file.

That one is missing...i have the gog release

comment:14 by raziel-, 19 months ago

And now i see that i have missed to extract one file :-(

comment:15 by bonki, 19 months ago

Yes, this definitely needs improving :-)

In the meanwhile I have updated the wiki page with a direct link to the thread on the GoG forums.

comment:16 by bonki, 19 months ago

Summary: MADE: RTZ - assertion on game startMADE: RTZ - Failure to manually extract necessary files from GOG release results in assertion without further explanation

comment:17 by raziel-, 19 months ago

And after decrunching that files it works fine :-/

Sorry for the hassle

comment:18 by bonki, 19 months ago

No problem at all, in my book we shouldn't just explode but provide a more meaningful error message to the user so this is useful information.

comment:19 by bonki, 19 months ago

Owner: set to bonki
Resolution: fixed
Status: newclosed

Fixed in commit 5dda21c1c2552945a9446ee24ec6692734a0332a, thanks for reporting!

Note: See TracTickets for help on using tickets.