BUG: Ezquake crash (on console-autocompletion IF vid_settings changed)

[onethree7]

I can reproduce a crash by:

-opening EZQUAKE with gl_no24bit 1 (saved in config)
-game open & via console: gl_no24bit 0 , + vid_restart
-FOR EXAMPLE: now change gamma... type gl_ga (HIT TAB, to get autocompletion)
-crashes.

Crashes on other GL_ or Vid_ related commands then. Not sure about others.
(Windows 7, 64bit, latest+nightly)

[jite]

Thanks for reporting. We will look into is as soon as we get time. For future reference please read the simple rules in the wiki for issue reporting. Thanks

[jite]

I can't reproduce this.. Are you still experiencing the issue?

[onethree7]

yes, i can still reproduce this.
basically switching gl_no24bit to 0/1 is only possible via config export , quit, and reloading EZq.
after that variable has been changed without restart, i might get lucky, turn on 3-4 particle effects, but as soon as i want to touch gamma or something serious it crashes.

I am using latest QRP textures (as probably most everybody) :)
i´ve attached my cfg. try loading & flip no24bit, maybe its in there

config.zip

[onethree7]

using 15.march nightly build, and it seems fixed. Can´t reproduce anymore since this one!

[onethree7]

ok i was a bit soon here. Still reoccuring. Changed no24bit , didnt restart client. I tried changing gamma via autocompletion no errors.... then i tried to change s_desiredsamples and hit TAB to complete, BOOM crash to desktop again. Still there! :(

[jite]

So is it no24bit toggling that causes it still? I'm wondering if you have some weirdo files in your quake or qw directory causing this... If you could try creating a new quake folder only containing original pak0.pak and pak1.pak (unmodiifed) and the .exe and see if you can reproduce, otherwise, just keep popping in the rest of your files one by one (pak/pk3 files) and then like texture folders until you hit what's causing it.

[onethree7]

ok i will try that reducing strategy (freshinstall) and check this weekend!
I had Pengu try no24bit 1 and his qw crashed also. (one more confirmed) :)

[jite]

Are you using nquake as base?

[jite]

I do believe you hehe, it's just that it's merely impossible to debug if I can't reproduce it :)

[JoakimSoderberg]

This is where having a visual studio project would come in handy. Very easy for @onethree7 to simply install it and run via that (or attach to the process as it crahses) to get a full stack trace when the crash happens.

But I guess the same thing could be done with gdb in mingw, just not as straight forward.

[jite]

@JoakimSoderberg Absolutely! How's your CMake pull request coming along? ;)

[JoakimSoderberg]

:D

[onethree7]

hi guys, thanks for all the suggestions and feedback!
I thiiiiiiink i managed to drill the issue down to a .pk3.

I tried with a pak1+pak2.pak freshinstall from quake cd :D then copyied my ezquake exe and ezquake folder over. Tried to reproduce [always like this: 1) map dm4 2)gl_no24bit 1 3)vid_restart 4)map dm6 5) gl_gam(TAB) 6)s_des(TAB)] usually there it crashes. It crashed again here, so i had to look further.

I began reducing the ezquake folder and found that the issue only occurs when a file called "base.pk3" is inside qw\ezquake\ . The other ,pk3 can be loaded fine without any issue. But as soon base.pk3 is there, i get this crash.

Then i checked weather this is nquake or ezquake delivered :D Those files are in ezquake Full version i believe. My base.pk3 has the following md5 sum "c2282a0426931cb13f0a28aa5f5246aa".

As for debugging, im totally clueless sadly. I have visual studio 2015 installed, but whenever im hitting debug after the crash, my debugger crashes :D ;D guess thats windows^^

[onethree7]

one correction on reproducing its not at step 2)gl_no24bit 1, its 0!!! as i switch from using it to not using it (sorry)

Edit: Concerning your question: Are you using nquake as base?
-> nope

[meag]

The version of base.pk3 I am using has a different md5 sum ("52c9baeb5618f3d7c67572ec8621ecfd"), available from the full install of ezquake 2.1, here

Can you test with that version, and if that doesn't crash (fingers crossed) we can take it from there to work out what the differences are?

[jite]

I was able to reproduce this fairly easy by following the steps. Just that I can't recall what gdb told me :(

I'll see if I can get my memory straight and update this post with what I found, but I think it had something to do with the cache ... Hmm, some small memory fragments coming back while writing: It was something with hash buckets in the fs.. fs_nocache 1 "solved" the issue IIRC....

[onethree7]

<3 <3 <3
can´t reproduce at all on todays nightly. Great job guys, thanks 👍

[meag]

Good to hear. It was my mistake when trying to reproduce it, your steps worked perfectly. Thanks for spending the time and working it out.