Jump to content

  • Log In with Google      Sign In   
  • Create Account

Access violation writing location 0x764f3398


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
17 replies to this topic

#1 heartofalion   Members   -  Reputation: 107

Like
0Likes
Like

Posted 14 April 2013 - 10:16 PM

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!


Edited by heartofalion, 15 April 2013 - 05:52 AM.


Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 9282

Like
0Likes
Like

Posted 14 April 2013 - 10:51 PM

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/

 

...


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 heartofalion   Members   -  Reputation: 107

Like
0Likes
Like

Posted 15 April 2013 - 05:50 AM

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!


Edited by heartofalion, 15 April 2013 - 05:51 AM.


#4 Bacterius   Crossbones+   -  Reputation: 9282

Like
0Likes
Like

Posted 15 April 2013 - 06:29 AM

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.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#5 heartofalion   Members   -  Reputation: 107

Like
0Likes
Like

Posted 15 April 2013 - 08:30 AM

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.


Edited by heartofalion, 15 April 2013 - 11:30 AM.


#6 heartofalion   Members   -  Reputation: 107

Like
0Likes
Like

Posted 15 April 2013 - 04:04 PM

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;

}


Edited by heartofalion, 15 April 2013 - 04:05 PM.


#7 sethhope   Members   -  Reputation: 462

Like
0Likes
Like

Posted 15 April 2013 - 04:47 PM

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)

#8 Bacterius   Crossbones+   -  Reputation: 9282

Like
0Likes
Like

Posted 15 April 2013 - 05:12 PM

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?


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#9 L. Spiro   Crossbones+   -  Reputation: 14267

Like
0Likes
Like

Posted 15 April 2013 - 06:58 PM

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


Edited by L. Spiro, 16 April 2013 - 05:56 PM.

It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#10 sethhope   Members   -  Reputation: 462

Like
0Likes
Like

Posted 15 April 2013 - 07:05 PM

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)

#11 heartofalion   Members   -  Reputation: 107

Like
0Likes
Like

Posted 15 April 2013 - 09:44 PM

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.



#12 Endurion   Crossbones+   -  Reputation: 3685

Like
0Likes
Like

Posted 16 April 2013 - 12:39 AM

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.


Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

#13 NightCreature83   Crossbones+   -  Reputation: 3033

Like
0Likes
Like

Posted 16 April 2013 - 06:02 AM

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.


Edited by NightCreature83, 16 April 2013 - 06:03 AM.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#14 Bacterius   Crossbones+   -  Reputation: 9282

Like
0Likes
Like

Posted 16 April 2013 - 06:08 AM

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.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#15 sethhope   Members   -  Reputation: 462

Like
0Likes
Like

Posted 16 April 2013 - 01:36 PM

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.


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

#16 heartofalion   Members   -  Reputation: 107

Like
0Likes
Like

Posted 16 April 2013 - 09:50 PM

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.



#17 heartofalion   Members   -  Reputation: 107

Like
0Likes
Like

Posted 16 April 2013 - 10:12 PM

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

 

10+ hours of troubleshooting and it was that simple!



#18 Indifferent   Members   -  Reputation: 576

Like
0Likes
Like

Posted 16 April 2013 - 10:42 PM

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.


Edited by Indifferent, 16 April 2013 - 10:43 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS