\GL optimization causes OpenGL error at runtime - by Invor

Status : 

 


1
0
Sign in
to vote
ID 788446 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 5/22/2013 3:56:29 PM
Access Restriction Public

Description

When compiled using /O2 /GL optimization, my OpenGL program encounters GL_ERROR 1282 during execution, making any use of OpenGL functionality impossible. If the whole program optimization (/GL) ist disabled, no GL errors occur and the program runs just fine.
Furthermore the error only occurs when a certain method, that in turn calls several methods that make heavy use of OpenGL functions, is called repeatingly and can also be fixed by inserting a random std::cout output into the method.

To reproduce the problem you can check the source code and Visual Studio solution online, although on different (graphics) hardware the behaviour of the application might change due to drivers etc. (I observed this on my laptop)
The code is openly accessable at
https://github.com/invor/space-lion/tree/debugging_glError_1282
Sign in to post a comment.
Posted by Eric [MSFT] on 5/28/2013 at 11:06 AM
Hi, I'm glad Mike Danes was able to help here.

Having uninitialized data (and objects with uninitialized members) will cause the kinds of problems you see when they are allocated on the stack: either as a local variable or with the "alloca" function.

The problem will manifest most straightforwardly if you have some function, say, foo(), with a local object of vertexGeometry, and that function is called often.

Between other functions writing to the stack (which is filled with junk data by the time foo() is called), and the compiler aggressively re-using the same stack locations for variables with different lifetimes inside foo(), you are bound to have the junk uninitialized data.

If the variable is a global, you could be getting lucky as Windows zeros out the data sections where globals reside. Similarly with using heap allocated functions. By default, malloc() does not need to return zero'd data -- but you could have been getting lucky.

I hope this helps. I am closing this MSConnect item. Feel free to reactivate it if you need more information.

Thanks,
Eric Brumer - Microsoft Visual C++ Team
Posted by Invor on 5/23/2013 at 4:44 PM
Hi Mike,
you are completely right. Fixing the constructer solves the issue, not only on my PC but also on a linux machine I got my hands on today, which showed a similiar behaviour and obviously doesn't use the VS compiler.

I'm still a bit puzzeled at how the compiler optimizations could have that kind of effect though, or why it was only caused when vertexGeometry(const char *fn) was called more than once and how seemingly random cout's could fix it... Or for that matter, I'm actually surprised that this bug hadn't caused any problems before, since older methods already made multiple calls to that constructor.
Anyway, thanks a bunch for finding and pointing out the bug in my code.
Posted by Mike Danes on 5/22/2013 at 11:22 PM
It seems you have a bug in the code, vertexGeometry(const char *fn) constructor doesn't initialize vaHandle & co. to 0 like the default constructor.
Posted by Helen [MSFT] on 5/22/2013 at 10:09 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Macy [MSFT] on 5/22/2013 at 4:54 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)