Jump to content

  • Log In with Google      Sign In   
  • Create Account

Memory Corruption: OMG Panic attack!


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
11 replies to this topic

#1 Matias Goldberg   Crossbones+   -  Reputation: 3471

Posted 21 January 2012 - 05:47 PM

You're relatively close to deadline, run the program, all's ok. Suddenly crash (hopefully it was a crash). Turns out it's while freeing memory. You realize you have memory corruption.

OMG Panick Attack!!! you remove a piece of code that seems troubling, and everything's fine. Put it back. Corruption. Your heart starts beating faster than normal.

Is it that code?? Or is it that it's just triggering a deeper problem somewhere else completely unrelated???? Is it a recent bug or something you've introduced like, 3 months ago????

I've just had one. Luckily the troublesome code was actually the root cause of the problem. All is well now. I came here just to relieve my pain. I needed to get it out of my system by talking here with other programmers that will understand me. Stupid mistake by the way (like most of bugs).

Don't you hate that feeling? Memory corruption is one of computer bugs that creeps me most. All the other I can bust them pretty quickly; but corruptions are the hardest to fine. Sometimes I wish there were some kind of All mighty monitoring software that would raise an exception each time you get out of a single byte. May be enabling DEP would help? Yes, I know about Purify, tried the trial a month ago when I thought I had one. Didn't convince me at all.

Thanks for listenting. It's therapeutic :)
I feel better now

Sponsor:

#2 MajorTom   Members   -  Reputation: 715

Posted 21 January 2012 - 05:53 PM

We once had a funny bug when an integer was assigned the value 0, but when checking the value against 0 on the next instruction, the comparison would fail.
We were all rather confused about what on earth was going on. Turned out to be memory corruption somewhere along the line. That day made me question the very fundamentals of programming. I enjoy those days.

Saving the world, one semi-colon at a time.


#3 Matias Goldberg   Crossbones+   -  Reputation: 3471

Posted 21 January 2012 - 07:40 PM

By next instruction you mean exactly the next instruction after the assignment, or that it was the next time you touched that integer again?

#4 Servant of the Lord   Crossbones+   -  Reputation: 19685

Posted 21 January 2012 - 07:57 PM

Towards the end of my first real game project, an error started popping up where all of the ships would draw fine, but the 2nd or 3rd ship would appear as the game's logo... which was an entirely different game state and had already been freed by that point. That was my first real experience with the "how in the world can I even begin to track this down?"-type corrupted memory errors.

I've since that time learned that whenever something is going "impossibly" wrong in my code, no matter how much it looks like the compiler's fault, it's always my fault in the end. Only once, in six years of programming, has it really been not my fault (or the fault of 3rd party libraries).. and that one time, it still wasn't the compilers' fault (it was an unrelated videocard driver I had installed a month beforehand that was defective in certain conditions and caused multiple programs to break, not just mine, and it just happened that I hadn't worked on that code for a few weeks since the video card driver was installed, so my program magically "broke" despite the last time I worked on it, it was functioning fine. Took me three or four days of aggravation wondering what had happened).
It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#5 Luckless   Crossbones+   -  Reputation: 1807

Posted 21 January 2012 - 08:59 PM

I find the largest source of issues like that is either misunderstanding documentation about something, or having something documented completely wrong. Usually the misunderstanding, but when it is simply wrong can make for some interesting adventures.

One time I had access to a rather large cluster owned by a research group. Massive distributed thing with sites all over the globe, and running this cool light weight custom OS linking everything together. I got drawn into a project to provide some wrappers for the boiler plate stuff required by apps to run on the custom cluster. Basically priority, load balancing, security spec flagging, etc. Stuff so the high level system could know how the program was suppose to run, and how it could handle stuff.

It has been so many years that I can't remember which way it was. But basically there was a disagreement between docs and implementation on the topic of passing a set of values as 1/0 or 1/-1. Pretty sure docs said 1/0, and it was implemented as 1/-1 for an efficiency reason that I can't recall anymore.

We ran a simple test program, a port of a system wide load balance and data passing. Should have taken 10 minutes for a scheduled down time. We managed to critically lock the system for over about two weeks. (The 'failsafe' systems kept storing the error, and carrying it through on a system boot.) Needless to say myself and my project lead were not looked fondly upon at first. After the source of the problem was traced back to "Not Us" they lightened up a bit, but one of the engineers responsible for the original systems got a broken nose.

Moral of the story: Check your docs, and even geeks can still carry a mean left hook.
Old Username: Talroth
If your signature on a web forum takes up more space than your average post, then you are doing things wrong.

#6 Koobazaur   Members   -  Reputation: 691

Posted 23 January 2012 - 01:02 AM

Memory breakpoints! It's one of those features of VS you never really use, but when you do use it, you thank god it exists!

As for my funky stories, In my current game I suddenly encountered a bug where, after about 10 seconds, the main ambient light would start to flicker for a second or two, before completely going dark. And then, the gravity would invert.

Which is peculiar, considering ambient light calculation is hardcoded into the shader at the time, and we had no way of modifying gravity on the fly...

Postmortem: one must die -  Political narrative-adventure game playing an Agent of Death who must take ONE life that could change the fate of a conflict-torn Nation

 

Check out my DevBlog for news on the next title!


#7 Hodgman   Moderators   -  Reputation: 30437

Posted 23 January 2012 - 02:37 AM

My worst one (took a few of us about a month to fix - maybe $10000 in salaries!) occurred about a month before gold -- turns out a render-target wasn't allocated enough RAM, so it was overflowing into random other resources, such as vertex buffers, causing random graphical corruptions, at random points in time, but this depended on the order that assets were constructed, which depended on background loading scheduling and the order that you progressed through the levels.

Memory breakpoints were a huge red-herring too, because a co-processor was responsible for the write to RAM, not the CPU!

#8 Eelco   Members   -  Reputation: 301

Posted 23 January 2012 - 04:38 AM

I can not really empathize with these issues, never having written big projects in low level languages. At most mid-sided ones, and then in modern low level languages like D.

Nowadays, if I use a low level language, its always as an extension module to another project in a high level language. That also seems to work wonders for me; I rarely do resource management within the low level language, and the code-paths within the unsafe context tend to be short and easy to debug, and usually have a reference implementation in the high-level language as well, as a fallback to isolate problems

I must say I have a hard time coming up with a project id say makes sense to implement in, say, pure C++. In all my projects, 90% of time is spent in 10% of the code, if not something more extreme.

#9 Luckless   Crossbones+   -  Reputation: 1807

Posted 23 January 2012 - 09:36 AM

Memory breakpoints! It's one of those features of VS you never really use, but when you do use it, you thank god it exists!

As for my funky stories, In my current game I suddenly encountered a bug where, after about 10 seconds, the main ambient light would start to flicker for a second or two, before completely going dark. And then, the gravity would invert.

Which is peculiar, considering ambient light calculation is hardcoded into the shader at the time, and we had no way of modifying gravity on the fly...


Depending on the game, I would consider fixing a bug like that, and then re-implementing the 'features' as part of the game play.
Old Username: Talroth
If your signature on a web forum takes up more space than your average post, then you are doing things wrong.

#10 frob   Moderators   -  Reputation: 21493

Posted 23 January 2012 - 10:01 AM

Memory breakpoints! It's one of those features of VS you never really use, but when you do use it, you thank god it exists!

^^ THIS. A thousand times.

I have felt your pain many times. And I will likely feel it again in the future.

Memory breakpoints ease the pain of memory corruptions, like Novocaine vs. a dentists drill during a root canal, or general anesthesia vs. open heart surgery.
Check out my personal indie blog at bryanwagstaff.com.

#11 Matias Goldberg   Crossbones+   -  Reputation: 3471

Posted 23 January 2012 - 12:20 PM


Memory breakpoints! It's one of those features of VS you never really use, but when you do use it, you thank god it exists!

As for my funky stories, In my current game I suddenly encountered a bug where, after about 10 seconds, the main ambient light would start to flicker for a second or two, before completely going dark. And then, the gravity would invert.

Which is peculiar, considering ambient light calculation is hardcoded into the shader at the time, and we had no way of modifying gravity on the fly...


Depending on the game, I would consider fixing a bug like that, and then re-implementing the 'features' as part of the game play.

I was thinking the same!!! That bug is really cool.

I use memory breakpoints very often. Not just for memory corruption, but also when I accidentally overwrite some value/behavior (due to wrong code path, not memory corruption) it's faster and easier than searching through the code where you manipulate that variable.

Put the variable name in MSVC's QuickWatch and add the '&' prefix. It will tell you the memory address. Copy pasting is allowed which means setting up a data/memory breakpoint is very straightforward.

Going back to the mem. corruption issue, yes they ease the pain; but there are some cases where they just aren't enough.

@Hodgman: Wow. Just wow. Speechless.

#12 Bacterius   Crossbones+   -  Reputation: 8954

Posted 29 January 2012 - 10:03 PM

Something really confusing happened to me once. I had a piece of code that didn't work. Eventually I randomly decided to put a printf("test") somewhere in the middle.

...

It worked perfectly Posted Image

Turns out the printf call prevented a memory corruption from occurring a few lines later somehow.

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





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