Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Crash in al_get_joystick_state, Windows #38
Reports by several people: Nepster's crash, reported on LF.net: Lix version 0.2.11, Windows cross-build, crashed after (skipping ahead, then framestepping back).
SimonN: okay, how do you watch this replay to make it crash? Immediately hit turbo and never disable turbo?
Facts: I never call
Even though Clam had a debugging version, there was no informative entry in the logfile. The output quoted above was everything.
Speculations: Most likely, al_lock_bitmap_region checks al_get_joystick_state for whatever obscure reason. Examine the A5.0 source. -- Otherwise, ABI mismatch? I have no clue. Maybe try with more modern versions of A5.0 or A5.1?
Maybe try to repro the crash with Ichotolot?
Icho and I have have looked into the joystick crash on Windows. This bug is very hard to trigger, we've hit it only once. Key ingredients, as Clam and Nepster have suggested, are turbo-fast-forward, then framestepping back.
When we hit the bug, instead of a crash, the screen and entire program froze. We still believe it's the same bug.
Theory: I don't run the D garbage collection (GC) during the game, only after each level. Automatic GC would kick in when RAM is scarce, which doesn't happen during play. But maybe VRAM gets scarce? This doesn't trigger the automatic GC, because RAM is not yet full. Yet somehow, we might get bad VRAM bitmaps, even though A5 always returns meaningful pointers on bitmap creation.
Therefore: From 0.2.33 on, I'm forcing the GC to run during play, whenever old savestates aren't needed anymore. GC'ing frees the savestates' RAM and VRAM. Let's see whether you can repro the crash still. When you framestep back in large jumps, holding down the button, this can make the GC run every frame. Let's see how much of a performance hit you take.