Access violation writing location 0x764f3398

Started by
16 comments, last by Indifferent 11 years ago

Hello,

I am trying to run a Demo, I get the following errors. I am trying to use glut and bullet physics. The code compiles but during execution the following happens.

EDIT: Also the person who sent me the code for the demo is able to compile and run the .exe without issue. /EDIT

First-chance exception at 0x001070ae in ***: 0xC0000005: Access violation writing location 0x764f3398.
Unhandled exception at 0x77d015de in ***: 0xC0000005: Access violation writing location 0x764f3398.
First-chance exception at 0x77cf016e in ***: 0x00000000: The operation completed successfully.
Unhandled exception at 0x77d015de in ***: 0x00000000: The operation completed successfully.
First-chance exception at 0x77cf016e in ***: 0x00000000: The operation completed successfully.

Unhandled exception at 0x77d015de in ***: 0x00000000: The operation completed successfully.

It breaks and points to the following code in gs_support.c


    cookie = systime.ft_struct.dwLowDateTime;

Which is part of the following


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;

}

gs_support.c is a system created file that I did not write.

I'm using Visual Studio 10

on

Windows 7 ultimate x64

I've been beating my head against a wall so any help is appreciated!

Thanks!

Advertisement

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/

...

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

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.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

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.

I develop to expand the universe. "Live long and code strong!" - Delta_Echo (dream.in.code)

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?

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”

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

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

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 develop to expand the universe. "Live long and code strong!" - Delta_Echo (dream.in.code)

This topic is closed to new replies.

Advertisement