Access violation writing location 0x764f3398

What is the "FT" struct defined as? My guess is it contains a pointer which hasn't been initialized. Otherwise, assuming the API behaves as expected, it could be an alignment/packing issue, reading outside the struct.

By the way, what's with the aggressive pseudorandom number generation approach? Just use a GUID or something, please... this is like a poor man's entropy pool, my eyes are burning.

Also, a quick Google search revealed someone has already encountered the same issue:

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/33d0aaed-5299-4e3f-9692-bb844a2b81dd/

...

I should have also stated, the person I received the code from can compile and run it no problem. The code snippets I posted are not written by me, but rather already on the machine. When i try and execute the .exe it gives me the errors i pasted first and then points to the

cookie = systime.ft_struct.dwLowDateTime;

I just posted the whole function so the were would be context for that cookie line.

Also I have been to the link you posted, and the topic originator never ends up getting his problem solved. Which seemed to be the case in most of the links I found via google.

I am able to write a small program to make sure glut works, and it does no problem. But as i said when i try and run the .exe for this it breaks and points to cookie = systime.ft_struct.dwLowDateTime;.

Thanks for your reply!

I should have also stated, the person I received the code from can compile and run it no problem. The code snippets I posted are not written by me, but rather already on the machine. When i try and execute the .exe it gives me the errors i pasted first and then points to the

cookie = systime.ft_struct.dwLowDateTime;

I just posted the whole function so the were would be context for that cookie line.

Also I have been to the link you posted, and the topic originator never ends up getting his problem solved. Which seemed to be the case in most of the links I found via google.

I am able to write a small program to make sure glut works, and it does no problem. But as i said when i try and run the .exe for this it breaks and points to cookie = systime.ft_struct.dwLowDateTime;.

Thanks for your reply!

Well if it worked on his system but not yours as a compiled executable then the only possible reason (that comes to mind, anyway) is that he asserted something held true on every system but actually doesn't (this is typically low-level stuff like memory packing, how structures are stored in memory, pointer hacks, and so on). Could you post a link to the gs_support.c file, so we can actually see what's inside? A reported segmentation fault from inside an opaque library doesn't tell much beyond the fact that there is a problem.

https://subversion.assembla.com/svn/mojos/kernel/crt/src/gs_support.c

Posting from my phone but this looks like the file. I wont be able to verify until i get home tonight but it looks right. I'll drop it onto pastebin when I get home.

Pardon the double post.

Here is gs_support.c as it is on my PC.

/***
*gs_support.c - initialize the global buffer overrun security cookie
*
*       Copyright (c) Microsoft Corporation.  All rights reserved.
*
*Purpose:
*       Define __security_init_cookie, which is called at startup to initialize
*       the global buffer overrun security cookie used by the /GS compile flag.
*
*******************************************************************************/

#include <windows.h>
#include <intrin.h>

#if defined (_M_IX86) && defined (_CRTBLD) && !defined (_SYSCRT) && defined (_DEBUG)
/*
 * __security_init_cookie must be called before any exception handlers using
 * the cookie are registered.  We do a spot check for this condition in the
 * debug version of the x86 CRT.
 */

#define CHECK_FOR_LATE_COOKIE_INIT

#include <cmsgs.h>  // for _RT_COOKIE_INIT_TXT

typedef
EXCEPTION_DISPOSITION
(*PEXCEPTION_ROUTINE) (
    IN struct _EXCEPTION_RECORD *ExceptionRecord,
    IN PVOID EstablisherFrame,
    IN OUT struct _CONTEXT *ContextRecord,
    IN OUT PVOID DispatcherContext
    );

typedef struct _EXCEPTION_REGISTRATION_RECORD {
    struct _EXCEPTION_REGISTRATION_RECORD *Next;
    PEXCEPTION_ROUTINE Handler;
} EXCEPTION_REGISTRATION_RECORD;

typedef EXCEPTION_REGISTRATION_RECORD *PEXCEPTION_REGISTRATION_RECORD;

#define EXCEPTION_CHAIN_END ((struct _EXCEPTION_REGISTRATION_RECORD * POINTER_32)-1)

EXCEPTION_DISPOSITION __cdecl
_except_handler4(
    IN struct _EXCEPTION_RECORD *ExceptionRecord,
    IN PVOID EstablisherFrame,
    IN OUT struct _CONTEXT *ContextRecord,
    IN OUT PVOID DispatcherContext
    );

#endif  /* defined (_M_IX86) && defined (_CRTBLD) && !defined (_SYSCRT) && defined (_DEBUG) */

/*
 * Default value used for the global /GS security cookie, defined here and
 * in gs_cookie.c (since standalone SDK build can't use CRT's internal.h).
 */

#ifdef _WIN64
#define DEFAULT_SECURITY_COOKIE 0x00002B992DDFA232
#else  /* _WIN64 */
#define DEFAULT_SECURITY_COOKIE 0xBB40E64E
#endif  /* _WIN64 */

/*
 * The global security cookie.  This name is known to the compiler.
 */
extern UINT_PTR __security_cookie;
extern UINT_PTR __security_cookie_complement;

/*
 * Union to facilitate converting from FILETIME to unsigned __int64
 */
typedef union {
    unsigned __int64 ft_scalar;
    FILETIME ft_struct;
} FT;

/***
*__security_init_cookie(cookie) - init buffer overrun security cookie.
*
*Purpose:
*       Initialize the global buffer overrun security cookie which is used by
*       the /GS compile switch to detect overwrites to local array variables
*       the potentially corrupt the return address.  This routine is called
*       at EXE/DLL startup.
*
*Entry:
*
*Exit:
*
*Exceptions:
*
*******************************************************************************/

void __cdecl __security_init_cookie(void)
{
    UINT_PTR cookie;
    FT systime={0};
    LARGE_INTEGER perfctr;

    /*
     * Do nothing if the global cookie has already been initialized.  On x86,
     * reinitialize the cookie if it has been previously initialized to a
     * value with the high word 0x0000.  Some versions of Windows will init
     * the cookie in the loader, but using an older mechanism which forced the
     * high word to zero.
     */

    if (__security_cookie != DEFAULT_SECURITY_COOKIE
#if defined (_X86_)
        && (__security_cookie & 0xFFFF0000) != 0
#endif  /* defined (_X86_) */
       )
    {
        __security_cookie_complement = ~__security_cookie;
        return;
    }


    /*
     * Initialize the global cookie with an unpredictable value which is
     * different for each module in a process.  Combine a number of sources
     * of randomness.
     */

    GetSystemTimeAsFileTime(&systime.ft_struct);
#if defined (_WIN64)
    cookie = systime.ft_scalar;
#else  /* defined (_WIN64) */
    cookie = systime.ft_struct.dwLowDateTime;
    cookie ^= systime.ft_struct.dwHighDateTime;
#endif  /* defined (_WIN64) */

    cookie ^= GetCurrentProcessId();
    cookie ^= GetCurrentThreadId();
    cookie ^= GetTickCount();

    QueryPerformanceCounter(&perfctr);
#if defined (_WIN64)
    cookie ^= perfctr.QuadPart;
#else  /* defined (_WIN64) */
    cookie ^= perfctr.LowPart;
    cookie ^= perfctr.HighPart;
#endif  /* defined (_WIN64) */

#if defined (_WIN64)
    /*
     * On Win64, generate a cookie with the most significant word set to zero,
     * as a defense against buffer overruns involving null-terminated strings.
     * Don't do so on Win32, as it's more important to keep 32 bits of cookie.
     */
    cookie &= 0x0000FFFFffffFFFFi64;
#endif  /* defined (_WIN64) */

    /*
     * Make sure the cookie is initialized to a value that will prevent us from
     * reinitializing it if this routine is ever called twice.
     */

    if (cookie == DEFAULT_SECURITY_COOKIE)
    {
        cookie = DEFAULT_SECURITY_COOKIE + 1;
    }
#if defined (_X86_)
    else if ((cookie & 0xFFFF0000) == 0)
    {
        cookie |= ( (cookie|0x4711) << 16);
    }
#endif  /* defined (_X86_) */

    __security_cookie = cookie;
    __security_cookie_complement = ~cookie;

}

I should have also stated, the person I received the code from can compile and run it no problem. The code snippets I posted are not written by me, but rather already on the machine. When i try and execute the .exe it gives me the errors i pasted first and then points to the

cookie = systime.ft_struct.dwLowDateTime;

I just posted the whole function so the were would be context for that cookie line.

Also I have been to the link you posted, and the topic originator never ends up getting his problem solved. Which seemed to be the case in most of the links I found via google.

I am able to write a small program to make sure glut works, and it does no problem. But as i said when i try and run the .exe for this it breaks and points to cookie = systime.ft_struct.dwLowDateTime;.

Thanks for your reply!

The code is written by me... It works fine on my machine, on another programmers machine, and on 2 macs... We are still unsure as to what is causing the problem.

From the MSDN documentation:

Do not cast a pointer to a FILETIME structure to either a ULARGE_INTEGER* or __int64* value because it can cause alignment faults on 64-bit Windows.

And this is exactly what the code is doing with the union, as far as I can tell. Could this be the problem?

From the MSDN documentation:

Do not cast a pointer to a FILETIME structure to either a ULARGE_INTEGER* or __int64* value because it can cause alignment faults on 64-bit Windows.

And this is exactly what the code is doing with the union, as far as I can tell. Could this be the problem?

It doesn’t seem to be the case here.

The access violation is on the writing of “cookie” rather than the reading of the FILETIME structure. Plus previous code had already written to the FILETIME structure (though they may have done so with 2 32-bit writes).

I still want to say it is an alignment issue, but then I have to explain away the fact that it happens on an 8-byte aligned address, which is proper for 64-bit variables.

So here is my theory.

Notice that the code being executed is not the 64-bit path. 2 writes are done to create the cookie. Since it is the first write that causes the exception (and both writes are to the lower half of the 64-bit value), I can’t explain why the alignment has a problem, because that means the 8-byte-aligned address is really the starting address of “cookie”, and not the address of its upper half or something.

However it is using the 32-bit path and the original topic creator claims to be using a 64-bit compiler.

So while it seems he has the source code to the library causing trouble, he isn’t actually using that source code to rebuild the libraries and must instead be statically linking to them.

If that is the case he is linking to the wrong libraries and should link to the 64-bit versions of them. Anywhere where the headers use the _WIN64 macro will cause unhappy.

The others who had this problem reported it to be on the 64-bit path and they do seem to have alignment issues, though none of them posted the address of the exception.

To sethhope: Don’t cast that structure to unsigned __int64 *, and if that is a problem use either std::memcpy() or 2 32-bit writes to copy that value.

You should make it a high priority to fix this and get the fix out fast.

L. Spiro

To sethhope: Don’t cast that structure to unsigned __int64 *, and if that is a problem use either std::memcpy() or 2 32-bit writes to copy that value.
You should make it a high priority to fix this and get the fix out fast.

The file that is having problems, cs_support.c is not written by me... the demo project is.

I'd also like to add that if Seth sends me the .exe i can run it fine. But if I compile it on my own, i receive the aforementioned error.

What are the differences in bitness (32 vs. 64) between your and your friends system?

Are you exchanging the source only or the solution/vcproj files as well?

If only the first, make sure you have the same settings. That's what L.Spiro was on about, the project settings do not seem to match.

Just as a side note but there is no pointer cast anywhere in that code, UINT_PTR is not a pointer it is just a unsigned integer type to hold a pointer address.

Just as a side note but there is no pointer cast anywhere in that code, UINT_PTR is not a pointer it is just a unsigned integer type to hold a pointer address.

I meant the union, you are implicitly assuming the FT structure is exactly as large as an unsigned __int64 when using this union - which is what MSDN is essentially warning against - but Spiro's theory seems more plausible.

Just as a side note but there is no pointer cast anywhere in that code, UINT_PTR is not a pointer it is just a unsigned integer type to hold a pointer address.

I meant the union, you are implicitly assuming the FT structure is exactly as large as an unsigned __int64 when using this union - which is what MSDN is essentially warning against - but Spiro's theory seems more plausible.

Both machines are 64 bit. I also tested the code on a 32 bit windows and it worked fine. The code also compiled without problems on mac.

What are the differences in bitness (32 vs. 64) between your and your friends system?

Are you exchanging the source only or the solution/vcproj files as well?

If only the first, make sure you have the same settings. That's what L.Spiro was on about, the project settings do not seem to match.

He sent me solution and everything, but as a test I create a new project copy and pasted the source into new files. Then linked the correct files. Still no luck. I have also tried compiling on a netbook and a virtual machine with a different OS with absolutely 0 luck.

HOLY CRAP I GOT IT. For some reason linking libglu32.a was causing the problems!

10+ hours of troubleshooting and it was that simple!

Just a note but this is Microsoft's code (if the header didn't give it away) that forms part of the CRT (C runtime). This particular feature is a fairly basic mechanism for attempting to detect buffer overflows that have written over the return value on the stack. By placing a cookie before the return address and then comparing a saved cookie with the global copy before returning, the runtime can tell whether the return address may have been modified by an overflow, either accidentally or maliciously.

If you want disable it, just make sure the /GS switch isn't set. I'd advise against this though as it's most likely that the problem is in your own code or that of some library you're using, not the runtime's.

Either posting a copy of the faulty executable or better still, the source, would be helpful.

Edit: Site went down during posting, not having much luck tonight. Glad to hear you've got it sorted one way or another.