Crashing when working out of a folder

Sat May 11, 2019 12:03 pm

So I didn't make this in bug-reporting cause I'm pretty sure it's user error and not a GZDoom bug.

But I'm trying to run a mod out of a folder for development purposes using ZDE, and it was working last night. Now suddenly this morning it crashes on start up and generates a crash report, which I've attached. It runs fine if I load a ZIP/WAD/PK3 whatever, and it runs with no PWADs. It crashes on GZDoom 3.7.2, 4.0.0 and 4.1.1.

What's going on here?

EDIT: After a restart it works now? Even though it "broke" after a restart?
You do not have the required permissions to view the files attached to this post.

Re: Crashing when working out of a folder

Tue May 14, 2019 5:34 am

If a separate file cannot be opened for some reason (due to permission, file system issues, exclusive access by other software, etc), GZDoom crashes.
There are plenty of FWadCollection::OpenLumpReader() calls, but no FileReader::isOpen() checks before further file operations.

This can solved in two ways.
The first one is obviously to add twenty isOpen() conditions with appropriate actions when it returned false.
The second one is to create dummy reader that will return zero length and no data.
Both approaches have own pros and cons. Got a better idea? Let me know.

Re: Crashing when working out of a folder

Tue May 14, 2019 5:57 am

I think the only good solution is to return a dummy FileReader that holds the file name, does not have any length, does not report as being open and which throws an exception if the code tries to read from it.

Re: Crashing when working out of a folder

Tue May 14, 2019 6:17 am

Downside of the exception approach is inability to start GZDoom if at least one file cannot be accessed.
Probably, it's not a big deal because this should be a very rare situation.

Re: Crashing when working out of a folder

Tue May 14, 2019 7:21 am

Normally the file reading code should check if the file is readable. Maybe the exception should be delayed for the second attempt to read. The first should return 0, and if the calling code does not deal with the error, then it should abort.

Re: Crashing when working out of a folder

Tue May 14, 2019 7:42 am

Not sure how this supposed to work. Let's take the actual crash location as example.
A file reader is created FImageSource::GetImage(), and the crash happens in IMGZImage_TryCreate().
Even if the first call won't abort (which is Seek() in this case), it will fail on Read() in the next line.
I assume that seeking a file is qualified as reading it.