There was a bug 318891 where users reported apps hanging on g_spawn_command_line_sync. That was due to bug in some old glib2. The solution there was to use popen() which was later reverted as bug in glib2 got fixed. Unfortunately the problem is still visible with current glib 2.44.1 and with 2.45.8). My google chrome get whole UI hangt and gdb shows such backtrace: 0x00007f3b7024b19d in read () at ../sysdeps/unix/syscall-template.S:84 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) bt #0 0x00007f3b7024b19d in read () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f3b7453030a in read (__nbytes=8, __buf=0x7ffcdd5cd620, __fd=219) at /usr/include/bits/unistd.h:44 #2 read_ints (fd=219, buf=buf@entry=0x7ffcdd5cd620, n_ints_in_buf=n_ints_in_buf@entry=2, n_ints_read=n_ints_read@entry=0x7ffcdd5cd5cc, error=error@entry=0x0) at gspawn.c:1257 #3 0x00007f3b74530696 in fork_exec_with_pipes (intermediate_child=intermediate_child@entry=0, working_directory=working_directory@entry=0x0, argv=0xeac90be5920, envp=envp@entry=0x0, close_descriptors=close_descriptors@entry=1, search_path=search_path@entry=1, search_path_from_envp=0, stdout_to_null=0, stderr_to_null=0, child_inherits_stdin=0, file_and_argv_zero=0, cloexec_pipes=0, child_setup=0x0, user_data=0x0, child_pid=0x7ffcdd5cd6e8, standard_input=0x0, standard_output=0x7ffcdd5cd6e0, standard_error=0x0, error=0x0) at gspawn.c:1475 #4 0x00007f3b74530d99 in g_spawn_sync (working_directory=working_directory@entry=0x0, argv=<optimized out>, envp=envp@entry=0x0, flags=flags@entry=G_SPAWN_SEARCH_PATH, child_setup=child_setup@entry=0x0, user_data=user_data@entry=0x0, standard_output=0x7ffcdd5cd878, standard_error=0x0, exit_status=0x0, error=0x0) at gspawn.c:288 #5 0x00007f3b745314c6 in g_spawn_command_line_sync (command_line=<optimized out>, standard_output=0x7ffcdd5cd878, standard_error=0x0, exit_status=0x0, error=0x0) at gspawn.c:727 #6 0x00007f3b5d3ed2e9 in Oxygen::QtSettings::runCommand(std::string const&, char*&) const () from /usr/lib64/gtk-2.0/2.10.0/engines/liboxygen-gtk.so #7 0x00007f3b5d3efa20 in Oxygen::QtSettings::kdeConfigPathList() const () from /usr/lib64/gtk-2.0/2.10.0/engines/liboxygen-gtk.so #8 0x00007f3b5d3fdf15 in Oxygen::QtSettings::initialize(unsigned int) () from /usr/lib64/gtk-2.0/2.10.0/engines/liboxygen-gtk.so #9 0x00007f3b5d41b8d0 in Oxygen::Style::initialize(unsigned int) () from /usr/lib64/gtk-2.0/2.10.0/engines/liboxygen-gtk.so #10 0x00007f3b5d41bcb1 in Oxygen::Style::fileChanged(_GFileMonitor*, _GFile*, _GFile*, GFileMonitorEvent, void*) () from /usr/lib64/gtk-2.0/2.10.0/engines/liboxygen-gtk.so #11 0x00007f3b6e9a7fb0 in ffi_call_unix64 () from /usr/lib64/libffi.so.6 #12 0x00007f3b6e9a7a18 in ffi_call () from /usr/lib64/libffi.so.6 #13 0x00007f3b747c022c in g_cclosure_marshal_generic_va (closure=0xeac8e93bf20, return_value=0x0, instance=0xeac8e910100, args_list=<optimized out>, marshal_data=0x0, n_params=3, param_types=0xeac8e98cfe0) at gclosure.c:1594 #14 0x00007f3b747bf7d4 in _g_closure_invoke_va (closure=closure@entry=0xeac8e93bf20, return_value=return_value@entry=0x0, instance=instance@entry=0xeac8e910100, args=args@entry=0x7ffcdd5cdfa8, n_params=<optimized out>, param_types=0xeac8e98cfe0) at gclosure.c:864 #15 0x00007f3b747d953e in g_signal_emit_valist (instance=0xeac8e910100, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffcdd5cdfa8) at gsignal.c:3292 #16 0x00007f3b747d9dd2 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3439 #17 0x00007f3b7358b4e3 in g_file_monitor_emit_event (monitor=<optimized out>, child=<optimized out>, other_file=<optimized out>, event_type=<optimized out>) at gfilemonitor.c:275 #18 0x00007f3b7362a219 in g_file_monitor_source_dispatch (source=0xeac8e98ec00, callback=<optimized out>, user_data=<optimized out>) at glocalfilemonitor.c:546 #19 0x00007f3b744ec16b in g_main_dispatch (context=0xeac8e8764d0) at gmain.c:3154 #20 g_main_context_dispatch (context=context@entry=0xeac8e8764d0) at gmain.c:3769 #21 0x00007f3b744ec4d8 in g_main_context_iterate (context=context@entry=0xeac8e8764d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840 #22 0x00007f3b744ec57c in g_main_context_iteration (context=0xeac8e8764d0, may_block=1) at gmain.c:3901 kde4-config is called there and read() there hangs. So two possibilities - another bug in glib2 or some bug in oxygen. (gdb) frame 2 #2 read_ints (fd=219, buf=buf@entry=0x7ffcdd5cd620, n_ints_in_buf=n_ints_in_buf@entry=2, n_ints_read=n_ints_read@entry=0x7ffcdd5cd5cc, error=error@entry=0x0) at gspawn.c:1257 1257 chunk = read (fd, (gdb) l 1252 break; /* give up, who knows what happened, should not be 1253 * possible. 1254 */ 1255 1256 again: 1257 chunk = read (fd, 1258 ((gchar*)buf) + bytes, 1259 sizeof(gint) * n_ints_in_buf - bytes); 1260 if (chunk < 0 && errno == EINTR) 1261 goto again; (gdb) print buf $1 = (gint *) 0x7ffcdd5cd620 (gdb) print *buf $2 = 0 (gdb) print bytes $3 = 0 (gdb) print n_ints_in_buf $4 = 2 Reproducible: Sometimes Steps to Reproduce: 1. No easy way to reproduce. It simply hangs google chrome UI one per 1-3 days. Backtrace is always the same - waiting for read in g_spawn_command_line_sync
Also from https://bugzilla.gnome.org/show_bug.cgi?id=738620 "g_spawn_* functions call internally fork_exec_with_pipes(), which calls do_exec(). In these functions, there are called functions which are not async-signal-safe, like readdir, dirfd, and probably others (I apology for not providing a complete callstack, but I reproduced a bug once and without full debug info)." so doesn't seem to be sane to use g_spawn_* functions for oxygen like stuff.
2 weeks of using oxygen with patch below reverted and no single lockup. So g_spawn_command_line_sync is still source of problems. commit 2068101234271725def6fe91de4a26543b260cba Author: Hugo Pereira Da Costa <hugo@oxygen-icons.org> Date: Wed Jun 19 14:17:53 2013 +0200 Re-added use of g_spawn_command_line_sync in place of popen, to execute an external comment. This effectively reverts commit 51b662b0cd86fd7a960cc2f0c436441d64b2dd44 Rational: - the failure of g_spawn_command_line_sync was a glib bug 3.6.0, that got fixed since then (3.6.2) - the use of popen generates unnecessary console when compiled for windows - the use of popen makes it difficult to redirect stderr, which results in error messages being printed on screen when the executed command failed (for instance because the relevant application is not installed. CCBUG: 318891
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.