qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [BUG] GTK terminal is broken


From: Stefan Weil
Subject: Re: [Qemu-devel] [BUG] GTK terminal is broken
Date: Wed, 28 Aug 2013 19:50:30 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8

Am 30.07.2013 00:35, schrieb Laszlo Ersek:
> On 07/29/13 20:18, Stefan Weil wrote:
>> Am 29.07.2013 20:05, schrieb Anthony Liguori:
>>> Stefan Weil <address@hidden> writes:
>>>
>>>> Hello,
>>>>
>>>> maybe most developers will already have noticed that the terminal output
>>>> in QEMU's GTK user interface is broken. As far as I know, it never worked,
>>>> but as there are working alternatives, I did not care much and forgot to
>>>> report the issues.
>>>>
>>>> See these snapshots which show the problems with QEMU's GTK terminals:
>>>>
>>>> http://qemu.weilnetz.de/test/bugs/qemu-gtk-demo1.png
>>>>
>>>> Here the first line of the QEMUmonitor is only partially visible.
>>>> Tested with Cygwin/X on W64 host, QEMU running on Debian Linux.
>>>> Other X servers (e.g. native X on Debian Linux) don't show this
>>>> problem.
>>> It's a GTK/Cygwin/X bug.
>>>
>>> We use a vbox without anything particularly fancy happening.  Looks like
>>> something is calculating layout incorrectly.
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>> I miss a comment on the more important next two points.
>> They are _not_ related to Cygwin / X.
>>
>> Do you investigate them?
> I did some investigation, and the results are not pretty. I'm using
> RHEL-6.4 host OS (kernel, gtk, vte etc), with fresh upstream qemu. The
> command line (started as a mere user --> TCG) was
>
> ./qemu-system-x86_64 -cdrom
> /home/virt-images/isos/Fedora-18-x86_64-Live-XFCE.iso
>
> Please find the attached debug patch (it has a small functional change
> as well, I'll discuss it below).
>
> (a) The patch extends the qemu_hexdump() function with ASCII strings. I
> wanted to ask you to run your tests with this patch applied, and try to
> correlate the hexdumps with the breakage on the screen.
>
> However, when testing the patch myself, I ran into problems.
>
> (b) The patch adds a qemu_set_nonblock(slave_fd) call to gd_vc_init(). I
> tested the patch both with and without this hunk.
>
> The key is to produce big output for VTE. For that purpose I waited
> until the Fedora 18 kernel enabled paging, and then issued "info tlb".
>
> ("info tlb" should be familiar from a recent monitor bugfix, as test
> case / trigger, but in bleeding edge qemu the monitor is OK.)
>
> So, if I do not add (b), the debug patch starts to spew data to stderr,
> and after a while qemu hangs hard, in the write() call in gd_vc_chr_write().
>
> If I add (b), then the same happens initially, followed by qemu spinning
> (ie. entering and exiting rapidly, without making any progress)
> gd_vc_chr_write(), with write() returning -1/EAGAIN.
>
> VTE seems to expect the owner of the slave side to run in a different
> process or thread. While browsing vte_terminal_io_read(), I found some
> throttling code in the read path, where VTE tries to keep one child
> process (maybe running in one tab?) to monopolize it.
>
> I think this could explain the deadlock / busy wait behavior. In qemu
> both sides of the terminal are manipulated by the same thread, and both
> file descriptors are (should be) added to the same GLib main loop. At
> some point VTE would be able read the master side but refuses to, the
> pty buffer becomes full, the slave-side write() in gd_vc_chr_write()
> blocks, and VTE never gets back control to release the throttle.
>
> This doesn't explain why qemu never recovers when the slave side is set
> to non-blocking mode (ie. with (b) added). I suspect that although we
> manage to run circles around the main loop in this case, we either never
> reach the master-fd read in VTE, or VTE always decides it's still too
> early to read.
>
> Laszlo

Thanks for your analysis. For me, it confirms that terminal
emulation with GTK is currently unusable.

Here is one more obvious bug (tested on Linux):

1. Run qemu-system-i386 -L pc-bios with GTK UI.
2. Select "Show tabs".
3. Unselect "Show tabs".

In 3, blank lines are added on top and on the bottom of the BIOS boot text,
so the screen in 3 is higher than in 1 although both should be identical.

Stefan




reply via email to

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