[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] qdev-monitor: fix segmentation fault on qdev_de
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH] qdev-monitor: fix segmentation fault on qdev_device_help() |
Date: |
Tue, 16 Sep 2014 09:59:34 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
"Gonglei (Arei)" <address@hidden> writes:
>> From: Markus Armbruster [mailto:address@hidden
>> Sent: Tuesday, September 16, 2014 3:28 PM
>> Subject: Re: [Qemu-devel] [PATCH] qdev-monitor: fix segmentation fault on
>> qdev_device_help()
>>
>> <address@hidden> writes:
>>
>> > From: Gonglei <address@hidden>
>> >
>> > Normally, qmp_device_list_properties() may return NULL when
>> > a device haven't special properties excpet Object and DeviceState
>> > properties, such as virtio-balloon-device.
>> >
>> > We just need check local_err instead of prop_list.
>> >
>> > Example:
>> >
>> > Segmentation fault (core dumped)
>> >
>> > The backtrace as below:
>> >
>> > Program received signal SIGSEGV, Segmentation fault.
>> > 0x00005555559af1a8 in error_get_pretty (err=0x0) at util/error.c:152
>> > 152 return err->msg;
>> > (gdb) bt
>> > #0 0x00005555559af1a8 in error_get_pretty (err=0x0) at util/error.c:152
>> > #1 0x000055555572fce9 in qdev_device_help (opts=0x5555562fdfe0) at
>> qdev-monitor.c:210
>> > #2 0x000055555574a6f2 in device_help_func (opts=0x5555562fdfe0,
>> opaque=0x0) at vl.c:2362
>> > #3 0x00005555559c0a33 in qemu_opts_foreach (list=0x555555dd0b40
>> <qemu_device_opts>,
>> > func=0x55555574a6ca <device_help_func>, opaque=0x0,
>> abort_on_failure=0) at util/qemu-option.c:1072
>> > #4 0x000055555574f514 in main (argc=3, argv=0x7fffffffe218,
>> envp=0x7fffffffe238) at vl.c:4246
>> >
>> > Signed-off-by: Gonglei <address@hidden>
>> > ---
>> > qdev-monitor.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/qdev-monitor.c b/qdev-monitor.c
>> > index fb9ee24..5ec6606 100644
>> > --- a/qdev-monitor.c
>> > +++ b/qdev-monitor.c
>> > @@ -206,7 +206,7 @@ int qdev_device_help(QemuOpts *opts)
>> > }
>> >
>> > prop_list = qmp_device_list_properties(driver, &local_err);
>> > - if (!prop_list) {
>> > + if (local_err) {
>> > error_printf("%s\n", error_get_pretty(local_err));
>> > error_free(local_err);
>> > return 1;
>>
>> Doesn't this leak prop_list when local_err && prop_list?
>>
> No, it will not happen this situation.
>
>> Returning both a value in need of destruction and an error object is at
>> least highly unusual, and probably plain wrong.
>>
>> Should qmp_device_list_properties() return NULL when it sets an error?
>
> Yes, it was.
I think I'm starting to understand now.
You backtrace shows qmp_device_list_properties() returned null without
setting an error. But this is okay, because null means "empty list",
which is a valid return value.
A systematic search for this kind of incorrect error handling would be
nice: search for functions returning QAPI lists, then look for callers
interpreting a null value as error. Would you be willing to do that?
Reviewed-by: Markus Armbruster <address@hidden>
Re: [Qemu-devel] [PATCH] qdev-monitor: fix segmentation fault on qdev_device_help(), Stefan Hajnoczi, 2014/09/16