Markus Armbruster <arm...@redhat.com> writes:
> Michal Privoznik <mpriv...@redhat.com> writes:
>
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0 0x000055baf6ab4adc in qemu_opt_foreach (opts=0x0, func=0x55baf696b650
>> <net_vhost_chardev_opts>, opaque=0x7ffc51368c00, errp=0x7ffc51368e48) at
>> util/qemu-option.c:617
>> 617 QTAILQ_FOREACH(opt, &opts->head, next) {
>> [Current thread is 1 (Thread 0x7f1d4970bb40 (LWP 6603))]
>> (gdb) bt
>> #0 0x000055baf6ab4adc in qemu_opt_foreach (opts=0x0, func=0x55baf696b650
>> <net_vhost_chardev_opts>, opaque=0x7ffc51368c00, errp=0x7ffc51368e48) at
>> util/qemu-option.c:617
>> #1 0x000055baf696b7da in net_vhost_parse_chardev (opts=0x55baf8ff9260,
>> errp=0x7ffc51368e48) at net/vhost-user.c:314
>
> This is where the null opts come from:
>
> CharDriverState *chr = qemu_chr_find(opts->chardev);
> VhostUserChardevProps props;
>
> if (chr == NULL) {
> error_setg(errp, "chardev \"%s\" not found", opts->chardev);
> return NULL;
> }
>
> /* inspect chardev opts */
> memset(&props, 0, sizeof(props));
> if (qemu_opt_foreach(chr->opts, net_vhost_chardev_opts, &props, errp)) {
> return NULL;
> }
>
> Can CharDriverState member opts be legitimately null? If yes, then its
> definition needs a comment. But I suspect the answer is no.
>
> [...]
Looks like the answer is yes: CharDriverState member opts is non-null
when the CharDriverState got created the old-fashioned way, via
qemu_chr_new_from_opts(), and null when it got created by
qmp_chardev_add(). We need to check all uses of member opts. We should
also document this with a comment next to the definition of
CharDriverState member opts.
