eglMakeCurrent stability issues in VS2010 debug

This topic contains 1 reply, has 1 voice, and was last updated by  Tachikoma 7 years, 1 month ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #30308

    Tachikoma
    Member

    Hello,

    I have a rather peculiar problem with the SDK in Visual Studio 2010 Express. When I start a debugging session in Visual Studio, something throws an exception at eglMakeCurrent. The typical error message is shown below:

    Quote:
    Unhandled exception at 0x032c520b in sideways.exe: 0xC0000005: Access violation reading location 0x03577000.

    Occasionally when I do a complete project rebuild, no exception is thrown, but that doesn’t always work. When I run the project without debugging, everything works fine. There is no clear pattern to this behaviour. The problem occurs in v2.07.27.0484 of the SDK and also in the older versions.

    Another problem: My application occasionally crashes when glDrawArrays() is called in the manner shown below:

    Code:
    typedef struct

       {

       float X, Y, Z;

       } vector3f;

    vector3f List[64];

    /*…. fill List array with coords ….*/

    glEnableClientState(GL_VERTEX_ARRAY);

    glBindBuffer(GL_ARRAY_BUFFER, 0);

    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);

    glVertexPointer(3, GL_FLOAT, sizeof(vector3f), &List[0].X);

    glDrawArrays(GL_POINTS, 0, 64);

    …but not always! It’s another one of those strange situations. When I use glDrawArrays somewhere else in the code (on a much shorter list), the above works, it renders all 64 points. When the above code is the only instance that uses glDrawArrays, my application crashes rather badly. Stranger still, if I reduce the Count parameter from 64 to about 14, the rendering works fine. If I increase the Count to 15 and beyond, all hell breaks loose.

    Any suggestions on tackling this issue?

    Tachikoma2010-10-11 06:21:42

    #34398

    Tachikoma
    Member

    I’m really sorry for bumping this topic, but the eglMakeCurrent situation is getting rather unpleasant. 😛 I get an unhandled access violation exception in my project only when I run my executable in debugging mode.

    When I compile and run the release build without debugging (Visual C++ 2010 Express) – all good. When I run the debug build (that retains debug symbols), again without debugging – all good. But when the debug build is started in debugging mode, something trips the exception.

    The entire project is written in C, and I’m using the OpenGL ES 1.1 emulator, v2.07.27.0484. According to the debugger, the exception seems to originate somewhere in eglMakeCurrent (libEGL.dll library), which is part of emulator. So naturally, this problem occurs way before any rendering code is called.

    To make the situation even more frustrating, the problem is sporadic. Sometimes when I clean and rebuild the project, everything works fine in debugging mode. Then, if I edit a source file, build, and start in debugging mode… bam… access violation at eglMakeCurrent blah blah.

    First I figured maybe something in my project is causing the trouble. So I started to divide and conquer the project. I commented out big blocks of code. Unfortunately, this did not get me closer to the cause. Sometimes culling code made the problem go away, other times the problem persisted.

    And the crazy thing is, on occasions the problem went away when I commented out rendering code that is never called prior eglMakeCurrent! I seriously can’t see a pattern to this madness.

    Are there third party tools I could use to track down issues like these? Has any of you experienced compatibility issues with OpenGL ES and Visual C++ 2010 binaries? I never experienced this with Visual C++ 2008 Express.

    EDIT:

    Woopsey! I figured out what the problem was. I was loading the wrong version of libEGL.dll, somehow I managed to overlook updating the lib when I installed the newer version of SDK.

    At any rate, please disregard my posts.Tachikoma2010-11-05 05:13:41

Viewing 2 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic.