GNOME Bugzilla – Bug 59305
Hang on URL/MIME part open with --enable-threads
Last modified: 2009-08-15 18:40:50 UTC
Balsa built with --enable-threads will hang when a highlighted URL is opened, or "view part with..." is selected for an URL. The hang occurs within gnome_execute_async(), which is in turn called by gnome_execute_shell() and gnome_url_show(). On closer inspection, it looks like there is a problem with the "exec" functions. For instance, process calling exec...("gnome-moz-remote") will never return, even though gnome-moz-remote exits immediately. When the same command is started via system(), everything looks OK, though. The patch that will be attached shows a possible workaround, and should also pinpoint the problem. It contains modified versions of functions ingnome-exec.c and gnome-url.c from gnome-libs.
Created attachment 921 [details] [review] Work-around
"for an URL" in the 2nd line of the description should of course be replaced with "for a message part" or similar...
Created attachment 927 [details] [review] Proposed patch
Created attachment 928 [details] [review] The previous patch was not reliable. This one is better.
Ah. That [referring to patch] makes a lot of sense, of course. Although I guess the gnome_exec... functions ought do something like this, really. Or isn't libgnome expected to be thread safe? Anyhow, let me just remind you that similar logic is probably needed for gnome_execute_shell(), too. Also, perhaps these routines should be moved to libbalsa, as they are needed in other files for one of my own hacks at least.
Your comments are valid. BTW, we have discussed this last night GMT at balsa-list, and this is not quite good approach: the handlers are added each time URL is clicked. The handlers should be registered only once. A new patch is needed.
Created attachment 929 [details] [review] Alternative approach: Add fork handler in threads_init()
How about simply [please consider my last patch]? The beauty of this is that _nothing_ else has to be changed. I wasn't able to find any side effects, either, but I may have missed something. And now for the bad news: This patch does not resolve the problem for me, neither does the previous one. In fact, I can't see any indications that the fork handler is called at all for the gnome_... functions. I tried debugging a bit to figure out what was going on, but wasn't very successful as gdb got rather confused...
Created attachment 932 [details] [review] Alternative approach - I
Your patch seemed ok apart from trying to unlock mutt without being sure it is locked. What about the attached version? Does it solve your problem?
One should also lock and unlock mailbox_lock mutex. It would be helpful to detect which mutex hangs balsa.
No, the last patch doesn't help, either. After paying around a bit with some other code that will execute an external app (my HMTL converter, refer to Bug 58915) I'm convinced that the fork handlers are NOT called on normal fork(). They are, however, if I replace fork()+exec...() with system(). I'll also attach some debug trace that shows where the hang occurs, although I'm not sure if it's very helpful.
Created attachment 933 [details] Debug trace from hanging process
I attach simple testing program. The funny thing is, it is sufficient to create void thread to create this hang. IMO, gnome_exec_async has a serious bug. I am going to forward it to gnome-libs team.
Created attachment 941 [details] url-test.c - testing program
This is believed to be solved in current CVS (2001-08-25) (at least I cannot reproduce it any more). Confirmation would be apprectiated.
*** Bug 59391 has been marked as a duplicate of this bug. ***
Works for me now.
I am happy to close this report :-)