• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Matias Goldberg

Memory Corruption: OMG Panic attack!

11 posts in this topic

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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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 ([size=2]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[/size]).
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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...
0

Share this post


Link to post
Share on other sites
My worst one ([i]took a few of us about a month to fix - maybe $10000 in salaries![/i]) 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!
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='Koobazaur' timestamp='1327302135' post='4905355']
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...
[/quote]

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

Share this post


Link to post
Share on other sites
[quote name='Koobazaur' timestamp='1327302135' post='4905355']
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!
[/quote]
^^ 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.
0

Share this post


Link to post
Share on other sites
[quote name='Luckless' timestamp='1327333012' post='4905464']
[quote name='Koobazaur' timestamp='1327302135' post='4905355']
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...
[/quote]

Depending on the game, I would consider fixing a bug like that, and then re-implementing the 'features' as part of the game play.
[/quote]
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.
0

Share this post


Link to post
Share on other sites
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 [img]http://public.gamedev.net//public/style_emoticons/default/blink.png[/img]

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0