BUG: assert failure on `offset < glBuffersState.buffers[id].size` on map end

[aardappel]

ezQuake version: 3.6-dev-alpha8

OS/device including version: Nvidia 3080 drivers 471.11, using glsl path

Describe the bug

Will crash with offset < glBuffersState.buffers[id].size assertion failure (gl_buffers.c, line 380) upon map end (score screen) at end of FFA match on custom maps (ones I've never played before). Only for some maps. Sometimes crashes fully without showing even the assertion dialog. Always leaves the gamma of the desktop overly bright, fixed by reboot.

To Reproduce Steps to reproduce the behavior:

1. connect to FFA server at 99.47.21.158:28503 and get to end map screen of as many maps as possible.. usually crashes for me after a couple.

[meag]

Hi aard

Does it crash for you on intermission, or when intermission ends and loading the next map? If when loading the next map, does it crash for you if loading that map and not switching from another one?

Thanks, meag

[Calinou]

Always leaves the gamma of the desktop overly bright, fixed by reboot.

This can be fixed by enabling vid_software_palette 1 then running vid_restart to use GLSL-based gamma control instead of hardware gamma. This has a performance cost, but surely it can be stomatched by a RTX 3080 :slightly_smiling_face:

Look into the vid_framebuffer* cvars as well if vid_software_palette doesn't work.

[aardappel]

@meag On starting the intermission. I don't even get to see a single frame of intermission. I can see the timer ticking down, and then boom, crash.

@Calinou heard of that option, I can try it out, though someone (qw player gnz) mentioned it increases input lag as well, which I'd rather not have.

[meag]

@aardappel is this when spectating or playing? I left client connected to ffa for a couple of hours the other day and no issues. Off top of head: the intermission point is causing more surfaces to be rendered than calculated when the map is loaded. Can you give example of a map that caused this so I can download it and check it out?

Thanks, meag

[aardappel]

@meag so far always while playing.

Next time it happens I'll try to remember the map we were on.

It may be triggered by the server somehow.. the client also shows a lot of packetloss just before/at intermission on that server, not sure why. Asked the guys that runs it and it is a pretty vanilla setup though.

[meag]

@aardappel thanks, any extra info that helps reproduce it would be really helpful. We could try a .qwd recording of the game where it crashes (autorecord)? Not sure if that would reproduce it but worth a shot.

[meag]

@aardappel - just added error message so it will give details of the buffer in the error message

[aardappel]

Awesome.. I should wait for a nightly build and then install that?

[aardappel]

Haven't seen it crash as much lately btw, and also haven't updated my ezquake since I reported this.. so I am wondering what changed. If anything, the difference is that maybe that back when it was crashing a lot it was getting new maps from the server? Is there anything different about a map that was just downloaded vs already in the maps dir? Anything being cached?

[aardappel]

Ok, just had crash again, and it was after map tekno, which I've played plenty of times without crashing. Another player mentioned that they've seen the same crash but it depends on.. map combination :P

I didn't have your new build installed yet, sorry.

[rakasunka]

ezquake-3.6-dev-alpha-dev r7192~f4af135b using vid_renderer 1 / NVIDIA-Linux-x86_64-510.39.01.run. I had the error when i was on play.quake1.pl:27501 and entered the end (for map end) teleport-er on maphub_v1. Quake crashed and that was it spit out to terminal.

It's not reproduceable

[meag]

Do we know if this is still an issue on recent builds?