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
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