_lock_file access violation

Started by
5 comments, last by DanielWilkins 12 years, 5 months ago
Hello, I am having issues with an error when I close my program in debug mode.

I do not have any problems whilst the program is running, but when I close it the debugger takes to to a function _lock_file() in _file.c which I presume is the compiler's code because I have never seen it before.

The error it gives me is:
Unhandled exception at 0x77838db9 in Engine.exe: 0xC0000005: Access violation writing location 0x00000014.


and it brings me to this function:
void __cdecl _lock_file (
FILE *pf
)
{
/*
* The way the FILE (pointed to by pf) is locked depends on whether
* it is part of _iob[] or not
*/
if ( (pf >= _iob) && (pf <= (&_iob[_IOB_ENTRIES-1])) )
{
/*
* FILE lies in _iob[] so the lock lies in _locktable[].
*/
_lock( _STREAM_LOCKS + (int)(pf - _iob) );
/* We set _IOLOCKED to indicate we locked the stream */
pf->_flag |= _IOLOCKED;
}
else
/*
* Not part of _iob[]. Therefore, *pf is a _FILEX and the
* lock field of the struct is an initialized critical
* section.
*/
EnterCriticalSection( &(((_FILEX *)pf)->lock) );
}


Now this error only occurs when I try to close the program via the window. If I close it by pressing the X on the console, I don't get this error?
Advertisement
Use the stack view in the debugger to identify which functions called _lock_file(). Eventually you should see something that's your own code. Check to make sure that in your code all function parameters are kosher, etc.

Use the stack view in the debugger to identify which functions called _lock_file(). Eventually you should see something that's your own code. Check to make sure that in your code all function parameters are kosher, etc.


Ahh, It's something to do with SDL_GL_SwapBuffers();! I'll look into it some more, I never knew about the stack view, it's helpful! Thanks!
After many hours of frustration I seem to have worked out why SDL_GL_SwapBuffers() was causing this.

I was adding the .lib files like so:
#pragma comment(lib, "SDL.lib")
#pragma comment(lib, "SDLmain.lib")
#pragma comment(lib, "glut32.lib")
#pragma comment(lib, "glu32.lib")
#pragma comment(lib, "OpenGL32.lib")


Removing the above code and adding the lib files to additional dependencies in the project properties under linker input fixed the problem, I have a clue why though.
FYI: Access violations reading an address very near 0x00000000 almost always means you have a null pointer. In this case, you're reading from a null pointer, 0x14 (20 bytes) from the start of it. I'd guess that your FILE pointer was null for whatever reason.

FYI: Access violations reading an address very near 0x00000000 almost always means you have a null pointer. In this case, you're reading from a null pointer, 0x14 (20 bytes) from the start of it. I'd guess that your FILE pointer was null for whatever reason.


It was weird though because if I removed anything in my actual code to do with files it would still happen and it would only do it when I exited the program. I don't know why removing the pragma comments fixed it but at least it is fixed :) Thanks though, it's useful to know.
Sorry to dig up an old topic but the OP's solution fixed my error. Thanks for being specific about the problem so other could benefit.

Now I did a bit more digging as I like the nature of #pragma comment rather than having them in the project linker and I figured out that SDL.lib and SDLmain.lib only protest if they are included with a #pragma comment.

Does anyone know why this is? Is this a bug I should report so the developers can fix it?

So again to recap, I moved just SDL.lib and SDLmain.lib into the project settings linker rather than linking them via #pragma comment and it now works perfectly.

Cheers!

This topic is closed to new replies.

Advertisement