New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unhandled exception at 0x77c22d37 in glsldb.exe: 0xC0000005: Access violation reading location 0x0ebf41f4. #22

Open
andrealexandrewangliu opened this Issue Feb 25, 2014 · 2 comments

Comments

Projects
None yet
2 participants
@andrealexandrewangliu

andrealexandrewangliu commented Feb 25, 2014

When using glsldb on windows I've achieved an unhandled exception when debugging one of my projects:

Unhandled exception at 0x77c22d37 in glsldb.exe: 0xC0000005: Access violation reading location 0x0ebf41f4.

I'm using on windows 7, Visual Studio 2010 professional and QT 4.8.5. Not sure if the errors occur because i'm using wrong versions...

trimmed callstack with a few '...' to shorten it:

    ntdll.dll!77c22d37()    
    [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] 
    ntdll.dll!77c22ce8()    
    kernel32.dll!7541c3c4()     
    msvcr100.dll!free(void * pBlock)
    glsldb.exe!003885af()   
    glsldb.exe!0037c09a()   
    glsldb.exe!003cca37()   
    QtCored4.dll!QMetaObject::metacall(QObject * object, QMetaObject::Call cl, int idx, void * * argv)  Line 246
    ...
    QtGuid4.dll!QtWndProc(HWND__ * hwnd, unsigned int message, unsigned int wParam, long lParam)  Line 1709 + 0xc bytes
    user32.dll!75e5c4e7()   
    ...
    user32.dll!75e5cc70()   
    QtCored4.dll!QEventDispatcherWin32::processEvents(QFlags<enum QEventLoop::ProcessEventsFlag> flags)  Line 814
    ...
    QtGuid4.dll!QApplication::exec()  Line 3824
    glsldb.exe!0034f99c()   
    ntdll.dll!77c2cd10()    
    msvcr100.dll!_unlock(int locknum)  Line 375
    msvcr100.dll!_unlockexit()  Line 785 + 0x7 bytes
    msvcr100.dll!_onexit(int (void)* func)  Line 90 + 0x5 bytes

Also it seems it seems to fail to find debugging information for the generated executable. It says the binary was not built with debug information so I think it won't show me exactly where the exception ocurred.

On a side note in case anyone is having glew linker errors, I've solved mine by adding glew32.lib to the linker -> input -> additional dependencies and also added my lib folder to vc++ directories. I did introduced my glew directories but it's linker still needed to be manually added after generation. Maybe it has something with:

WARNING: Target "glsldb" requests linking to directory "C:\toolkits\libs".  Targets may link only to libraries.  CMake is dropping the item.

C:\toolkits\libs is my library direcctory

And also thanks for listening and solving the issues I posted so far.

@SirAnthony

This comment has been minimized.

Show comment
Hide comment
@SirAnthony

SirAnthony Feb 25, 2014

Member

Please, can you provide information about debugger state at time of the crash? Did it happens at certain gl call or as a result of user action? I see qt calls in trace, so it probably on debugger side, not debuglib, but I could be wrong so far.
About debug symbols. Did you selected "Debug" build type in VS or used "Release"? You must use debug build to get debug information in binary. If you'll achieve this and will not catch the crash by debugger it may be in debuglib, and as for now some freaky preparations needed to debug it.
About glew. Did your cmake could not find this? It may be related to #20 or may not. CMake will hangs if library not found, so do you add your library directory manually in the cmake files?

Member

SirAnthony commented Feb 25, 2014

Please, can you provide information about debugger state at time of the crash? Did it happens at certain gl call or as a result of user action? I see qt calls in trace, so it probably on debugger side, not debuglib, but I could be wrong so far.
About debug symbols. Did you selected "Debug" build type in VS or used "Release"? You must use debug build to get debug information in binary. If you'll achieve this and will not catch the crash by debugger it may be in debuglib, and as for now some freaky preparations needed to debug it.
About glew. Did your cmake could not find this? It may be related to #20 or may not. CMake will hangs if library not found, so do you add your library directory manually in the cmake files?

@andrealexandrewangliu

This comment has been minimized.

Show comment
Hide comment
@andrealexandrewangliu

andrealexandrewangliu Feb 25, 2014

I used Debug during cmake and Visual Studio, as for the crash it ocurred right when I tried to start debugging the target opengl application. It somehow caught the crash on free.c which is inside Visual Studio 2010 directories...

andrealexandrewangliu commented Feb 25, 2014

I used Debug during cmake and Visual Studio, as for the crash it ocurred right when I tried to start debugging the target opengl application. It somehow caught the crash on free.c which is inside Visual Studio 2010 directories...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment