On Wed, Sep 18, 2013 at 03:35:12PM +0200, Mario DE CHENNO wrote: > This time crashed just issuing a mount command: > > Starting program: /vmstore/vmtools/qemu-nbd-from1.6.0 > /vmstore/playground/archivioweb.img > [Thread debugging using libthread_db enabled] > [New Thread 0x7ffff55e3700 (LWP 7626)] > [New Thread 0x7ffff47dd700 (LWP 7645)] > [New Thread 0x7ffff3fdc700 (LWP 7646)] > [New Thread 0x7ffff37db700 (LWP 7647)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff37db700 (LWP 7647)] > 0x00007ffff7717249 in ?? () from /usr/lib64/libglib-2.0.so.0 > (gdb) bt > #0 0x00007ffff7717249 in ?? () from /usr/lib64/libglib-2.0.so.0 > #1 0x00007ffff771759c in ?? () from /usr/lib64/libglib-2.0.so.0 > #2 0x00007ffff7718958 in g_slice_free1 () from /usr/lib64/libglib-2.0.so.0 > #3 0x0000555555591c2d in aio_worker (arg=0x555555c2f6c0) at > block/raw-posix.c:776 > #4 0x00005555555da094 in worker_thread (opaque=0x555555c31a40) at > thread-pool.c:109 > #5 0x00007ffff6c2ed6b in start_thread () from /lib64/libpthread.so.0 > #6 0x00007ffff6966abd in clone () from /lib64/libc.so.6
Please try this patch and let us know if it worked. Older glib versions required the application to call g_thread_init(). Failure to do so results in the single-threaded code path being used. In a multi-threaded application that means race conditions and I've seen crashes similar to the backtrace you've posted. diff --git a/qemu-nbd.c b/qemu-nbd.c index c26c98e..8ae3868 100644 --- a/qemu-nbd.c +++ b/qemu-nbd.c @@ -357,6 +357,15 @@ int main(int argc, char **argv) const char *fmt = NULL; Error *local_err = NULL; + if (!g_thread_supported()) { +#if !GLIB_CHECK_VERSION(2, 31, 0) + g_thread_init(NULL); +#else + fprintf(stderr, "glib threading failed to initialize.\n"); + exit(1); +#endif + } + /* The client thread uses SIGTERM to interrupt the server. A signal * handler ensures that "qemu-nbd -v -c" exits with a nice status code. */