search

andrei-drexler / ironwail

High-performance QuakeSpasm fork
GNU General Public License v2.0
528 stars 49 forks source link

Crash on load quicksave #311

Closed 4LT closed 5 months ago

4LT commented 6 months ago

Build: Latest, Master branch OS: LInux

image

Attempts to load quicksave on the map "Replicon" results in a crash with dialog box shown in the screenshot

replicon_quicksave.zip

alexey-lysiuk commented 6 months ago

Add -heapsize 1048576 to command line options. This increases heap size to 1 GB from default of 384 MB. You can experiment with the value if you want. Probably, 512 MB (-heapsize 524288) will be enough for this map.

4LT commented 6 months ago

I tried setting -heapsize 1048576 but I still get the same behavior

4LT commented 6 months ago

Ahh, no, I figured it out, I wasn't on the master branch after all, it was my own branch.

4LT commented 6 months ago

Ack! Re-compiled with the latest changes I'm sure I'm on the master branch this time and it's occurring again. WTF is going on? -heapsize still has no effect

gcc --version: gcc (GCC) 13.2.1 20230801

In case this is a mis-compile

Also, I performed make clean before the latest compile, still getting a crash

error is always consistently "133120 bytes"

Update: Can't replicate after a full system upgrade and reboot. Not sure if updating a dependency fixed it, or it's some global system state having an effect

Placo commented 6 months ago

I've had the same issue in the map "Gibtropolis" recently. I loaded another save then and forgot about he issue. Just now I have the same problem in ad_tears with an autosave. I have tried to increase heapsize but I get the crash "Z_Realloc: failed on allocation of 243712 bytes" consistently while trying to load that autosave. I was using the windows x64 ironwail.exe compiled by me in VS2022 with the latest source. I have tried using the exe in the artifacts of the latest CI here but I have the exact same error trying to load that save.

Here is that save in a zip file: ad_tears.zip

Update: I still haven't restarted my system, but the latest release version here (Ironwail 0.7.0 from Mar 17, 2023) can load the save no problem, and I still have the crash with the latest CI ironwail.exe, so it really looks like a bug introduced since last year's release

Placo commented 6 months ago

I have narrowed it down to commit a30008d Versions before that commit load my save file, but versions after crash...

4LT commented 6 months ago

apparently it depends on my working directory whether or not the crash occurs;

If my CWD is my ironwail directory (~/.ironwail), loading the save will cause a crash.

If my CWD is something else, loading the save does not cause a crash.

(I have IronWail built with DO_USERDIRS=1)

andrei-drexler commented 6 months ago

Thanks for looking into this, folks, I'll try to repro this again with the new info.

andrei-drexler commented 6 months ago

@Placo You mentioned you were running the Win64 version - could you share how your Quake dir is set up, where the executable is relative to that, and how you're launching it? I'm hoping to repro this on Windows, so I can use the VS debugger.

Placo commented 6 months ago

Hello @andrei-drexler , sorry for the late answer I was off the internet for a few days. I am using a "legacy" dir set up, that's more or less the same folder I've been hauling from HDD to HDD since the late 90s (with a few cleanups ofc) ie:

The autosave I linked earlier still crashes with that big folder (having restarted Windows multiple times since). I have the crash launching Ironwail with only basic command line params ("ironwail.exe -width 2560 -height 1440 -game ad180 +skill 2 +map start").

I have tried to make a minimal repro Quake folder by just copying the ID1, AD180 folders, the latest Ironwail binaries and Simple Quake Launcher in a new folder, but I don't get the crash there. I am beginning to think in my case the whole mass of mod folders is what is causing latest Ironwail to break a sweat.

andrei-drexler commented 6 months ago

Thanks for the details, @Placo. I was finally able to repro this by creating a few copies of my ad directory, and then abusing the -basedir argument to use the same working directory multiple times. The issue should be fixed in b44479827dcdd6493de902efbca12110f7840316.

Placo commented 5 months ago

It has fixed the issue for me, thanks a lot!