Re: [Qemu-devel] [PATCH for-2.6 3/3] qom: -object error messages lost location, restore it

[Markus Armbruster]

"Daniel P. Berrange" <address@hidden> writes:

> On Wed, Apr 27, 2016 at 04:29:09PM +0200, Markus Armbruster wrote:
>> qemu_opts_foreach() runs its callback with the error location set to
>> the option's location.  Any errors the callback reports use the
>> option's location automatically.
>> 
>> Commit 90998d5 moved the actual error reporting from "inside"
>> qemu_opts_foreach() to after it.  Here's a typical hunk:
>> 
>>       if (qemu_opts_foreach(qemu_find_opts("object"),
>>     -                          object_create,
>>     -                          object_create_initial, NULL)) {
>>     +                          user_creatable_add_opts_foreach,
>>     +                          object_create_initial, &err)) {
>>     +        error_report_err(err);
>>           exit(1);
>>       }
>> 
>> Before, object_create() reports from within qemu_opts_foreach(), using
>> the option's location.  Afterwards, we do it after
>> qemu_opts_foreach(), using whatever location happens to be current.
>> Commonly a "none" location.
>
> IMHO this shows a major design flaw with error_report_err() method
> and the location handling. The design pattern we have for "Error *"
> objects is that we can freely propagate them up the caller, because
> it is a self-contained record of the error information. As soon as
> you do that you loose the location information, because it was not
> in fact associated with the Error, but rather stored in a single
> global variable. For that matter, the Location info isn't even
> thread safe AFAICT since its a simple state var, so you better hope
> that there's no code which calls loc_push/pop from a non-main thread :-(

I readily concede that the current state is decidedly sub-optimal.
Error reporting in QEMU has a tortuous history, and it shows.

Locations date back to simpler times.  Threads?  What's a "thread"?

The current location stack was the simplest way to retrofit locations to
most of the errors with the least churn.  If it's a good idea (which is
debatable), it should certainly be thread-local.

Error was created with cavalier disregard for actual error messages.
We've fixed the worst issues, but we haven't attacked location
information.

Instead, we fall back to what error_report() gives us for free: the
current location at the point where we report the error.

Blindly replacing this by the current location at the point where we
detect the error may not always be an improvement.  It depends.

Here's an instructive example:

    -drive if=none,cache=none,file=blkdebug:blkdebug.conf:...

with an erroneous blkdebug.conf.

The current location at the point where we detect the error is the bad
spot in blkdebug.conf.  That's useful information.  It currently gets
lost.

The current location at the point where we report the error should be
the -drive (it currently isn't, but that's just a bug).  Also useful
information.

>> Reproducer:
>> 
>>     $ qemu-system-x86_64 -nodefaults -display none -object 
>> secret,id=foo,foo=bar
>>     qemu-system-x86_64: Property '.foo' not found
>> 
>> Note no location.  This commit restores it:
>> 
>>     qemu-system-x86_64: -object secret,id=foo,foo=bar: Property '.foo' not 
>> found
>> 
>> Note that the qemu_opts_foreach() bug just fixed could mask the bug
>> here: if the location it leaves dandling hasn't been clobbered, yet,
>> it's the correct one.
>> 
>> Reported-by: Eric Blake <address@hidden>
>> Cc: Daniel P. Berrange <address@hidden>
>> Signed-off-by: Markus Armbruster <address@hidden>
[...]
>
> Very reluctant
>
>  Reviewed-by: Daniel P. Berrange <address@hidden>

Thanks!

> this really needs fixing properly in 2.7 so that the Error object is
> fully self contained so that later use of it does not rely on any
> global state.

Worthwhile project.