Diagnosing Monomer crash

Learn
#1

I’ve been trying to do a UI addition to a couple of my projects and have been dealing with periodic crashing so I decided to go back to the start to see if I could pinpoint when the crashing starts. Starting fresh from the monomer-starter I made the following change that simply adds a forkIO around the Monomer IO and within a minute it segmentation faults.

-- git diff 
+ import Control.Concurrent
- startApp model handleEvent buildUI config
+ forkIO $ startApp model handleEvent buildUI config
+ threadDelay maxBound
  • Is this a Monomer bug that I should make an issue?
  • What tools can I use to find out more?
  • Is it expected that async errors would have a different effect from a non-primary thread?
1 Like
#2

Try forkOS instead of forkIO.

I think monomer uses SDL2, and I don’t think SDL2 likes being switched around OS threads (which forkIO allows for since it spawns an M:N green thread).

iirc I had this same issue running my SDL2 games in ghci. forkOS was the fix.

5 Likes
#3

Thank you! From the ForkOS documentation:

forkOS creates a bound thread, which is necessary if you need to call foreign (non-Haskell) libraries that make use of thread-local state

2 Likes
#4

Notice that in sdl2 (the C library, not even the Haskell bindings) event polling, rendering, etc… should be done in the same thread. sdl2 official documentation advice to always run in the main thread, so even if you forkOS you might run into problems.

1 Like
#5

I have had no trouble running in a bound thread in ghci fwiw!

The only “trouble” was GC pauses that weren’t present in the final executable. I think it’s because ghci has an additional working set in the heap (all the loaded code & state I guess?). Luckily the non-moving collector fixed that. Thank goodness for -xn!