* [Qemu-devel] qemu-nbd segmentation fault
@ 2013-09-17 12:53 ing. Mario De Chenno
2013-09-18 12:50 ` Stefan Hajnoczi
0 siblings, 1 reply; 5+ messages in thread
From: ing. Mario De Chenno @ 2013-09-17 12:53 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 6471 bytes --]
Hi all.
I cannot use qemu-nbd to write files to a qcow2 disk image. It always exit
after a while with a segmentation fault.
Here's what I'm doing:
modprobe nbd max_part=8
qemu-nbd qcow2image.img
(in another shell)
nbd-client localhost 10809 /dev/nbd0
mount /dev/nbd0p1 /mnt/tmp
cd /mnt/tmp
tar -xf file.tar.gz
The qcow2 image holds a single ext4 primary partition and (of course) it is
not associated
with any running vm. file.tar.gz is a 7GB website backup with a big number
of (mostly small) files in it.
Anyway I also get a segfault trying to remove the files with "rm -rf *"
nbd client is compiled from the latest sources.
qemu-nbd is from qemu 1.4.0 we compiled from source and run in production
without problems on Slackware64 13.37. I tried qemu-nbd from 1.6.0 with
the same result.
kernel is 3.4.0
Below are the last lines from "strace qemu-nbd" output.
Let me know If I can help.
Mario
-----------------------------
sendmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"gDf\230\0\0\0\0\30\325\243\203\0\210\377\377", 16}],
msg_controllen=0, msg_flags=0}, 0) = 16
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
poll([{fd=8, events=POLLIN|POLLERR|POLLHUP}, {fd=3,
events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=4,
events=POLLIN}], 4, -1) = 3 ([{fd=8, revents=POLLIN}, {fd=6,
revents=POLLIN}, {fd=4, revents=POLLIN}])
read(6, "\n\0\0\0\0\0\0\0", 512) = 8
read(4, "\7\0\0\0\0\0\0\0", 512) = 8
recvmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"%`\225\23\0\0\0\1p\310\243\203\0\210\377\377\0\0\0\2\0208\260\0\0\1\360\0",
28}], msg_controllen=0, msg_flags=0}, 0) = 28
recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{"\213K\24
+\305\377\365\370T\344\371\243w\37m\200\247~\357\7\374\201t\250\213\224\364\221P{\277"...,
126976}], msg_controllen=0, msg_flags=0}, 0) = 126976
poll([{fd=8, events=POLLIN|POLLERR|POLLHUP}, {fd=3,
events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=4,
events=POLLIN}], 4, -1) = 2 ([{fd=8, revents=POLLIN}, {fd=6,
revents=POLLIN}])
read(6, "\2\0\0\0\0\0\0\0", 512) = 8
recvmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"%`\225\23\0\0\0\1h\301\243\203\0\210\377\377\0\0\0\2\20:\240\0\0\1\360\0",
28}], msg_controllen=0, msg_flags=0}, 0) = 28
recvmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"\311L\321l\360o\302\373>^\217\325\336\234\37\370W\350\0165\31\371\213w,\273\373\342\363\360\n\347"...,
126976}], msg_controllen=0, msg_flags=0}, 0) = 126976
poll([{fd=8, events=POLLIN|POLLERR|POLLHUP}, {fd=3,
events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=4,
events=POLLIN}], 4, -1) = 2 ([{fd=8, revents=POLLIN}, {fd=6,
revents=POLLIN}])
read(6, "\1\0\0\0\0\0\0\0", 512) = 8
recvmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"%`\225\23\0\0\0\1\0\300\243\203\0\210\377\377\0\0\0\2\20<\220\0\0\1\360\0",
28}], msg_controllen=0, msg_flags=0}, 0) = 28
recvmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{";a\16Z8\224yi\317\254\366\0166\36\35F\321\3\30\254Y\212\323\10\347\236\272\364\241T\16\245"...,
126976}], msg_controllen=0, msg_flags=0}, 0) = 126976
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=4,
events=POLLIN}], 3, -1) = 1 ([{fd=6, revents=POLLIN}])
read(6, "\1\0\0\0\0\0\0\0", 512) = 8
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=4,
events=POLLIN}], 3, -1) = 1 ([{fd=6, revents=POLLIN}])
read(6, "\1\0\0\0\0\0\0\0", 512) = 8
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
sendmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"gDf\230\0\0\0\0\20\316\243\203\0\210\377\377", 16}],
msg_controllen=0, msg_flags=0}, 0) = 16
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
sendmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"gDf\230\0\0\0\0\320\302\243\203\0\210\377\377", 16}],
msg_controllen=0, msg_flags=0}, 0) = 16
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
brk(0x7f4f5b5e5000) = 0x7f4f5b5e5000
poll([{fd=8, events=POLLIN|POLLERR|POLLHUP}, {fd=3,
events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=4,
events=POLLIN}], 4, -1) = 3 ([{fd=8, revents=POLLIN}, {fd=6,
revents=POLLIN}, {fd=4, revents=POLLIN}])
read(6, "\6\0\0\0\0\0\0\0", 512) = 8
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
read(4, "\5\0\0\0\0\0\0\0", 512) = 8
recvmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"%`\225\23\0\0\0\1\340\375\243\203\0\210\377\377\0\0\0\2\20>\200\0\0\1\360\0",
28}], msg_controllen=0, msg_flags=0}, 0) = 28
recvmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"\5\2763x\234\6\322\260m\200\311\33\234I#\335\246${\16\25\213\20\250\302/\304\322\315\331J\265"...,
126976}], msg_controllen=0, msg_flags=0}, 0) = 126976
poll([{fd=8, events=POLLIN|POLLERR|POLLHUP}, {fd=3,
events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=4,
events=POLLIN}], 4, -1) = 1 ([{fd=8, revents=POLLIN}])
recvmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"%`\225\23\0\0\0\1\320\357\243\203\0\210\377\377\0\0\0\2\20@p\0\0\1\360\0",
28}], msg_controllen=0, msg_flags=0}, 0) = 28
recvmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"sf\36\363\210G<\341q\217{\362\223\236\370h\220\311w\276\343\370\233^\365\243\312\234\351\221?\375"...,
126976}], msg_controllen=0, msg_flags=0}, 0) = 126976
poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=4,
events=POLLIN}], 3, -1) = 1 ([{fd=6, revents=POLLIN}])
read(6, "\1\0\0\0\0\0\0\0", 512) = 8
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
sendmsg(8, {msg_name(0)=NULL,
msg_iov(1)=[{"gDf\230\0\0\0\0\220\344\243\203\0\210\377\377", 16}],
msg_controllen=0, msg_flags=0}, 0) = 16
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=8, events=POLLIN|POLLERR|POLLHUP}, {fd=3,
events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=4,
events=POLLIN}], 4, -1) = 3 ([{fd=8, revents=POLLIN}, {fd=6,
revents=POLLIN}, {fd=4, revents=POLLIN}])
read(6, "\3\0\0\0\0\0\0\0", 512) = 8
futex(0x7f4f5b187ad8, FUTEX_WAKE_PRIVATE, 1) = 1
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault
[-- Attachment #2: Type: text/html, Size: 7411 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] qemu-nbd segmentation fault
2013-09-17 12:53 [Qemu-devel] qemu-nbd segmentation fault ing. Mario De Chenno
@ 2013-09-18 12:50 ` Stefan Hajnoczi
2013-09-18 13:35 ` [Qemu-devel] R: " Mario DE CHENNO
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Hajnoczi @ 2013-09-18 12:50 UTC (permalink / raw)
To: ing. Mario De Chenno; +Cc: qemu-devel
On Tue, Sep 17, 2013 at 02:53:51PM +0200, ing. Mario De Chenno wrote:
> I cannot use qemu-nbd to write files to a qcow2 disk image. It always exit
> after a while with a segmentation fault.
Hi Mario,
Thanks for providing the strace. Is it possible for you to post a
backtrace?
The backtrace shows where exactly the segfault occurs. Try this:
$ gdb --args path/to/qemu-nbd test.img
When the qemu-nbd process crashes you will be at the gdb prompt and can
print the backtrace:
(gdb) bt
Please post the gdb output.
Thanks,
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Qemu-devel] R: qemu-nbd segmentation fault
2013-09-18 12:50 ` Stefan Hajnoczi
@ 2013-09-18 13:35 ` Mario DE CHENNO
2013-09-19 10:05 ` Stefan Hajnoczi
0 siblings, 1 reply; 5+ messages in thread
From: Mario DE CHENNO @ 2013-09-18 13:35 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1840 bytes --]
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
See you again
Mario
-----Messaggio originale-----
Da: Stefan Hajnoczi [mailto:stefanha@gmail.com]
Inviato: mer 18/09/2013 14.50
A: Mario DE CHENNO
Cc: qemu-devel@nongnu.org
Oggetto: Re: [Qemu-devel] qemu-nbd segmentation fault
On Tue, Sep 17, 2013 at 02:53:51PM +0200, ing. Mario De Chenno wrote:
> I cannot use qemu-nbd to write files to a qcow2 disk image. It always exit
> after a while with a segmentation fault.
Hi Mario,
Thanks for providing the strace. Is it possible for you to post a
backtrace?
The backtrace shows where exactly the segfault occurs. Try this:
$ gdb --args path/to/qemu-nbd test.img
When the qemu-nbd process crashes you will be at the gdb prompt and can
print the backtrace:
(gdb) bt
Please post the gdb output.
Thanks,
Stefan
[-- Attachment #2: Type: text/html, Size: 2542 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] R: qemu-nbd segmentation fault
2013-09-18 13:35 ` [Qemu-devel] R: " Mario DE CHENNO
@ 2013-09-19 10:05 ` Stefan Hajnoczi
2013-10-02 8:32 ` Stefan Hajnoczi
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Hajnoczi @ 2013-09-19 10:05 UTC (permalink / raw)
To: Mario DE CHENNO; +Cc: qemu-devel
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.
*/
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] R: qemu-nbd segmentation fault
2013-09-19 10:05 ` Stefan Hajnoczi
@ 2013-10-02 8:32 ` Stefan Hajnoczi
0 siblings, 0 replies; 5+ messages in thread
From: Stefan Hajnoczi @ 2013-10-02 8:32 UTC (permalink / raw)
To: Mario DE CHENNO; +Cc: qemu-devel
On Thu, Sep 19, 2013 at 12:05 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> 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.
> */
Hi Mario,
Have you had time to try out this patch?
Stefan
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-10-02 8:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-17 12:53 [Qemu-devel] qemu-nbd segmentation fault ing. Mario De Chenno
2013-09-18 12:50 ` Stefan Hajnoczi
2013-09-18 13:35 ` [Qemu-devel] R: " Mario DE CHENNO
2013-09-19 10:05 ` Stefan Hajnoczi
2013-10-02 8:32 ` Stefan Hajnoczi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).