Random retarded SDL mixer crashes

Meatballsub · Post by **Meatballsub** » Wed Feb 20, 2008 8:43 pm

Nope, no sound effects are playing at the time that it crashes. I have tested it on multiple games and the crash seems to occur when you do one of the following:

-use a door
-run a script
-get into a random battle

The retarded thing is that it doesn't happen 100% of the time. For instance, the scripted portion of the beginning of EOTE2 ran fine until the hero went into a door and BAM it crashed.

EDIT: I just confirmed that it also crashes with Ubersetzung, but not at the same spot at least in my game. I was able to run some of a script until I opened a door before it crashed.

Should I run over my laptop with my truck and throw it in the oven?

Post by **Bob the Hamster** » Wed Feb 20, 2008 10:55 pm

Smells like memory corruption.

The frustrating thing about memory corruption is that there doesn't have to be any kind of connection between the place where the corruption occurs, and the place where the crash happens.

The memory corruption can happen, and the program can keep running fine for a while, until it happens to use some of that corrupted memory, and then things go crazy :(

Meatballsub · Post by **Meatballsub** » Thu Feb 21, 2008 3:25 pm

So basically there's nothing I can do but wait and see if it stops happening like it did the last time it started doing this?

Post by **Bob the Hamster** » Thu Feb 21, 2008 4:06 pm

Meatballsub wrote:So basically there's nothing I can do but wait and see if it stops happening like it did the last time it started doing this? :???:

Well, it is possible to deduce (or at least narrow down) where the memory corruption occurs. Now, you said the crashes usually occur when you:

-use a door
-run a script
-get into a random battle

The most likely culprit is some event in common that happened *before* each of these. My first guess would be using the menu, since I already distrust the menu code because of <a href="http://gilgamesh.hamsterrepublic.com/cg ... d=577">bug 577</a>. Now something I have noticed about bug 577 is that it never crashes on the first menu, it crashes on a submenu that you get to from the first menu. So my guess is that something about that first menu is corrupting memory.

So try this for me. Try using as many doors as you can without ever looking at your menu. Try running as many scripts as you can without looking at your menu, try getting into as many battles without looking at yor menu. If it never crashes, then maybe your crash might also be caused by the same menu-related memory corruption in <a href="http://gilgamesh.hamsterrepublic.com/cg ... d=577">bug 577</a>

EDIT: I just enabled additional error-checking in the WIP nightlies. Try out <a href="http://hamsterrepublic.com/ohrrpgce/nig ... sdl.zip</a> and let me know what happens. I expect the crash will still happen, but I expect it will be a lot less random.

Meatballsub · Post by **Meatballsub** » Sat Feb 23, 2008 10:29 pm

The only difference I can tell so far with this copy you have linked is that instead of crashing and showing an error message it just crashes with no error message.

Also, it doesn't seem to last much longer when you go without opening the menu. Maybe a slight difference, but nothing extravagant.

I hate that this is putting a halt on the testing of my game

Post by **Bob the Hamster** » Sun Feb 24, 2008 8:36 pm

Hmmm... well, if it still crashes if you never go into the menu, then it can't be the same as bug 577.

Let's try something even trickier... Read <a href="http://gilgamesh.hamsterrepublic.com/wi ... dows">read this wiki article</a>. If you can get a backtrace it might help.

EDIT: and use this build <a href="http://hamsterrepublic.com/ohrrpgce/nig ... bug.zip</a>. TeeEmCee talked me out of leaving debugging enable for all nightylies, because it is rather slow.

Meatballsub · Post by **Meatballsub** » Wed Feb 27, 2008 4:58 am

You are not going to beleive this but...

This is what happened. I install Mingw and downloaded that debug build of ohrrpgce. I ran it with mingw running in the background and it...will...not...crash for anything. Sweet!

I think to myself, hey, maybe everything is back to normal now. I try to run my game from voxhumana without Mingw in the background and it crashes within five seconds. I then try to run it from the debug version without Mingw running in the background, and it also crashes within five seconds. I then go back and run Mingw and the debug version of the ohr and I cannot get it to crash.

All I can say is...WTF mate?

Post by **Bob the Hamster** » Wed Feb 27, 2008 4:31 pm

You, my friend, have what is known as a <a href="http://en.wikipedia.org/wiki/Heisenbug">Heisenbug</a>, a bug which (according the the principles of quantum cats) changes when you try to investigate it.

I'll try to think of another angle of attack, and get back to you...

EDIT: okay, I split the -debug build. there is now a -debug-exx build which has extra error detection, just like the one you have tried already. And the new -debug build just adds debug symbols, and nothing else, so it is more likely to behave like the regular nightly. So re-download <a href="http://hamsterrepublic.com/ohrrpgce/nig ... bug.zip</a> and try it out, and let me know if it crashes under gdb

Meatballsub · Post by **Meatballsub** » Thu Feb 28, 2008 12:21 am

No dice on getting it to crash. It seems to work just fine during all of the previous errorneous items.

Post by **Bob the Hamster** » Thu Feb 28, 2008 4:21 pm

Hmmm....

You said in your original post that this crash happens the same no matter which game you play. Is that still true?

EDIT: Oh, another thing, just so we can rule out a hardware problem, can you run the <a href="http://www.memtest.org/">memtest86+</a> memory tester? You download an ISO file, burn it to a CD, and then you boot from the CD and let the memory tester run for a while.

(if your CD burning software doesn't support ISO images, you can use <a href="http://infrarecorder.sourceforge.net/">InfraRecorder</a>)

Meatballsub · Post by **Meatballsub** » Thu Feb 28, 2008 7:58 pm

Yep, still crashes when I try to play any game (tested Bloodlust, EOTE 2, Vikings, and my game).

Memtest ran successfully with zero errors. Do you think I should try and roll back windows update updates and see if that changes anything? It would be a pain but I guess I could do it if needed.

Post by **Bob the Hamster** » Thu Feb 28, 2008 10:03 pm

Meatballsub wrote:Yep, still crashes when I try to play any game (tested Bloodlust, EOTE 2, Vikings, and my game).

Memtest ran successfully with zero errors. Do you think I should try and roll back windows update updates and see if that changes anything? It would be a pain but I guess I could do it if needed.

No, I wouldn't bother with a rollback...

Here is something else to try: What happens if you start up Windows in Safe Mode, and then try to play a game? That could tell us if this is caused by interference from some other running program.

Meatballsub · Post by **Meatballsub** » Thu Jun 05, 2008 9:48 pm

Sorry I haven't responded to this in a while. I don't think I ever tried it in safe mode, but I will the next time I have issues.

I bought a new laptop three or four days ago and I still occasionally have the same issues discussed here. If I can get it to happen again several times in a row, I will try it in safe mode and see if that makes a difference.

Meatballsub · Post by **Meatballsub** » Fri Jun 13, 2008 8:29 pm

I had a string of crashes happen to me during a script, and also when flipping through music loaded in my game on custom. I decided to boot up and safe mode and see if it made a difference. Not a single crash, but then again, that sometimes happens even out of safe mode. I hate unneccessary background programs, so i've disabled most from running via msconfig, except for those that the system needs to run.

Post by **Bob the Hamster** » Fri Jun 13, 2008 9:25 pm

Meatballsub wrote:I had a string of crashes happen to me during a script, and also when flipping through music loaded in my game on custom. I decided to boot up and safe mode and see if it made a difference. Not a single crash, but then again, that sometimes happens even out of safe mode. I hate unneccessary background programs, so i've disabled most from running via msconfig, except for those that the system needs to run.

The fact that you are using a new computer makes a memory problem unlikely.

Are you using the latest nightly? There were some memory corruption bugs fixed recently.

If you are using the latest nightly, and you are still seeing crashes, you may have discovered an unreported memory corruption bug.