Catalyst crash on first SwapBuffers after resize

TL/DR: Program found at locks up Catalyst driver or corrupts the screen on the first SwapBuffers after maximizing the window. Anyone able to reproduce? (THIS MAY HANG YOUR SYSTEM!)

Hello. I’ve come across an issue where the Catalyst driver sometimes (~50% of the time) locks up on both Windows Vista x64 and Ubuntu 10.04 on a HD3850. The problem persists across multiple Catalyst versions, including 10.5 and on Ubuntu I can reliably reproduce screen corruption the times it doesn’t hang.

Basically I have a render loop that that renders a (simple) scene to a framebuffer with a sRGBA8 colour texture and a F32 depth texture attached, blits the colour texture to the context framebuffer (name 0) using glBlitFramebuffer and calls SwapBuffers(hdc).

The problem almost exclusively occurs if I start the application windowed in, say, 800x600 and then maximize the window (~1920x1050). My application resizes the textures used in the framebuffers on WM_SIZE (glTexImage2D with no data), and when the next frame is rendered (when the message loop is idle) the driver either hangs or starts corrupting random textures/framebuffers (even of other applications like VS2010) on the SwapBuffers(hdc) call.

Now, I could very well be doing something wrong here, but regardless the driver shouldn’t hang.

The program is linked at the top if anyone wants to give it a whirl. You’ll need the VS2010 C++ runtime and GL3.2, but hopefully nothing else if I linked it correctly. I can probably provide code as well, but it’s buried deep in an abstraction layer and probably wouldn’t be very useful for a quick look.


I’ve just sent another case of Catalyst hang to ATI.
It’s 100%, but appears only when Geometry Shader is used.

Not sure these bugs are connected. I recommend contacting ATI yourself.

I don’t use a geometry shader here so it’s probably not related to your problem (well, who knows).

But yeah, I’ll see about reporting it to ATI. I just wanted a quick sanity check to avoid wasting their time. :slight_smile:

for the swapbuffer issue, we have been able to reproduce it (it sems specific to that ASIC). we will look into it.

Excellent, thank you. Let me know if there’s anything else I can do to help.