qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu process crash: Assertion failed: QLIST_EMPTY(&bs->


From: Fernando Casas Schössow
Subject: Re: [Qemu-devel] qemu process crash: Assertion failed: QLIST_EMPTY(&bs->tracked_requests)
Date: Wed, 13 Dec 2017 15:33:01 +0000

Thanks for the explanation Stefan.

Maybe I’m missing something here but, if I recall correctly, the qemu process 
for the guest is terminated when this problem happens. So how a debugger will 
be attached to a process that is gone?

Also I don’t think the Alpine packages for qemu include the debug info. :(
But I’m not 100% sure at the moment.

Sent from my iPhone

On 13 Dec 2017, at 12:23, Stefan Hajnoczi 
<address@hidden<mailto:address@hidden>> wrote:

On Mon, Dec 11, 2017 at 01:42:38PM +0000, Fernando Casas Schössow wrote:
Hello Stefan,

Thanks for your reply.
Fortunately I didn’t have the problem again and it’s not clear how it can be 
consistently reproduced. Daily backups are running as usual at the moment.

If there is anything I can do from my side or if you have any ideas to try to 
reproduce it let me know.

Okay, thanks.

In case it happens again, here is some information about the assertion
failure.  It will probably be necessary to use GDB to inspect the failed
process (core dump).  The starting point for debugging is mirror_run()
in block/mirror.c:

 if (cnt == 0 && should_complete) {
     /* The dirty bitmap is not updated while operations are pending.
      * If we're about to exit, wait for pending operations before
      * calling bdrv_get_dirty_count(bs), or we may exit while the
      * source has dirty data to copy!
      *
      * Note that I/O can be submitted by the guest while
      * mirror_populate runs, so pause it now.  Before deciding
      * whether to switch to target check one last time if I/O has
      * come in the meanwhile, and if not flush the data to disk.
      */
     trace_mirror_before_drain(s, cnt);

     bdrv_drained_begin(bs);
     cnt = bdrv_get_dirty_count(s->dirty_bitmap);
     if (cnt > 0 || mirror_flush(s) < 0) {
         bdrv_drained_end(bs);
         continue;
     }

     /* The two disks are in sync.  Exit and report successful
      * completion.
      */
     assert(QLIST_EMPTY(&bs->tracked_requests));

The reason why this assertion makes sense is because
bdrv_drained_begin(bs) starts a region where I/O is quiesced (all
requests should have been completed).

Either there is a bug with blockjobs vs bdrv_drained_debug(), or maybe
mirror_flush() submitted new I/O requests.

It would be interesting to print the bs->tracked_requests linked list
in the GDB debugger.  Those requests might give a clue about the root
cause.

Stefan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]