glib2-devel-2.30.3-1.fc16.i686

We (abrt project) use syncronous dbus calls in a single-threaded application.
Essentially:

static GDBusProxy *get_dbus_proxy(void)
{
    GError *error = NULL;
    GDBusProxy *proxy = g_dbus_proxy_new_for_bus_sync(G_BUS_TYPE_SYSTEM,
                                         G_DBUS_PROXY_FLAGS_NONE,
                                         NULL,
                                         ABRT_DBUS_NAME,
                                         ABRT_DBUS_OBJECT,
                                         ABRT_DBUS_IFACE,
                                         NULL,
                                         &error);
    if (error) ...
    return proxy;
}

...
    GDBusProxy *proxy = get_dbus_proxy();
    if (!proxy)
        return NULL;
    GError *error = NULL;
    GVariant *result = g_dbus_proxy_call_sync(proxy,
                                    "GetProblems",
                                    g_variant_new("()"),
                                    G_DBUS_CALL_FLAGS_NONE,
                                    -1,
                                    NULL,
                                    &error);
...

We discovered that sometime after we do such calls (and they work successfully, no problem), our application hangs after fork().

The hanging code looks like this:

        pid_t pid = fork();
        if (pid < 0) /* error */...
        if (pid == 0) /* child */
        {
            struct run_event_state *run_state = new_run_event_state();
            int r = run_event_on_dir_name(run_state, dirname, "open-gui");
            int no_such_event = (r == 0 && run_state->children_count == 0);
            free_run_event_state(run_state);
            if (!no_such_event)
            {
                exit(r);
            }
            /* Default: launch graphical tool */
            execlp("report-gtk", "report-gtk", "--", (char *)dirname, NULL);
            perror_msg_and_die("Can't execute %s", "report-gtk");
        }

Child process gets stuck on a futex() call soon after fork() - we do not reach run_event_on_dir_name() and execlp().

Even when parent process is gone, the still-living child remains visible in ps output.

This bug disappears under strace and when debug logging is added. Basically, it looks like a non-deterministic inconsistent lock state in the child.

After investigating the problem we discovered that our program is not single-threaded anymore (!!!) - glib created a thread in g_dbus_proxy_new_for_bus_sync() or in g_dbus_proxy_call_sync() function, and this thread persists for the lifetime of the program. I see it in ps -AT output.

Stracing shows a fair amount of futex ops in this thread. So, it is capable of locking and unlocking locks while we fork() - classic cause of PITA when threading and fork() are mixed.

We wrote the program as a single-threaded one exactly because we wnated to avoid going there.

When we run the program so that it does not use dbus ("abrt-gui -D /var/spool/abrt"), this thread is not created, and the buggy behavior does not trigger.

Can you guys please make *syncronous* glib dbus API to not create threads? Or at least nuke these threads when they are done?

If it is a performance hit to repeatedle create and tear them down, consider exposing a nuke_stupid_thread_I_did_not_ask_for()-esque function in the API so that we can still enjoy the simplicity of single-threaded life?