Something is erasing my program while it's running (oh wait oops)

Like in the 80's, writing games for the Commodore 64... Where they kept the memory for the program at a location shortly after where they kept the screen memory... So if you forgot to bounds-check the coordinates of the little guy you had running around on the screen, you could run him right off the bottom.

Where he'd start overwriting random bits of memory. Until eventually he walked right over your source code. Which was being interpreted. Until, of course, the guy caught up with the current execution point.

At which point, you hoped you had spent 10 minutes saving a copy of your code recently. Because listing your source you'd find it speckled with random special characters and changed values. Tire tracks from that little guy.

And you learned that the first thing you do when implementing that joystick routine is to also implement bounds checking.

She freaks out a bit, I freak out a lot. We're both worried that something really bad happened, then I realized that DEAD is actually a number in hex. I look through the data segment, and I see a AD DE in there (yay Intel byte reversal!).

I check through the code a bit, and even though it looks like the data segment is being initialized properly, it's still reading from the Program Segment Prefix. So, I find the Wikipedia article on the PSP and see that address 05h in the PSP has a cross-segment jump to CP/M compatibility code.

But, there's nothing at address DEAD (at least, nothing sensible). So I go searching through the DOSBox code for that string, and I find these lines:

    // far call to interrupt 0x21 - faked for bill & ted
    // lets hope nobody really uses this address
    sSave(sPSP,cpm_entry,RealMake(0xDEAD,0xFFFF));

I can only imagine the problems that can manifest when you're dealing directly with hardware, and don't have access to commented source code.

Change variable attributes from ‘private’ to ‘public’ at random (actual other thing that has worked)...

Changing stuff at random (without having any idea why you're doing it and without keeping track of what you've already done) isn't a very productive debugging strategy - it's more like an act of desperation. At least use the scientific method:

- Make a hypothesis about what might happen if you change X.

- Observe and record what actually happens.

- Think about why this could be, and then think about what experiment you could do next to get another step closer to the answer.

If you have a hard time coming up with a reasonable hypothesis, it might help to learn more about the system. In this case, reading the linker documentation to find out what the various options do could be more productive than just making random changes to the linker script.

Needless to say that was a bugger to debug. We didn't believe what was happening until we literally saw a jar disappear before our eyes.

Sun fixed the problem pretty quickly!

I don't remember the exact code, but it was something like:

  function clear_dir($dir) {
    $contents = scandir($dir); // returns array of directory contents

    foreach($dir => $file) {
      if(is_dir($file)) {
        clear_dir($file);
      }
      else {
        unlink($file);
      }
    }
  }

Anyway, so the code looks like it should work. The problem is the scandir function result includes . and ..

So my little function would see .., recognise it as a directory, and recursively call itself on the parent of the directory I wanted to empty. I lost a fair few files before I realised what was happening. Luckily I had back ups, as this was before I started using SCMs.