I've written a small program using the gtk2hs library and it crashes at unpredictable times with X windows errors like the one below. I looked for the messages online and found various people talking about buggy gtk libraries but no clear solutions. I don't know a lot about X windows or what these errors mean. Has anyone else had this problem or know what to do? The program is a simple implementation of the Conway Life game. It doesn't have very much going on except that the main window is an animation showing the evolution of the game. I tried running with the --sync option as it said and you get an almost immediate error like "Xlib: unexpected async reply (sequence 0x1652)!". Even these are not predictable and often come after several screen updates. I'm using the Gtk.timeoutAddFull function to do the animation. Note that the error_code, request_code, etc.. changes with each crash. It's as though it picks a random error code each time. I've compiled with both ghc 6.4.2 and 6.6.1 and gtk2hs 0.9.12 and 0.9.12.1. I've tried various combinations of -O flags as well. Same problem every time. A typical crash message ----------------------------------------------------------------------- The program 'hlh' received an X Window System error. This probably reflects a bug in the program. The error was 'BadDrawable (invalid Pixmap or Window parameter)'. (Details: serial 236321 error_code 9 request_code 62 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) --------------------------------- Never miss a thing. Make Yahoo your homepage.
On Tue, Nov 20, 2007 at 03:18:03PM -0800, Gregory Propf wrote:
I've written a small program using the gtk2hs library and it crashes at unpredictable times with X windows errors like the one below. I looked for the messages online and found various people talking about buggy gtk libraries but no clear solutions. I don't know a lot about X windows or what these errors mean. Has anyone else had this problem or know what to do? The program is a simple implementation of the Conway Life game. It doesn't have very much going on except that the main window is an animation showing the evolution of the game. I tried running with the --sync option as it said and you get an almost immediate error like "Xlib: unexpected async reply (sequence 0x1652)!". Even these are not predictable and often come after several screen updates. I'm using the Gtk.timeoutAddFull function to do the animation. Note that the error_code, request_code, etc.. changes with each crash. It's as though it picks a random error code each time. I've compiled with both ghc 6.4.2 and 6.6.1 and gtk2hs 0.9.12 and 0.9.12.1. I've tried various combinations of -O flags as well. Same problem every time.
A typical crash message ----------------------------------------------------------------------- The program 'hlh' received an X Window System error. This probably reflects a bug in the program. The error was 'BadDrawable (invalid Pixmap or Window parameter)'. (Details: serial 236321 error_code 9 request_code 62 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
What happens if you run 'gdb ./hlh', 'b gdk_x_error', 'run --sync' ? (Are the backtraces consistent?) Stefan
On Tue, 2007-11-20 at 15:18 -0800, Gregory Propf wrote:
I'm using the Gtk.timeoutAddFull function to do the animation.
Are you using the threaded rts? Are you linking the program with -threaded? Are you doing the drawing directly in the timeout function or just invalidating the window/widget and letting it get redrawn? See for example the cairo clock demo which animates the hands of the clock every second: timeoutAdd (widgetQueueDraw window >> return True) 1000 In general it is much better to only ever draw to a window or widget during that widget's expose event. Duncan
OK, it actually DOES appear related to the -threaded flag. I was sure I had removed that and still seen the problem but now it seems that taking that out is indeed the fix. Using the -O2 flag is OK. I guess it's some syncronization problem when using the threaded RTS. Which is a shame because it does seem faster that way on my dual core machine. I guess I need to learn about how threading works in ghc. Duncan Coutts <duncan.coutts@worc.ox.ac.uk> wrote: On Tue, 2007-11-20 at 15:18 -0800, Gregory Propf wrote:
I'm using the Gtk.timeoutAddFull function to do the animation.
Are you using the threaded rts? Are you linking the program with -threaded? Are you doing the drawing directly in the timeout function or just invalidating the window/widget and letting it get redrawn? See for example the cairo clock demo which animates the hands of the clock every second: timeoutAdd (widgetQueueDraw window >> return True) 1000 In general it is much better to only ever draw to a window or widget during that widget's expose event. Duncan --------------------------------- Get easy, one-click access to your favorites. Make Yahoo! your homepage.
participants (3)
-
Duncan Coutts -
Gregory Propf -
Stefan O'Rear