I use glReadPixels() to get the current frame contents for the manual save-game and auto-save game slots. On some rare users computers (Nvidia gfx. card based), driver crashes somewhere between once per day (with approx. 8h of playing) and once per week.
I read the image from a pbuffer and whole OpenGL API usage is single-threaded.
The one way to blindedly try to workaround it is to read the image from the back-buffer…
Anyone else stumbled upon this bug / managed to workaround it?
No, just checked it, I think it is something else for me(I always check for null pointers, use std::auto_ptr etc…).
I read a buffer after resizing the window at WM_SIZE time, so it is possible windows had not resized the application framebuffer, causing an access violation when the window size increased. Or something like that…
There’s definitely a driver bug on ReadPixels----because sometimes when I fail to allocate a sufficient amount of memory, calling ReadPixels will bluescreen my computer. I don’t see any way that could happen except a driver bug.
However, it’s always worked fine when the allocated memory is big enough.
Couldn’t it be related to the pack/unpack alignment ? Check glPixelStorei. If the buffer expected when performing glReadPixels is corrupting a bit of memory after what you allocated, it could explain the random crashes…
Bluescreen can not be related to packing. BSOD is driver or Windows bug. Plain and simple.
My bet is that the driver isn’t checking the user provided buffer (ProbeForWrite). If it’s due to a misdirected “shortcut” to gain a microsecond of performance or an oversight (a very large one at that) is of little concern if the end result is that the write to RAM overwrites the user provided buffer and overflows into physical RAM memory pages owned by the kernel (from kernel-mode the actual RAM after the memory the user process provided can be just about anything).