Dispatch of `KeyPress` event throws a `System.AccessViolationException`
AzuxirenLeadGuy opened this issue · comments
Issue description
While running a RenderWindow instance, any KeyPress event results in throwing a System.AccessViolationException.
How to reproduce
Run the example project in example/window, and press any key
Expected behaviour
The key is processed by the event successfully
Actual behaviour
An uncaught exception interrupts the program, with the following message on the console.
Press ESC key to close window
Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at SFML.Window.WindowBase.CallEventHandler(SFML.Window.Event)
at SFML.Window.WindowBase.DispatchEvents()
at window_core.SimpleWindow.Run()
at window_core.Program.Main(System.String[])
this is a serious heisenbug in SFML.Net. it cant usually be replicated while debugging but it appears in release builds.
the new ScanCode field of CSFML 2.6 wasnt accounted for in Event or KeyEvent, and inconsequentially KeyEventArgs. the total size of CSFML events is now 28 bytes. adding the field to KeyEvent and updating the size of the Event struct fixes this crash.
its also worth mentioning that this same bug may cause KeyEvent to not report correct values (i have not tested this), so fixing it will kill two birds with one stone
It might be recommended to stick to CSFML 2.5.2 until SFML.Net has been updated for 2.6
if its any consolation, this is the only problem with SFML.NET which we could find.
we patched this bug in our internal fork of SFML.NET (currently 321101d) with CSFML 2.6, and have been essentially field testing it for over a week. we have not discovered any further problems from upstream besides this one.
i've been facing this same crash on my build. As @uwaaya mentioned, addition of ScanCode and adjusting the Event size seems to fix this. can you please address and close this.
Note, that while the change has been merged into master, it doesn't mean that you can now mix the SFML.Net 2.5.x nuget packages with the CSFML 2.6.x nuget packages.
Keep the versions aligned to not run into this issue. 😉
Note, that while the change has been merged into master, it doesn't mean that you can now mix the SFML.Net 2.5.x nuget packages with the CSFML 2.6.x nuget packages.
Just to clarify, this won't happen unless there are multiple SFML.NET projects being worked on, right? If I only use the latest SFML.Net nupkg (built from the current master branch), I don't need to worry about this, right?
If you build SFML.Net yourself, then you should be okay for this issue.
It's just that there's no official SFML.Net 2.6 Nuget package yet, and people seem to be trigger happy on the update button for CSFML 😄
in our case, this actually had nothing to do with nuget. upstream changed the CSFML version, and we just ran into this issue bc we just assumed upstream wouldnt break their master branch. its no big deal though. ppl simply gotta reset to a stable tag after creating their fork, but most would not be aware of that..
this is just my thoughts, but i think it be a good idea to have a development branch for updating CSFML, right? i know its not needed most of the time, but SFML will change a lot with SFML 3 being in active development, and keeping master stable would be super helpful for anybody creating and maintaining their own forks 👀
master is the development branch. We don't provide any guarantees on stability on the master. If you want stability, it's recommended to stick with git tags. If you deem a specific commit stable enough, you can choose to stick to that commit.
Merging between some master and develop branch is more busy work than it's providing value, given the two mentioned options.
We will be adopting the branching as done in SFML and CSFML, where any fixes for SFML.Net will happen on the 2.6.x branch, while master starts targeting SFML 3. As such, since you most likely would want to stick to SFML 2 for a while longer, you can simply target 2.6.x once it has been created.