Window not opening under certain conditions in --release builds

[ghost]

I've run into a very strange issue using this shard. I first thought it was a compiler bug and still somewhat suspect that it may be. However, I was recommended to create an issue here.

The contents of this issue are here: crystal-lang/crystal#7012

[ysbaddaden]

The window does appear but is closed immediately, while the loop continues running. Using window.update instead of renderer.present doesn't trigger the bug.

Maybe LLVM's optimizations are reordering some statements, or inlines variables on the stack which triggers an issue with the SDL renderer...

[ghost]

I found that I had to use both renderer.present and window.update. Probably I'm just misusing SDL at this point.

However, you're right that this does fix it. Seems like the kind of thing that shouldn't happen...

[rymiel]

I realize this issue is 3 years old (I didn't check if any other issues reference this specific problem) but I'm pretty sure I've just encountered the same issue and after longer than I'm willing to admit of messing around and debugging, I've concluded that the GC is behind all this. I inserted a manual GC.collect in the main loop and sure enough, the window disappeared as soon as that happened. I inserted a simple window.to_unsafe to see if the pointer to the window data somehow moves but that is enough for the GC to think that the window is in use and not delete it, which means it fixed the problem (and also made me feel like the program was pulling a "Volkswagen emissions behavior" on me...)

What all this means is a simple SDL loop which uses renderer.present will never actually reference window again and the GC will think it's okay to destroy it.. removing the window of course.

I don't know enough about crystal's internals or garbage collection in general to know how to prevent this in the library itself, however just using window within the main loop (in a way that the compiler doesn't see it as dead code) seems to be a workaround for now...

Moreover, if the program isn't intensive enough to really require the GC to act, this bug won't actually arise. I do not know if the --release flag specifically triggers this behavior (since I've made all my testing compiling with release mode anyway), so I assume simple setups like the ones within the examples folder wouldn't encounter this issue as quickly

[ysbaddaden]

Thanks for the investigation! That sounds quite plausible.