GNOME Bugzilla – Bug 613783
Quartz builds hang on main_quit when threading is enabled
Last modified: 2018-08-17 13:36:32 UTC
(first reported as http://www.daa.com.au/pipermail/pygtk/2010-February/018308.html because Bugzilla is painful) On the Mac the following works fine with both X11 and Quartz: http://www.pygtk.org/pygtk2tutorial/examples/helloworld.py I then added a single line to prepare for simple threading as mentioned on: http://faq.pygtk.org/index.py?req=show&file=faq20.001.htp gobject.threads_init() This changes nothing when using X11, but on a Quartz build gtk.main_quit() no longer exits the process, only SIGKILL does! To narrow it down I also added a single line to: http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD g_thread_init(NULL); This did not exhibit the problem, so it must be something PyGTK does. Reproducible on both 10.5 with MacPorts and 10.6 with my own build. I found another mention of the problem, and a proposed fix by commenting out close(real_source->fds[0]): http://sourceforge.net/mailarchive/forum.php?thread_name=4A48FA0E.3080100%40eversholt.net&forum_name=gramps-devel This FIXED IT for me. It is confirmed by a process sample I took: 891 Thread_13713 DispatchQueue_1: com.apple.main-thread (serial) 891 start 891 Py_Main 891 PyRun_SimpleFileExFlags 891 PyRun_FileExFlags 891 Py_CompileString 891 PyEval_EvalCode 891 PyEval_EvalCodeEx 891 PyEval_EvalFrameEx 891 PyEval_EvalFrameEx 891 _wrap_gtk_main 891 g_source_destroy 891 g_source_destroy_internal 891 g_source_unref_internal 891 pygtk_main_watch_finalize 891 close$UNIX2003 891 Thread_13714 DispatchQueue_2: com.apple.libdispatch-manager (serial) 891 start_wqthread 891 _pthread_wqthread 891 _dispatch_worker_thread2 891 _dispatch_queue_invoke 891 _dispatch_mgr_invoke 891 kevent 891 Thread_13719 891 thread_start 891 _pthread_start 891 select_thread_func 891 g_poll 891 select$DARWIN_EXTSN
It's hanging in a kevent() call on thread 2; killing thread 2 (threads apply 2 kill) allows the program to finish. (gdb) info threads 4 port# 0x5403 0x95794262 in __semwait_signal () 3 port# 0x3a03 0x95785286 in select$DARWIN_EXTSN () * 2 port# 0x1503 0x9578cb42 in kevent () 1 port# 0x613 0x95772042 in close$UNIX2003 () (gdb) thread apply all bt
+ Trace 221457
Thread 4 (process 62737)
I can no longer reproduce this with a current build. Probably fixed as a side effect of http://git.gnome.org/browse/pygtk/commit/?id=f4cc1453896a891b8197a4ddbc1b7b9706c86996
pygtk is not under active development anymore and had its last code changes in 2013. Its codebase has been archived: https://gitlab.gnome.org/Archive/pygtk/commits/master PyGObject at https://gitlab.gnome.org/GNOME/pygobject is its successor. See https://pygobject.readthedocs.io/en/latest/guide/porting.html for porting info. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent version of PyGObject. Thanks!