Memory change on function return

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

Recommended Posts

I have a very hard to find bug in one of my routines. An array of byte objects is becoming currupted when a member function (of the same class containing the array) exits. The array memory pointer does not change, but the values of the array indices become "garbled". It seems like I would need to be accessing out-of-bounds memory in order for this to happen. But it happens when a function ends. Within the last line of the function, the data is fine, but as soon as the code stream goes back to where it was called, it turns into a mess. Is there any information that may help me find the reason for this? Any clue related to the data scrambling when the function exits? Would the problem definitely be in the function? Or anywhere before the function was called? Unfortunately, this function calls several other functions within a loop, so even knowing it was happening in it's scope wouldn't help much. Here's what I'm meaning when I say it scrambles on function-exit:
VOID Object::FindBug()
{
DoSomething();
DoSomeOtherThing(); // breakpoint shows Object::Array is fine
int useless_code_breakpoint = 1; // Object::Array is fine
}
.. another module ..
{
Instance->FindBug(); // breakpoint, Instance->Array is fine
int another_useless = 1; // Instance->Array is scrambled
}


If anyone can give me a hint, it would make my day.

Share on other sites

What type is Object::Array? What is the definition of Object? What are the actual functions doing? What function is the array created in? What is the binary data in the array before and after it becomes corrupted?

From what you've told us, it sounds like your array is on the stack, rather than the heap (and is disappearing when it goes out of scope). But without more details I can't confirm it.

And I think I've told you before: std::vector instead of raw arrays. Please.

Share on other sites
Quote:
 Original post by Andrew RussellWhat type is Object::Array? What is the definition of Object? What are the actual functions doing? What function is the array created in? What is the binary data in the array before and after it becomes corrupted?

BYTE's. It's a world map class, but it's definition is a bit more complex than the problem. The array is created and filled with correct values in the object constructor. The array starts out with 0's and 1's, but becomes filled with garbage. In ascii values, it appears to be a repeating set of symbols: îþîþîþîþîþîþîþîþîþî.

Quote:

Trust me when I say you wouldn't want to help me if I had to post the entire map implementation. I cannot narrow it down to any specific point, other than that function returning. The function routine doesn't mess with the array data. It doesn't even access it. It's unrelated, yet that's where it happens.

Quote:
 From what you've told us, it sounds like your array is on the stack, rather than the heap (and is disappearing when it goes out of scope). But without more details I can't confirm it.

The array is not initialized in the problem area, and the memory is definitely on the heap.

Quote:
 And I think I've told you before: std::vector instead of raw arrays. Please.

I'm not sure why you're requesting the use of vectors here. This is totally unrelated. The array is not the problem. It's just the victom.

I appreciate the try though.

Share on other sites
It was a typo. Address-of symbol on an abject when sending it to be read from file. The object had it's own handler for file IO, but I prevented this by passing the address. Pretty dumb mistake. It ended up trying to load a large amount of data into a small 32 bits of memory.

Sorry for whining (my first ever GD bug post!). Thanks again.

Share on other sites
Quote:
Original post by Jiia
Quote:
 And I think I've told you before: std::vector instead of raw arrays. Please.

I'm not sure why you're requesting the use of vectors here. This is totally unrelated. The array is not the problem. It's just the victom.

Because std::vector is a known container, thus people know how it works and that it is indeed bug free. You might well assert that its not your code causing the problem, however we cant trust this fact without knowing the code and lets face it, the values are being stomped apon thus there must be a problem your code somewhere, be it with the array class or with something which access it is, but right now we are flying blind into a load of unknown code.

You can assert that your code is bug free as much as you like, the fact remains we cant trust your code as we dont know it.

Share on other sites
Quote:
 Original post by _the_phantom_You might well assert that its not your code causing the problem, ...

How in the world would I think that my code is not at fault? It's all my code. Nothing else could be at fault.

Quote:
 ..however we cant trust this fact without knowing the code and lets face it, the values are being stomped apon thus there must be a problem your code somewhere, be it with the array class or with something which access it is, but right now we are flying blind into a load of unknown code.

I'm the one flying. I was just looking for directions. I didn't expect someone to point out the problem. That's why I didn't throw you blindly into a load of unknown code. The details I provided wouldn't have helped anyone much to lead me to the problem. I just didn't know what else would be relevant. Now that I know the answer, I'm still not sure what code I could have posted that would have helped. Other than the exact typo line and the header line where that file IO handler is declared. But these things were totally unrelated to the symptoms. I apologize for wasting your time, but it was not done so carelessly. Still, I should have just stayed at the problem on my own instead of seeking help.

Quote:
 You can assert that your code is bug free as much as you like, the fact remains we cant trust your code as we dont know it.

I have no idea where you got the idea that I asserted such facts.

Share on other sites
[looksaround] um. so what has been accomplished in this post?

Share on other sites
Quote:
 Original post by skillfreak[looksaround] um. so what has been accomplished in this post?

You're making fun of my post? [grin]

Share on other sites
you caught me. +) ::andy tips his hat::

Share on other sites
Quote:
Original post by Jiia
Quote:
 Original post by Andrew RussellWhat type is Object::Array? What is the definition of Object? What are the actual functions doing? What function is the array created in? What is the binary data in the array before and after it becomes corrupted?

BYTE's. It's a world map class, but it's definition is a bit more complex than the problem. The array is created and filled with correct values in the object constructor. The array starts out with 0's and 1's, but becomes filled with garbage. In ascii values, it appears to be a repeating set of symbols: îþîþîþîþîþîþîþîþîþî.

I asked for "binary" for a reason *grumble*.

Anyway... I decoded your "îþîþîþîþîþîþîþîþîþ" string. It becomes FEEEFEEE in hexadecimal. A little research tells us that "FEEEFEEE" is "Used by Microsoft's C++ compiler to mark the storage area of a deleted class in debug mode".

In other words, your array, or whatever your array was living in, was deleted.

Where it was deleted is something we'd need to see real code to tell you.

Share on other sites
Quote:
 Original post by Andrew RussellAnyway... I decoded your "îþîþîþîþîþîþîþîþîþ" string. It becomes FEEEFEEE in hexadecimal. A little research tells us that "FEEEFEEE" is "Used by Microsoft's C++ compiler to mark the storage area of a deleted class in debug mode".

I was aware of the 0xfeefee code, but I assumed it was only used for pointer addresses. Probably because I only use hex-display on address data. It's interesting to know that it's used everywhere. That could be pretty handy. By the way, the îþ sequence is repeated in the watch display several hundred thousand times. So many times, it chokes the PC to hover it with the mouse.

Quote:
 In other words, your array, or whatever your array was living in, was deleted.

It wasn't being deleted, manually. Or at least there were no delete's being called in the area where everything shot to hell. Overwriting so much unknown memory must have driven the stack to delete it for me. I can't see how else it could have happened, since the address value remained constant.

Quote:
 Where it was deleted is something we'd need to see real code to tell you.

It was masked feefee on the function exiting. It would be extremely difficult (if not impossible) to know exactly what happened, as it depends on what memory was stored where. Nasty typo. I had to resort to commenting out blocks of code just to find it.

Thanks for explaining the extra details.

Share on other sites
Quote:
 Original post by Jiiaquote]It was masked feefee on the function exiting. It would be extremely difficult (if not impossible) to know exactly what happened, as it depends on what memory was stored where. Nasty typo. I had to resort to commenting out blocks of code just to find it.Thanks for explaining the extra details.
So, just to make things clear, have you solved the problem now?

I'll bet that someone would like to know what the cause was. It's good to post your findings so that others may learn from your mistakes. Not to mention people might have tips for how to avoid the problem happening again.

Share on other sites
Quote:
 Original post by iMalcSo, just to make things clear, have you solved the problem now?I'll bet that someone would like to know what the cause was. It's good to post your findings so that others may learn from your mistakes. Not to mention people might have tips for how to avoid the problem happening again.

I thought I did explain it..? Ctrl+F, type "It was a typo."

The problem was passing an object to be loaded from file, but passing it with it's address. The object was saved correctly, as a large amount of data, but the typo requested that all of that data be loaded into a memory location that was only 32-bits. The 32-bits was filled up and the rest of the data flooded unknown memory. I was unlucky that it didn't cause a crash.

Share on other sites
I don't know what compiler you are using but Visual Studio has a compile option /FAcs that produces a combined source and assembler file corresponding to each object file. The interesting thing about these is that the assembler generated for the end of each block contains the calls to any destructors of automatic objects declared in the block. This would tell you exactly what code is in the frame for corrupting your memory.

Share on other sites
As does observing the call stack on an activated data breakpoint. The whole moral of the story is to not necro 6-year old threads.

Share on other sites

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

This topic is now closed to further replies.