[Fixed] PDAs Still Causing a Crash

[Enjay]

g4.8pre-4-g3ef60a40a

The visual issue that was reported in this thread: viewtopic.php?f=7&t=73403

has indeed been fixed. However, the test file that was sent to the devs to illustrate that bug still causes a crash with an

Code: Select all • Expand view

Execution could not continue.

Could not allocate memory for vulkan buffer: out of device memory

message.

As before, load the test file, pick up all of the PDA items then start scrolling through them. Click on one in the left column, scroll down the text on the right, rinse and repeat for all of the the PDA entries and sooner or later your GZDoom will probably hang.

When GZDoom hangs, if I click on the screen a few times I get a white screen and the dialogue that tells me my computer is getting stuff ready to send to Microsoft.

If I do not click on the screen, but simply wait, GZDoom eventually drops out itself, gives me the out of memory message and allows me to save a crash report.

Very reproducible on my system.

[Enjay]

Just as with the visual bug, the problem appeared between gzdoom-x64-g4.7.0pre-101-g39513cf7a and gzdoom-x64-g4.7.0pre-131-gc3772fe20.

I was able to run the test map and click and scroll around the PDAs for over 5 minutes with gzdoom-x64-g4.7.0pre-101-g39513cf7a and no sign of a crash. With gzdoom-x64-g4.7.0pre-131-gc3772fe20 I got one after about 30 seconds.

Unfortunately, there are quite a lot of commits on the 11th and 10th of Aug (all of which I guess could have been done between these builds).

https://github.com/coelckers/gzdoom/com ... nch=master

[Enjay]

I notice in the commits for the period between the two builds I identified that there are a few changes that mention the 2D buffer. Would what the PDA kit is doing when it is drawing images to the screen be using the 2D buffer? Could one of those commits be where this issue lies?

[dpJudas]

OK since those zero byte buffers keep happening I decided to fix it in the vulkan backend by creating a buffer of 16 bytes. That's the only way of keeping the hardware renderer and vulkan happy at the same time. Here's the PR.

[Enjay]

Do you know if this made it into build gzdoom-x64-g4.8pre-8-g8f54de99e ?

Judging by the time of the PR, Rachael merging it and the time the build was posted, I think it should be in. If so, the problem still exists.

CrashReport.zip

If not, I'll just wait until tomorrow's build and test again.

[drfrag]

It's in. Just check the hash in the log: https://github.com/coelckers/gzdoom/commits

[Enjay]

In that case, unfortunately, this does not resolve the crash that I am experiencing.

Any idea which other commits from the 11th or 10th of Aug could be re-looked at?

[Enjay]

It's in. Just check the hash in the log: https://github.com/coelckers/gzdoom/commits

OK, I understand a bit more how the log works now (I never really got into Git after GZDoom moved from SVN to Git because it was at the time when there was becoming less and less need for me to be compiling the source). If I'm reading it right:

g4.7.0pre-101-g39513cf7a (which works) was compiled after 39513cf7aef33dd0de3afd662815c64aafa870b5 which was committed on 9th August.

g4.7.0pre-131-gc3772fe20 (which crashes) was compiled after c3772fe2036a8778d2e7198570a3ab0658e2e88e which was the last commit on 11th August.

Therefore, all commits from 10th August (13 of them) and 11th August (17 of them) comprise the difference between the working and the crashing build.
Is that correct?

That's a lot of commits (it would have to happen after two busy days with no builds in the middle) and none of the commits really leap into my non-coder brain as obvious "yes, that's the one" from their descriptions (though a few seem as if they are unlikely).

Unfortunately, my machine isn't set up for compiling anything at the moment so I can't even try to pick through them one by one and track it down any further than the above broad list myself, otherwise I'd have a go.


[edit]
I have also been able to get the crash with the Siren TC ( viewtopic.php?f=19&t=68686 ). The PDA messages in that are less graphically intensive than the ones in my file but after about 90 seconds of clicking around the PDA interface (after summoning all of the PDAs) I got the same type of crash.

CrashReport.zip

It is perhaps interesting that the crash took longer to get in Sirens versus my test file. My messages use a lot of graphics and the Sirens ones are just text (plus, mine uses hi-res graphics and has more PDAs too) but they do both show the same kind of crash eventually.

Unfortunately, Sirens is also a huge project and, obviously, is also based on the PDA starter kit too. So slimming it down to a smaller test file is not really possible there either.
[/edit]

[Enjay]

I realise that this probably doesn't help much, but here are three screenshots of my task manager:
The first row was captured immediately on starting the test map.
The second row was captured about 20 seconds later, moments before the crash happened. As soon as I open the PDAs, the memory use starts to climb and when it gets to about 640+MB, that's when the crash happens (tested several times, it was always around that number).
The third row is immediately after the crash happened.



From the performance monitor:

1 = GZDoom started (and me running around picking up PDAs)
2 = Opened the PDA Reader (then scrolling around the various messages)
3 = Crash

I have also noticed that even if I close the PDA reader before the crash happens, and then quit GZDoom, it takes much longer to return me to the desktop than normal (can be 10 seconds or so). I assume some sort of memory flush is going on?

[dpJudas]

How do I open the PDA reader? Not really sure how this part of gzdoom works.

[Enjay]

It should appear as an inventory item, As it's the only one, it should be autoselected so, after picking the PDAs up, press whatever button you have bound to use the inventory. I *think* it's the enter key by default (if indeed it is bound by default in a Doom game).

[dpJudas]

It is the enter key, but it doesn't seem to do anything. Sorry, I know very little about this part of zdoom.

[Enjay]

Silly question I know, but you do have the example file that I messaged out to the dev group don't you? If not, I'll pm a link.

When I load the file and pick up the PDAs, the item is auto selected and it works by pressing Enter. No special configuration needed - it's just using default keybindings etc.

[dpJudas]

If you sent it to the developers group as a private message, then I don't have it as I'm not member of that group.

[Enjay]

Yup, just realised that on checking my sent PMs. I've sent it to you now.