qemu-trivial
[Top][All Lists]
Advanced

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

Re: [Qemu-trivial] [Qemu-devel] [PATCH] qemu-char: fix terminal crash wh


From: Markus Armbruster
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] qemu-char: fix terminal crash when using "-monitor stdio -nographic"
Date: Fri, 05 Sep 2014 11:04:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Li Liu <address@hidden> writes:

> Ping, any more comments? Thanks.

I'd like to hear Gerd's opinion (cc'ed).

> On 2014/8/27 15:40, Li Liu wrote:
>> 
>> 
>> On 2014/8/27 14:44, Markus Armbruster wrote:
>>> "john.liuli" <address@hidden> writes:
>>>
>>>> From: Li Liu <address@hidden>
>>>>
>>>> Eeay to reproduce, just try "qemu -monitor stdio -nographic"
>>>> and type "quit", then the terminal will be crashed.
>>>>
>>>> There are two pathes try to call tcgetattr of stdio in vl.c:
>>>>
>>>> 1) Monitor_parse(optarg, "readline");
>>>>    .....
>>>>    qemu_opts_foreach(qemu_find_opts("chardev"),
>>>>                      chardev_init_func, NULL, 1) != 0)
>>>>
>>>> 2) if (default_serial)
>>>>    add_device_config(DEV_SERIAL, "stdio");
>>>>    ....
>>>>    if (foreach_device_config(DEV_SERIAL, serial_parse) < 0)
>>>>
>>>> Both of them will trigger qemu_chr_open_stdio which will disable
>>>> ECHO attributes. First one has updated the attributes of stdio
>>>> by calling qemu_chr_fe_set_echo(chr, false). And the tty
>>>> attributes has been saved in oldtty. Then the second path will
>>>> redo such actions, and the oldtty is overlapped. So till "quit",
>>>> term_exit can't recove the correct attributes.
>>>>
>>>> Signed-off-by: Li Liu <address@hidden>
>>>
>>> Yes, failure to restore tty settings is a bug.
>>>
>>> But is having multiple character devices use the same terminal valid?
>> 
>> I'm not sure. But I have found such comments in vl.c
>> "According to documentation and historically, -nographic redirects
>> serial port, parallel port and monitor to stdio"
>> 
>> Best regards
>> Li.
>> 
>>> If no, can we catch and reject the attempt?
>>>
>>> [...]



reply via email to

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