qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/6] tests/device-introspection: Check that the


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 2/6] tests/device-introspection: Check that the qom-tree and qtree do not change
Date: Wed, 15 Aug 2018 08:42:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Thomas Huth <address@hidden> writes:

> On 08/14/2018 07:53 PM, Markus Armbruster wrote:
>> Thomas Huth <address@hidden> writes:
>> 
>>> Introspection should not change the qom-tree / qtree, so we should check
>>> this in the device-introspect-test, too. This patch helped to find lots
>>> of instrospection bugs during the QEMU v3.0 soft/hard-freeze period in the
>>> last two months.
>> 
>> Clever idea.
>> 
>>> Signed-off-by: Thomas Huth <address@hidden>
>>> ---
>>>  tests/device-introspect-test.c | 23 +++++++++++++++++++----
>>>  1 file changed, 19 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/tests/device-introspect-test.c b/tests/device-introspect-test.c
>>> index 0b4f221..5b7ec05 100644
>>> --- a/tests/device-introspect-test.c
>>> +++ b/tests/device-introspect-test.c
>>> @@ -103,7 +103,14 @@ static QList *device_type_list(bool abstract)
>>>  static void test_one_device(const char *type)
>>>  {
>>>      QDict *resp;
>>> -    char *help, *qom_tree;
>>> +    char *help;
>>> +    char *qom_tree_start, *qom_tree_end;
>>> +    char *qtree_start, *qtree_end;
>>> +
>>> +    g_debug("Testing device '%s'", type);
>> 
>> This is only the second use of g_debug() in tests/.  What are you trying
>> to accomplish?
>
> When the test crashes, I need a way to determine the device which caused
> the crash. To avoid that I've then got to insert fprintf statements
> manually here and recompile, the g_debug() seems to be a good solution,
> since you can enable its output by setting some environment variable (I
> use G_MESSAGES_DEBUG=all and G_MESSAGES_PREFIXED=none).

I see.  However, I'm unlikely to remember these GLib arcana when I run
into test failures.

> Or do you see a better way to provide a possibility to determine the
> device that caused a crash?

g_test_message() and --verbose.

Less arcane, because device-introspect-test --help points to --verbose,
and --verbose does the natural thing, namely printing more about what
it's being done.

Another option would be to split test_device_intro_concrete() into one
test case per device.  main() would have to enumerate devices so it can
register the test cases.  Vaguely similar to how qmp-test enumerates
query commands and registers their tests.  Probably not worth the bother
now.



reply via email to

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