Re: [Qemu-devel] qemu-nbd vs 'simple' trace backend vs iotest 147

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

On Mon, Jul 09, 2018 at 03:45:49PM +0200, Cornelia Huck wrote:
> Hi,
> 
> I recently noticed that iotest 147 was hanging on my laptop, but worked
> fine on my s390x LPAR. Turned out that the architecture was a red
> herring; on both platforms, things fail with the 'simple' trace backend
> and work with e.g. the 'log' trace backend. Some details on the
> failures with the 'simple' backend:
> 
> - The first run of 147 passes. However, there are two processes hanging
>   around, one using a unix socket and one using an inet socket:
> 
> cohuck   22912  0.0  0.0 156580  3836 ?        Ss   14:32   0:00 /home/cohuck/git/qemu/build/tests/qemu-iotests/../../qemu-nbd --fork -f qcow2 /home/cohuck/git/qemu/build/tests/qemu-iotests/scratch/test.img -p 10811
> cohuck   22925  0.0  0.0 156580  3840 ?        Ss   14:32   0:00 /home/cohuck/git/qemu/build/tests/qemu-iotests/../../qemu-nbd --fork -f qcow2 /home/cohuck/git/qemu/build/tests/qemu-iotests/scratch/test.img -k /home/cohuck/git/qemu/build/tests/qemu-iotests/scratch/nbd.socket
> 
> Attaching a gdb shows that we seem to be waiting on flushing:
> 
> (gdb) bt
> #0  0x00007f461c078b99 in syscall () from /lib64/libc.so.6
> #1  0x00007f461d13650f in g_cond_wait () from /lib64/libglib-2.0.so.0
> #2  0x0000560cf3a1caf2 in flush_trace_file (wait=255)
>     at /home/cohuck/git/qemu/trace/simple.c:139
> #3  st_flush_trace_buffer () at /home/cohuck/git/qemu/trace/simple.c:374
> #4  0x00007f461bfc01d8 in __run_exit_handlers () from /lib64/libc.so.6
> #5  0x00007f461bfc022a in exit () from /lib64/libc.so.6
> #6  0x0000560cf392eb7e in main (argc=<optimized out>, argv=<optimized out>)
>     at /home/cohuck/git/qemu/qemu-nbd.c:1076
> 
> (for both processes)

Please also print backtraces for the other threads:

  (gdb) thread apply all bt

There should be another thread in writeout_thread() so I'm surprised
that flush_trace_file() is getting stuck in g_cond_wait().

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]