Hi Bertram, hi Colin, On May 7, 2009, at 21:19, Bertram Felgenhauer wrote:
> Colin McQuillan wrote: >> I'm using GHC 6.10.2 with Gtk2Hs from darcs. Very occasionally Yi >> gives this error and exits: [..] >> I've tried to narrow this down to a test case. Run the attached >> program with: >> make >> ./gcgc --sync >> Resize the window or hit a few keys, it seems to error quite quickly. >> (Unfortunately, without --sync this test program doesn't seem to >> crash.) > > This happens during garbage collection: > > ./a,out --sync +RTS -Sstderr > Alloc Copied Live GC GC TOT TOT Page Flts > bytes bytes bytes user elap user elap > expose done > [I added this message at the end of the onExpose callback] > 13484 3000 3628 0.00 0.00 0.02 0.36 0 > 0 (Gen: 1) > Xlib: unexpected async reply (sequence 0x102)! > [note: this is xlib without xcb, which treats this as a warning > instead > of crashing] > 4372 3996 4628 0.00 0.00 0.02 0.69 0 > 0 (Gen: 1) > > So what breaks it is that the drawing context is destroyed from a > finalizer while the main loop is waiting for X events to process -- > the > finalizer (necessarily) runs in a different thread. > > Indeed strace shows the main thread receiving some data from the X > server that's obviously the reply to a request sent by a different > thread a split-second earlier. > > It's not a new bug. This also happens when using the threaded runtime > with ghc 6.6.1 and gtk2hs 0.9.12.2. Indeed, this seems to be an instance of http://hackage.haskell.org/trac/gtk2hs/ticket/1112 Yes, while Gtk2Hs <0.10.2 and ghc >6.10.2 won't work together, any other combination has the same behaviour for finalizers: They are called from the Haskell mutator that will run in different OS threads than the Gtk loop runs. So I hope that your diagnostics is right. > So it appears that gtk2hs' finalizers actually have to synchronize > with the main thread, because Xlib is not thread-safe. I'm not sure > how > to do that. GHC 6.10.2 now calls finalizers during GC rather than creating Haskell threads that eventually call the finalizers. In any case, we cannot directly call the finalizers of Gtk+ (like object_destroy) since these might trigger callbacks, leading to run-time errors about the Haskell run-time being entered during GC. A solution to all of these problems has to fulfill the following: - does not run finalizers during GC - only runs finalizers from the Gtk+ main thread We could thus, each time the garbage collector calls finalizer f on the pointer p, call g_idle_add(f,p) which would then run this finalizer off the main loop of Glib/Gtk+. However, if the main loop runs while the garbage collector runs, we might be back at square one where the Haskell run-time is entered unsafely. I'll ask on the ghc mailing list about this. > I'm not sure whether this explains the BadAllocs you see in yi though; > they could also be caused by infrequent garbage collections and actual > resource exhaustion on the X server side. Let's assume this for a now. Thanks for the good bug report, Axel. > Bertram > > ---------------------------------------------------------------------- > -------- > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! > Your > production scanning environment may not be a perfect world - but > thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW > KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Gtk2hs-devel mailing list > Gtk2hs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
