qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Aborts in iotest 169


From: Max Reitz
Subject: Re: [Qemu-devel] Aborts in iotest 169
Date: Wed, 23 Jan 2019 17:12:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 23.01.19 17:04, Luiz Capitulino wrote:
> On Wed, 23 Jan 2019 16:48:49 +0100
> Max Reitz <address@hidden> wrote:
> 
>> Hi,
>>
>> When running 169 in parallel (e.g. like so:
>>
>> $ while TEST_DIR=/tmp/t0 ./check -T -qcow2 169; do; done
>> $ while TEST_DIR=/tmp/t1 ./check -T -qcow2 169; do; done
>> $ while TEST_DIR=/tmp/t2 ./check -T -qcow2 169; do; done
>> $ while TEST_DIR=/tmp/t3 ./check -T -qcow2 169; do; done
>>
>> in four different shells), I get aborts:
> 
> OK, is this part of a test-suite that's also running migration
> tests in parallel or in sequence? In other words, what does
> iotests have to do with migration (sorry if this is stupid
> question, but it's been years I don't do qemu).

They run migration tests in sequence, but if you run multiple test
instances in parallel, well, then they will be run in parallel.

The only reason I CC'd you was because you were so prominent in git
blame. O:-)

> More below.
> 
> [...]
> 
>> The backtrace always goes like this:
>>
>> (gdb) bt
>> #0  0x00007f0acf5cc53f in raise () at /lib64/libc.so.6
>> #1  0x00007f0acf5b6895 in abort () at /lib64/libc.so.6
>> #2  0x000055a46ebbb1a6 in runstate_set (new_state=RUN_STATE_POSTMIGRATE)
>> at vl.c:742
>> #3  0x000055a46ebbb1a6 in runstate_set
>> (address@hidden) at vl.c:730
>> #4  0x000055a46ed39129 in migration_iteration_finish (s=0x55a4708be000)
>> at migration/migration.c:2972
>> #5  0x000055a46ed39129 in migration_thread
>> (address@hidden) at migration/migration.c:3130
>> #6  0x000055a46eea665a in qemu_thread_start (args=<optimized out>) at
>> util/qemu-thread-posix.c:502
>>
>>
>> #7  0x00007f0acf76258e in start_thread () at /lib64/libpthread.so.0
>> #8  0x00007f0acf6916a3 in clone () at /lib64/libc.so.6
>> (gdb) frame 2
>> #2  0x000055a46ebbb1a6 in runstate_set (new_state=RUN_STATE_POSTMIGRATE)
>> at vl.c:742
>> 742             abort();
>> (gdb) print current_run_state
>> $1 = RUN_STATE_RUNNING
>>
>>
>> Neither of migration or runstates are my strong suite, so I thought I'd
>> report it before diving into it.
> 
> So, the problem seems to be that qemu is going from running state to
> postmigrate state. IIRC, this is is an invalid state transition. The
> valid states to transition to depends if this guest is the source or
> target for migration.
> 
> When this happened in the past it meant some QEMU code skipped a
> transition, but I can't tell what this has to do with iotests.

Well, this iotest (which tests a migration configuration) sometimes
apparently results in this invalid transition.  But that can't be just
the test's fault, as qemu should handle that gracefully.

It's probably an issue in the migration code and not so much in vl.c, yes...

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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