Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash in al_get_joystick_state, Windows #38

SimonN opened this issue Feb 2, 2016 · 2 comments

Crash in al_get_joystick_state, Windows #38

SimonN opened this issue Feb 2, 2016 · 2 comments


Copy link

SimonN commented Feb 2, 2016

Reports by several people: Nepster's crash, reported on Lix version 0.2.11, Windows cross-build, crashed after (skipping ahead, then framestepping back).

Clam's crash:

Lix version:  0.1.40 (Windows cross-build too)
    64.37 Access Violation
    64.37 0x6CB5A6B0 in al_convert_bitmap_data
0x7716DFA1 in RtlpUnWaitCriticalSection
0x6CB5E8E7 in al_get_joystick_state
0x6CB5EB3E in al_get_joystick_state
0x6CB05ED8 in al_lock_bitmap_region

SimonN: okay, how do you watch this replay to make it crash? Immediately hit turbo and never disable turbo?
Clam: yes; you may have to move the cursor around as well

Facts: I never call al_get_joystick_state from the Lix code in either version. I wasn't able to repro the crash on Linux.

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?

SimonN added a commit that referenced this issue Mar 1, 2016
I'm trying to attack #38 by cleaning up in VRAM often.
Destroying RAM Torbits calls al_destory_bitmap for VRAM.
Copy link
Owner Author

SimonN commented Mar 1, 2016

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.

Copy link
Owner Author

SimonN commented Apr 11, 2016

Superseded by #61 (Implement manual memory management for savestates). I'd like to improve the performance over running the GC almost every frame. Running the GC almost every frame happens when holding a key to go back in time.

If you experience the Joystick crash #38 still, open a fresh issue.

@SimonN SimonN closed this as completed Apr 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant