1

I encountered a strange problem while coding a OpenGl program with C++ under Visual Studio Express 2010.
I use: Windows 7 64bit, OpenGl 4.x
My partner uses: Windows XP 32bit, Visual Studio Express 2010, OpenGl 2.x

Until now we just drawed vertexes for our models and it works fine at both systems (I know, I know: deprecated but we're still beginners). Now he included a lib to import 3d-meshes and make an animation. For him everything works fine but I get

First-chance exception at 0x0055f838 in Ant Simulation.exe: 0xC0000005: Access violation reading location 0x00bb0000.
Unhandled exception at 0x0055f838 in Ant Simulation.exe: 0xC0000005: Access violation reading location 0x00bb0000.

With the debugger I traced the problem to the line

glDrawArrays(GL_QUADS,0,n_data);

I tried to catch the code, but nothing is triggered. Strange enough, yesterday I could go over this line 2-3 times with the debugger until it crashed, today it crashes directly. I checked yesterday that n_data is the same every time. If I execute the *.exe in Windows, it crashes (error code below). When my partner sends me his *.exe, it usually doesn't work, but 1 time I could start it. I reproduced the error on an other windows. We tried on Linux 64bit and there is no problem. I tried running it in compatibility mode, but the problem keeps the same (still crashes).

I searched around and found this:
https://blogs.msdn.com/b/debugger/archive/2010/05/12/visual-studio-debugger-fails-to-catch-unhandled-exception-for-a-windows-form-or-wpf-application.aspx?Redirected=true

Not sure if I understood this correctly. There is an exception I cannot catch but which will kill the application - but why haven't other system a problem with this exception?

I tried to solve it the way described in the link but it seems in VS Express I have not the menu to throw the first-chance exceptions. I'll try to get VS 2012 but nevertheless I'd like to know: Is this an enirely Windows thing or could there by a problem with my code which causes the crash (as suggested in one of the comments in the link)? I would also highly appreciate an explication for what is actually going on...

The error I get when I run the *.exe:

Problem Event Name: APPCRASH

Application Name: Ant Simulation.exe
Application Version: 0.0.0.0

Application Timestamp: 511d99a3

Fault Module Name: StackHash_0a9e

Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000

Exception Code: c0000005

Exception Offset: 0037f278

OS Version: 6.1.7601.2.1.0.256.48

Locale ID: 1031

Additional Information 1: 0a9e

Additional Information 2: 0a9e372d3b4ad19135b953a78882e789

Additional Information 3: 0a9e

Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
Andarin
  • 799
  • 1
  • 8
  • 17

1 Answers1

4

A "first chance exception" in Windows isn't a C++ exception, it means the runtime system has detected illegal behaviour of your program, such as dereferencing an invalid pointer. In fact, "Access violation reading location 0x00bb0000" suggests very much that this is what's happening.

Dereferencing an invalid pointer doesn't necessarily cause the same behaviour on different systems or even on different runs on the same machine: see questions like C code crashes in Windows, but not in Linux for more information on that. In this case, the fault seems to be occurring inside the GL implementation, but this is probably caused by earlier application code giving it bad information.

Check that all the enabled vertex arrays have at least n_data elements. (Be particularly careful to make sure they don't have only n_data - 1 elements, and that n_data holds the value you expected.) You should also check that any pointers you have previously passed to GL functions were valid. There's a lot more GL state to check too, but that would be my first guess.

Community
  • 1
  • 1
Dan Hulme
  • 14,779
  • 3
  • 46
  • 95
  • Thanks for the fast response. I'm looking for it. If I find it, I'll give feedback. So far, when I only load a static image it works which would be an indicator that your guess is right. – Andarin Feb 15 '13 at 16:40
  • -1 for assuming that it's OpenGL's fault and not the OPs. This looks like a clear heap overflow going on, and it's MUCH more likely to be in the OPs code than in the code-reviewed and relatively stable OpenGL libraries – SecurityMatt Feb 15 '13 at 18:24
  • I'm not saying it's OpenGL's fault, nor even the specific GL implementation. It's commonplace for violating OpenGL preconditions (which is the application's fault) to result in a crash inside an OpenGL call. Passing an invalid pointer to a GL function is the most obvious way to achieve this, but there are subtler ones. I'll edit the answer to make this more clear. – Dan Hulme Feb 15 '13 at 18:53
  • @SecurityMatt BTW, as a GPU driver author, I find your characterisation of GL implementations as "code-reviewed and relatively stable" a little naïve. – Dan Hulme Feb 15 '13 at 19:01
  • @DanHulme: It's commonplace in all code for it to break if you breach one of its preconditions. I'm not saying OpenGL is free of bugs. I'm just saying that you need to always start with the assumption that it's YOUR bug until you have proved beyond all doubt that it's someone else's, and so blaming OpenGL with so little information from the OP seems premature. – SecurityMatt Feb 15 '13 at 19:45
  • Just to say that I'm still alive. I "solved" my problem by not using the library function and writing the thing myself. I tracked down the error-prone code but I don't have time until Friday (hand in of the project) to really dive in the problem and understand what doesn't work. Saturday I'll look on it and, if you were right, of course accept your answer to give you the credit. – Andarin Feb 20 '13 at 12:25