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?
glReadPixels works like charm… It will be more usefull to post readback code. Maybe you miss something…
used to happen to me sometimes when frequently reading to a recently allocated buffer. something like:
char *buffer = new char [numOfPixels];
glReadPixels(..., buffer);
would run into an access violation and crash my application.
But I never got around to figure out why.
Using a pre-allocated buffer like, for example:
extern char buffer[numofpixels];
glReadPixels(..., buffer);
solved the problem…Don’t know if it helps though.
I think, your memory allocation failed then in the first place returning a NULL pointer? Check the value of the “buffer”-pointer.
Do you free the memory later on? One technique I use to ensure proper memory cleanup is using std::vector<char> for such cases:
std::vector<char> buffer(numOfPixels);
glReadPixels(..., &buffer[0]);
“buffer” will be cleaned up automatically (even in case of exceptions)…
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…
Y.
Good point; the default values for alignment of pixel pack/unpack should be 1 instead of 4 (or 8?) as it is now!
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).