2
votes

In a project of mine i noticed the program hanging from time to time when i was scrolling in a special scrolled viewport. I condensed the problem down to a minimal programm.

When you scroll fast up and down in the scrollable area it hangs but does not throw any error messages.

By trying i found out that

onWidgetDraw drawingArea $ \(Context fp) -> withManagedPtr fp $ \p -> (`runReaderT` Cairo (castPtr p)) $ runRender $ do
   return True

is responsible for the hang. Without these two lines it works just fine. I need them though (In my project it is more than two lines but it hangs with just the two already).

I have no idea what is going on. Does anybody know how to fix this?

Code (all files on github):

{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE OverloadedLabels #-}

module NotificationCenter where

import Data.Maybe
import qualified Data.Text as Text
import Control.Monad.Trans.Reader (ReaderT(..))
import GI.Gtk as Gtk
import Graphics.Rendering.Cairo
import Graphics.Rendering.Cairo.Types (Cairo(..))
import Graphics.Rendering.Cairo.Internal (Render(..))
import GI.Cairo
import Foreign.Ptr (castPtr)

main :: IO ()
main = do
  Gtk.init Nothing
  let objsToGet = [ "main_window" , "main_bg" ]
  builder <- Gtk.builderNew
  Gtk.builderAddFromFile builder "crash.glade"

  (Just win) <- Gtk.builderGetObject builder "main_window"
  (Just bg) <- Gtk.builderGetObject builder "main_bg"

  mainWindow <- (Gtk.unsafeCastTo Gtk.Window) $ win
  drawingArea <- (Gtk.unsafeCastTo Gtk.DrawingArea) $ bg

  onWidgetDraw drawingArea $ \(Context fp) -> withManagedPtr fp $ \p -> (`runReaderT` Cairo (castPtr p)) $ runRender $ do
    return True

  onWidgetDestroy mainWindow mainQuit
  widgetShowAll mainWindow
  Gtk.main
1
Does it still crash with haskell-gi-base-0.20.5 ? It was released some days ago, and fixed some crashes I was having. You may also want to ask on gitter.im/haskell-gi/haskell-giunhammer
I did'nt try, but i created an issue on github and that got resolved, so i think it is working now.user3637541

1 Answers

0
votes

It was an issue with haskell-gi and it was fixed by the maintainer.