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

[raziel-]

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

[bonki]

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

[raziel-]

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?

[bonki]

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.

[raziel-]

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

[bonki]

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?

[raziel-]

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

[raziel-]

line break 137

[raziel-]

line break 138

[raziel-]

line break 139

[bonki]

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).

[raziel-]

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");

[bonki]

Yes!

[raziel-]

error("foo") in place

[raziel-]

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

[bonki]

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).

[raziel-]

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

[raziel-]

Ah, sorry, wrong file.

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

[raziel-]

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

[bonki]

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.

[raziel-]

And after decrunching that files it works fine :-/

Sorry for the hassle

[bonki]

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.

[bonki]

Fixed in commit 5dda21c1c2552945a9446ee24ec6692734a0332a, thanks for reporting!