Re: Delay on exiting GUI

[Daniel J Sebald]

On 04/27/2015 09:38 PM, Mike Miller wrote:
> On Mon, Apr 27, 2015 at 16:25:37 -0500, Daniel J Sebald wrote:
> > Could someone describe the delay?  Is it just in the GUI?  Or octave-cli as
> > well?  Edit some unsaved file and exit, trying to say "save" in response to
> > the dialog box as fast as possible.  Is the delay before the dialog box or
> > after the dialog box?  Open the resources/processes monitor for the desktop.
> > Does the CPU usage climb during those ten seconds before exit actually
> > completes?
>
> Hey Dan and others affected,
>
> I think I have narrowed this down, at least for me I think it is bug
> #40693 [1], or another incarnation of something related to the
> clipboard, occurring again.
>
> The delay has nothing to do with any interaction in the GUI, it occurs
> after the GUI appears to have completely disappeared, but control is not
> returned to the shell. It also affects octave --no-gui, but not
> octave-cli.
>
> I was able to run octave-gui in gdb, and get the following backtrace in
> the main thread:
>
> #0  0x00007ffff41f02b3 in select () at ../sysdeps/unix/syscall-template.S:81
> #1  0x00007ffff3015e50 in QX11Data::clipboardWaitForEvent (this=<optimized out>,
>      address@hidden, address@hidden, address@hidden,
>      address@hidden, address@hidden)
>      at kernel/qclipboard_x11.cpp:596
> #2  0x00007ffff3018d53 in QClipboard::event (this=0x700c80, e=<optimized out>)
>      at kernel/qclipboard_x11.cpp:945
> #3  0x00007ffff2f9548c in QApplicationPrivate::notify_helper (address@hidden,
>      address@hidden, address@hidden)
>      at kernel/qapplication.cpp:4570
> #4  0x00007ffff2f9bfa8 in QApplication::notify (this=0x7fffffffd770, 
> receiver=0x700c80,
>      e=0x7fffffffd650) at kernel/qapplication.cpp:4356
> #5  0x00007ffff2a6571d in QCoreApplication::notifyInternal (this=0x7fffffffd770,
>      receiver=0x700c80, address@hidden) at kernel/qcoreapplication.cpp:955
> #6  0x00007ffff2f95ee2 in sendEvent (event=0x7fffffffd650, receiver=<optimized 
> out>)
>      at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
> #7  QApplication::~QApplication (this=0x7fffffffd770, __in_chrg=<optimized out>)
>      at kernel/qapplication.cpp:1111
> #8  0x00007ffff7a4832c in octave_start_gui (argc=3, argv=0x7fffffffdbf8,
>      start_gui=<optimized out>) at ../../libgui/src/octave-gui.cc:117
> #9  0x00007ffff4132b45 in __libc_start_main (main=0x400960<main(int, char**)>, 
> argc=3,
>      argv=0x7fffffffdbf8, init=<optimized out>, fini=<optimized out>,
>      rtld_fini=<optimized out>, stack_end=0x7fffffffdbe8) at libc-start.c:287
> #10 0x00000000004009ef in _start ()
>
> This appears to be the same backtrace I originally reported in #40693.
>
> I am using GNOME 3, it may be something particular in the interaction
> between Qt and GNOME's implementation of the clipboard manager
> interface.
>
> I can force the delay to occur by starting Octave, running "sombrero",
> and using the new Copy feature of the plot window to copy the plot to
> the clipboard. Exiting Octave now shows the delay.
>
> If I run "xsel -bc" back at the bash prompt to clear the desktop
> clipboard buffer, and run Octave again, there is no more delay when it
> exits the next time.
>
> [1] https://savannah.gnu.org/bugs/?40693

That does appear to be the same problem, from what I read.

In the link you provide is another link to the Qt bug report page.  At 
that report page is mentioned how to fix the problem inside Qt itself. 
However, I think it might be possible to just place that suggested code 
inside Octave's GUI exit if that hasn't been done before (i.e., if there 
is an event in the clipboard, handle it).  I'd try doing this, but I'm 
not experiencing the problem on my machine.

The heart of the problem is that X11 doesn't move any data for 
copy/paste until the paste happens.  (It may be more flexible that way, 
i.e., one application may generate content in one of the forms the other 
application indicates it accepts.)  The Desktop will add a clipboard 
manager that actually holds data.  It sounds as though the Desktop 
clipboard manager wants to get the actual data from the GUI before it 
exits...hence the missing communication described in that Qt bug report.

Dan