Jump to content
  • Advertisement
Sign in to follow this  
SymLinked

Strange crash when deleting class instance that contains an unsigned _int64.

This topic is 2798 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

My FileStream class contains a position integer which is of the type unsigned _int64.
I can new it and delete it (alone) just fine, but if I wrap it inside another class and try to new/delete that class, I get a memory crash inside CRT.

Is this an alignment issue or something else? I can make it happen right at the start of main, or even before any static variables are initialized. Inside the FileStream constructor, the integer is set to 0. If I take that away, it silently works again. I'm running a debug build and doing CRT memory corruption checks which alarms me right after I initialize the integer, so I guess it means I'm getting memory corruption.

Oh, and if I switch the unsigned _int64 to an unsigned int, the problem goes away too. But that's hardly a solution...

So basically, what works:

* Remove the initialization of the integer in the class constructor.
* Remove the integer member variable from the class altogether.
* Remove a std::string member variable from the class.

Any ideas? Thanks!

[Edited by - SymLinked on October 22, 2010 1:48:00 AM]

Share this post


Link to post
Share on other sites
Advertisement
Sounds like memory corruption. Some part of your program is writing to the wrong memory, and this subtle change is affecting the memory layout of the resulting code, causing it to break.

Do you have lots of stuff happening before main()? The static intialisation order fiasco might be in play too.

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off
Sounds like memory corruption. Some part of your program is writing to the wrong memory, and this subtle change is affecting the memory layout of the resulting code, causing it to break.

Do you have lots of stuff happening before main()? The static intialisation order fiasco might be in play too.


Thanks for your answer rip-off. Yeah, I do have lots of stuff happening before main (), and most likely your guess on the static initialisation order fiasco is pretty close to what the problem is too.

I'll have to research alternatives for that. Thank you!

Share this post


Link to post
Share on other sites
When you say "memory crash", is that an exception, a hard breakpoint, a certain instruction that generates an access violation, etc.? Is it in the same place every time? Does it happen only on new, delete, or both? What does the call stack look like?

Any additional information can help us narrow down the problem :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Zipster
When you say "memory crash", is that an exception, a hard breakpoint, a certain instruction that generates an access violation, etc.? Is it in the same place every time? Does it happen only on new, delete, or both? What does the call stack look like?

Any additional information can help us narrow down the problem :)


Access violation when delete is called, but _CrtCheckMemory () does return false after I initialize the integer, but not before - so it's definatly corruption.. I just can't find where it happens.

Some info:
* There are no static initializations happening before a FileStream object is created (which has the integer as a member variable).
* It doesn't matter if it's a unsigned _int64 or if there are two unsigned ints, it corrupts anyway. I guess it's logical.

Isn't there a memory debugger which can tell if I make overlapping memory allocations? CRT doesn't seem to care. I'm not working with arrays or anything, just objects and their member variables.

Share this post


Link to post
Share on other sites
You can run your program with Application Verifier. One of it's options is to automatically insert a guard page after every memory allocation so that if you write past the end of allocated memory it triggers a memory exception.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
You can run your program with Application Verifier. One of it's options is to automatically insert a guard page after every memory allocation so that if you write past the end of allocated memory it triggers a memory exception.


Isn't that what CRT does? I'll try it, in any case! Thanks.

Share this post


Link to post
Share on other sites
Quote:
First-chance exception at 0x0040191e in Client.exe: 0xC0000005: Access violation writing location 0x02b5b010.

VERIFIER STOP 00000013: pid 0xC04: First chance access violation for current stack trace.

02B5B010 : Invalid address causing the exception.
0040191E : Code address executing the invalid access.
0012FB84 : Exception record.
0012FBA0 : Context record.


It basically says I'm writing outside my memory location?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!