summaryrefslogtreecommitdiff
path: root/qemu-img.c
diff options
context:
space:
mode:
authorStefan Hajnoczi <stefanha@redhat.com>2013-10-08 11:58:31 +0200
committerStefan Hajnoczi <stefanha@redhat.com>2014-03-25 13:39:31 +0100
commitae2990c259abec198879c362dc13f7047f26c2cf (patch)
treedbf4815eff7df7791a089fffef00d9dc4b71117d /qemu-img.c
parent839a5547574e57cce62f49bfc50fe1f04b00589a (diff)
downloadqemu-ae2990c259abec198879c362dc13f7047f26c2cf.tar.gz
osdep: initialize glib threads in all QEMU tools
glib versions prior to 2.31.0 require an explicit g_thread_init() call to enable multi-threading. Failure to initialize threading causes glib to take single-threaded code paths without synchronization. For example, the g_slice allocator will crash due to race conditions. Fix this for all QEMU tool programs (qemu-nbd, qemu-io, qemu-img) by moving the g_thread_init() call from vl.c:main() into a new osdep.c:thread_init() constructor function. thread_init() has __attribute__((constructor)) and is automatically invoked by the runtime during startup. We can now drop the "simple" trace backend's g_thread_init() call since thread_init() already called it. Note that we must keep coroutine-gthread.c's g_thread_init() call which is located in a constructor function. There is no guarantee for constructor function ordering so thread_init() may only be called later. Reported-by: Mario de Chenno <mario.dechenno@unina2.it> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Diffstat (limited to 'qemu-img.c')
0 files changed, 0 insertions, 0 deletions