View Full Version : Windows R6025 - pure virtual function call - AMD Driver - Malicious GLSL Code

07-31-2013, 07:05 PM
Hi there.

Ok, not really malicious, but you know...

I have an issue when compiling a buggy glsl geometry shader. First of all, the buggy shader code goes like this:

!! BAD CODE !!

// dont mind the names, just for debug reasons
uvec4 abc( uint marker )
return uvec4( marker ) >> uvec3(7,6,5,4) & uvec4(1) ;

BEFORE seeing the solution, do you see the buggy spot? ;) Awesomely annoying!

Now the fix is simple:

// dont mind the names, just for debug reasons
uvec4 abc( uint marker )
return uvec4( marker ) >> uvec4(7,6,5,4) & uvec4(1) ;

When I compile the BAD CODE code, I get the pure virtual function exception pretty much between glCompileShader and glGetShaderInfoLog. What a pity. The GOOD CODE, as the name implies, makes the bug disappear!


There is even no pure virtual function call handler called. I also tried to set one, but also not called. I checked that in purevirt.c.

That took some time to figure it out! I just thought there is some deeper trouble in the engine or something... I really sweat my pants full! However.

Can someone please check the code I posted above if the same "error" message occurs?
If so, I dont think that this is the right way to respond to the mistakes I made in GLSL code.


Im using the latest AMD Driver

Alfonse Reinheart
07-31-2013, 08:48 PM
The compiler is simply crashing. This is no different from getting an "internal compiler error" in a C++ compiler. That means the compiler is broken. It would be good to know what actual hardware you're compiling this on, as AMD supports a pretty broad range of compilers that could crash.

Compilation can fail. But compilers crashing is always a bug (though your GLSL is certainly ill-formed).

08-01-2013, 05:24 AM
Hi there.

Card: Sapphire Ultimate Radeon HD7750
Catalyst: 13.4

Although is realized that there is also a Catalyst 13.5CAP1 and a 13.6Beta... Anyway, responding to a syntax error with a pure function call really seems to being a bug.

That reminds to an older problem I had with a AMD card that had the first tesselation hardware build in. It was two years ago or so. It was when filling undeclared varyings or using unset varying in subsequent tessellation stages. Doing so resulted in random OpenGL application code crashes like glViewport. Anyway.

So what can be done with the posted bug report?