🔒 Locked

_lock_file access violation

Started by Rarge Apr 28, 2011 at 11:34 PM 5 replies 6.6k views

Original Post

Apr 28, 2011 at 11:34 PM

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?

SiCrane

Apr 29, 2011 at 1:24 AM

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.

Rarge

Apr 29, 2011 at 2:04 AM

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!

Rarge

Apr 29, 2011 at 2:23 PM

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.

Evil Steve

Apr 29, 2011 at 3:28 PM

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.

Rarge

Apr 29, 2011 at 5:46 PM

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.

DanielWilkins

Nov 12, 2011 at 9:42 AM

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!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.