Question

Linux IBM370 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
ldd (Ubuntu EGLIBC 2.15-0ubuntu20) 2.15
GTK+  2.24.13-0ubuntu2 and 3.2.4-2 - the same behavior

There are some report in Gnome bugzilla:
https://mail.gnome.org/archives/gtk-devel-list/2012-June/msg00017.html
The problem is gtkfilechooser crash application on second call or even the first one

GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument.  Aborting.  
Aborted (core dumped)

I found that the problem raises when I have background thread running.

g_thread_new("vm refresh thread", get_vm_list, (gpointer) session);

Here is file chooser function

char *
gtk_select_dir(char *label)
{
    GtkWidget *select_dir;
    char *dirpath=NULL;
    select_dir = gtk_file_chooser_dialog_new(label, GTK_WINDOW(main_window),
                                          GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
                                          GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT, NULL );

    if (gtk_dialog_run(GTK_DIALOG (select_dir) ) == GTK_RESPONSE_ACCEPT)
    {
        dirpath = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER (select_dir) );
    }   
    gtk_widget_destroy(select_dir);
    return (dirpath);
}

Everything is ok while no threads are running. While threads are running, calling this function from main thread lead to crash. After thread finished and exited any call to this function leads to segfault. Here is gdb output

(gdb) backtrace 
#0  0x00007f7d4aff6425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f7d4aff9b8b in __GI_abort () at abort.c:91
#2  0x00007f7d4b9ed95d in g_thread_abort (status=<optimized out>, function=function@entry=0x7f7d4baad358 "pthread_setspecific")
at /build/buildd/glib2.0-2.34.1/./glib/gthread-posix.c:76
#3  0x00007f7d4ba58215 in g_private_set (key=key@entry=0x7f7d4a192ce0 <current_cancellable>, value=0x1c21a80)
at /build/buildd/glib2.0-2.34.1/./glib/gthread-posix.c:1024
#4  0x00007f7d49e75400 in g_cancellable_push_current (cancellable=<optimized out>) at /build/buildd/glib2.0-2.34.1/./gio/gcancellable.c:203
#5  0x00007f7d49e9c224 in io_job_thread (data=0x1fe1ba0, user_data=<optimized out>) at /build/buildd/glib2.0-2.34.1/./gio/gioscheduler.c:158
#6  0x00007f7d4ba3ee62 in g_thread_pool_thread_proxy (data=<optimized out>) at /build/buildd/glib2.0-2.34.1/./glib/gthreadpool.c:309
#7  0x00007f7d4ba3e645 in g_thread_proxy (data=0x1c0b320) at /build/buildd/glib2.0-2.34.1/./glib/gthread.c:797
#8  0x00007f7d4b386e9a in start_thread (arg=0x7f7d3e240700) at pthread_create.c:308
#9  0x00007f7d4b0b3cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10 0x0000000000000000 in ?? ()

This issue totally blocks me from using threads... is it bug as described or I did something wrong?

Was it helpful?

Solution

The answer is inproper use of libxml2

Based on the libxml2 document (http://xmlsoft.org/threads.html), we should only call xmlInitParser() in the "main" thread, but we are calling xmlInitParser() multiple times. The proper way to use xmlCleanupParser should be calling immediately before exiting and only once. But we are calling xmlCleanupParser multiple times.

The problem was in imported source code that ignored it

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top