GUI Program Hangs in GHCI

Hello, I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, "main", it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window. I found this old email regarding gtk2hs: http://web.archiveorange.com/archive/v/nDNOvMeDATtTGn026lbI I recompiled the program to use -threaded but the behavior is unchanged (if the email above describes my problem then I expected the compiled version to start having issues). What else can cause the hangs I'm seeing? I'm using the GLFW-b library on hackage and the program I'm trying to run are any of the executables from the nehe-tuts package (also on hackage). To reproduce my hangs, I think you need OSX (I didn't test this on windows or linux), and then type the following: {{{ mkdir -p ~/tmp/test cd ~/tmp/test cabal update cabal-dev install-deps nehe-tuts cabal unpack nehe-tuts cabal-dev ghci nehe-tuts-0.2.3/lesson01.hs *Main> main }}} Doing a force quit on ghci gives me a stack trace via the OSX crash reporting system. You'll find the relevant bits from that at the end of this email. What debugging techniques do I have at my disposal for figuring out what is going wrong here? At least one person has suggested that possibly ghci and the GUI bits of glfw are competing for input and conflicting with each other. If that's the case, how could I be sure and what would I do about it? Thanks, Jason {{{ Process: ghc [48045] Path: /Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/ghc UID: 502 Thread 84d5f8 DispatchQueue 1 User stack: 47 __semwait_signal + 10 (in libSystem.B.dylib) [0x7fff8760ef8a] Kernel stack: 46 semaphore_wait_continue + 0 [0x22a88f] 1 lo_alltraps + 454 [0x2a1976] 1 i386_astintr + 47 [0x2aacb4] 1 ast_taken + 247 [0x219432] 1 bsd_ast + 806 [0x48fea8] 1 postsig + 432 [0x48cfff] 1 exit1 + 449 [0x48187a] 1 task_terminate_internal + 242 [0x22ca4d] 1 ipc_space_destroy + 177 [0x215868] 1 ipc_right_clean + 397 [0x215256] 1 mach_notify_no_senders + 75 [0x23ff7b] 1 mach_msg_send_from_kernel_proper + 90 [0x21e0cb] 1 ipc_kmsg_send + 105 [0x210a86] 1 ipc_kobject_server + 267 [0x21dbfc] 1 iokit_notify + 154 [0x284eed] 1 iokit_client_died + 85 [0x571527] 1 com.apple.GeForce 6.3.0 + 47083 [0x830867eb] 1 com.apple.GeForce 6.3.0 + 305981 [0x830c5b3d] 1 com.apple.GeForce 6.3.0 + 258633 [0x830ba249] 1 OSObject::release() const + 25 [0x506759] 1 OSObject::taggedRelease(void const*) const + 32 [0x50673e] 1 com.apple.GeForce 6.3.0 + 253194 [0x830b8d0a] 1 com.apple.GeForce 6.3.0 + 251919 [0x830b880f] 1 com.apple.NVDAResman 6.3.0 + 453556 [0x83689bb4] 1 com.apple.NVDAResman 6.3.0 + 445937 [0x83687df1] 1 com.apple.NVDAResman 6.3.0 + 302211 [0x83664c83] 1 com.apple.NVDAResman 6.3.0 + 249957 [0x83658065] 1 com.apple.NVDAResman 6.3.0 + 112888 [0x836368f8] 1 com.apple.NVDAResman 6.3.0 + 111718 [0x83636466] 1 com.apple.nvidia.nv50hal 6.3.0 + 623157 [0x83e1a235] 1 com.apple.nvidia.nv50hal 6.3.0 + 605845 [0x83e15e95] 1 com.apple.nvidia.nv50hal 6.3.0 + 606056 [0x83e15f68] Thread 84d67e DispatchQueue 2 User stack: 46 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff875edfc5] 46 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff875ee128] 46 _dispatch_worker_thread2 + 252 (in libSystem.B.dylib) [0x7fff875ee7fe] 46 _dispatch_queue_invoke + 185 (in libSystem.B.dylib) [0x7fff875eecd4] 46 kevent + 10 (in libSystem.B.dylib) [0x7fff875ed12a] Kernel stack: 46 kevent + 97 [0x47a681] Thread 84d5f9 User stack: 46 kevent64 + 10 (in libSystem.B.dylib) [0x7fff87687512] Kernel stack: 46 kevent + 97 [0x47a681] Thread 84d5fa User stack: 46 ??? [0x10681d9e8] 38 ??? [0x10a60403b] 37 CGLFlushDrawable + 67 (in OpenGL) [0x7fff819d3261] 37 gldFinish + 874 (in GeForceGLDriver) [0x2000d728a] 37 glcNoop + 1072 (in OpenGL) [0x7fff819d491c] 37 CGSFlushSurfaceWithOptions + 396 (in CoreGraphics) [0x7fff88fb81f9] 37 _CGSFlushSurfaceInline + 210 (in CoreGraphics) [0x7fff88fb848c] 37 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff875d429a] 1 glfwSwapBuffers + 69 (in libglfw.dylib) [0x1036f6ba5] 1 _glfwPlatformPollEvents + 132 (in libglfw.dylib) [0x1036f26c4] 1 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155 (in AppKit) [0x7fff88135751] 1 _DPSNextEvent + 103 (in AppKit) [0x7fff88135ba5] 8 ??? [0x109fc6d03] 8 glFlush_Exec + 133 (in GLEngine) [0x11c5b7150] 8 gldUpdateDispatch + 13841 (in GeForceGLDriver) [0x2000d6711] 8 IOConnectCallMethod + 325 (in IOKit) [0x7fff81ae3328] 8 io_connect_method + 490 (in IOKit) [0x7fff81b26ad2] 8 mach_msg_trap + 10 (in libSystem.B.dylib) [0x7fff875d429a] Kernel stack: 32 ipc_mqueue_receive_continue + 0 [0x210d84] 12 lo64_mach_scall + 77 [0x2a255d] 12 thread_setuserstack + 405 [0x295c17] 8 mach_msg_overwrite_trap + 274 [0x216f84] 8 ipc_kmsg_send + 105 [0x210a86] 8 ipc_kobject_server + 244 [0x21dbe5] 8 iokit_server_routine + 4669 [0x286610] 8 is_io_connect_method + 467 [0x56e2b3] 8 IOUserClient::externalMethod(unsigned int, IOExternalMethodArguments*, IOExternalMethodDispatch*, OSObject*, void*) + 909 [0x56d9ff] 8 shim_io_connect_method_scalarI_structureO + 455 [0x56d160] 8 com.apple.GeForce 6.3.0 + 49337 [0x830870b9] 8 com.apple.GeForce 6.3.0 + 310514 [0x830c6cf2] 8 com.apple.GeForce 6.3.0 + 64383 [0x8308ab7f] 8 IOLockSleep + 39 [0x53633c] 8 lck_mtx_sleep + 87 [0x221d42] 8 thread_block + 33 [0x227654] 8 thread_block_reason + 331 [0x2275c6] 8 thread_dispatch + 1966 [0x227327] 8 machine_switch_context + 659 [0x2a9adb] 4 mach_msg_overwrite_trap + 586 [0x2170bc] 4 ipc_mqueue_receive + 89 [0x211dc4] 4 thread_block + 33 [0x227654] 4 thread_block_reason + 309 [0x2275b0] 4 thread_go + 1961 [0x22698c] 4 thread_setrun + 1360 [0x225bba] 4 machine_idle + 239 [0x2ad0f5] 1 call_continuation + 28 [0x2a179c] 1 idle_thread + 58 [0x22812e] 1 thread_run + 118 [0x22743b] 1 thread_dispatch + 1347 [0x2270bc] 1 ml_set_interrupts_enabled + 47 [0x2a45e3] 1 lo_allintrs + 302 [0x2a1c2e] 1 interrupt + 182 [0x2ab419] 1 lapic_interrupt + 108 [0x2b32b2] 1 mp_kdp_exit + 860 [0x2b4506] 1 sync_iss_to_iks + 124 [0x2aabf6] Thread 84d623 User stack: 46 __semwait_signal + 10 (in libSystem.B.dylib) [0x7fff8760ef8a] Kernel stack: 46 semaphore_wait_continue + 0 [0x22a88f] }}}

On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit
Hello,
I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, "main", it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window.
I found this old email regarding gtk2hs: http://web.archiveorange.com/archive/v/nDNOvMeDATtTGn026lbI
I recompiled the program to use -threaded but the behavior is unchanged (if the email above describes my problem then I expected the compiled version to start having issues).
On second though, I think this *IS* a threading issue. Depending on where I add either forkIO or forkOS in main the compiled program either behaves the same as it does in ghci or it segfaults. I don't know how to fix it, but I suspect that I have to do something like what is described here: http://www.cocoabuilder.com/archive/cocoa/292830-nstimer-not-working-in-mult... I think the issue is that when I run the GUI code one a thread that isn't the original thread then I need to explicitly call that threads run loop. The above link points at this bit of documentation and I probably need to read it to develop a better understanding: http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/Multi... Jason

On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit
Hello,
I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, "main", it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window.
I don't know if this is the same issue, but it sounds like it at first glance: http://www.haskell.org/pipermail/haskell-cafe/2011-May/092029.html

On Sun, Jul 3, 2011 at 8:31 PM, Alexander Solla
On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit
wrote: Hello,
I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, "main", it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window.
I don't know if this is the same issue, but it sounds like it at first glance: http://www.haskell.org/pipermail/haskell-cafe/2011-May/092029.html
Heh. Yes, good memory! That's a link to an email I wrote in response to Conal. I'm looking into the issues that Conal mentions there. So far I've discovered that there is a bug in the Objective-C part of glfw when it inits threads[1]. Fixing that bug makes it so that I can use forkIO in the compiled version of my program but I still have the bad behavior in ghci. I think the remaining bit is that OSX (and probably windows too) makes it very hard to run your event loop on a thread other than your original thread[2]. I'm now wondering if the threading model in GHC even gives me enough control to handle this situation correctly. Jason [1] https://sourceforge.net/tracker/?func=detail&aid=3352963&group_id=72569&atid=534938 [2] http://www.cocoabuilder.com/archive/cocoa/205803-event-loop-in-secondary-thr...

On Sun, Jul 3, 2011 at 9:06 PM, Jason Dagit
On Sun, Jul 3, 2011 at 8:31 PM, Alexander Solla
wrote: On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit
wrote: Hello,
I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, "main", it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window.
I don't know if this is the same issue, but it sounds like it at first glance: http://www.haskell.org/pipermail/haskell-cafe/2011-May/092029.html
Heh. Yes, good memory! That's a link to an email I wrote in response to Conal. I'm looking into the issues that Conal mentions there.
So far I've discovered that there is a bug in the Objective-C part of glfw when it inits threads[1]. Fixing that bug makes it so that I can use forkIO in the compiled version of my program but I still have the bad behavior in ghci. I think the remaining bit is that OSX (and probably windows too) makes it very hard to run your event loop on a thread other than your original thread[2]. I'm now wondering if the threading model in GHC even gives me enough control to handle this situation correctly.
My test was incorrect. Even with that fix I still can't use the threaded RTS in the compiled version. I think I understand the issue now and I'm looking for a solution in a different thread (pun intended?). Jason
participants (2)
-
Alexander Solla
-
Jason Dagit