Re: Sometimes windows remain after the process has died.

[Vincent Lefevre]

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=100863

I've reported a bug upstream (I've searched among open/closed bugs
containing "window" and couldn't find one already reported):

  https://bugs.freedesktop.org/show_bug.cgi?id=100863

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Sometimes windows remain after the process has died.

[Vincent Lefevre]

Hi,

On 2017-04-27 17:00:33 -0600, Jaimos Skriletz wrote:
> On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt  wrote:
> >  2) the X server has a bug,
> 
> This does seem to be the case. The user and myself both tested this
> running an xsession with only an xterm. We could not reproduce it with
> only running an xterm.

I can reproduce it with just an xterm called from my .xsession file.
Not sure what you mean by "only running an xterm".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Sometimes windows remain after the process has died.

[Jaimos Skriletz]

On Thu, Apr 27, 2017 at 5:09 PM, Dominik Vogt  wrote:

> On Thu, Apr 27, 2017 at 05:00:33PM -0600, Jaimos Skriletz wrote:
> > On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt 
> wrote:
> > > On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote:
> > >> Sometimes when a process stops the window will remain open until some
> > >> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
> > >> will remove the window.
> > >
> > > That is not possible unless either
> > > ...
> >
> > The process do not appear in 'ps fax' and the script outputs [Done] on
> > all the jobs that were run in the background in the shell, so this is
> > not the case.
> >
> > >  2) the X server has a bug,
> >
> > This does seem to be the case. The user and myself both tested this
> > running an xsession with only an xterm. We could not reproduce it with
> > only running an xterm.
> >
> > I decided to test another window manager, openbox in this case, and
> > was able to reproduce the issue in openbox. So it seems to be some bug
> > with how the xserver but may require a window manager to trigger it.
>
> I wonder what that trigger could be.  If the window can be moved,
> fvwm is communicating with the X server in both directions, so if
> a destroy event was pending it should have been delivered to fvwm
> before any mouse motion events.  Maybe the X server itself has
> destroyed the window internally but not yet sent the event for
> some reason, and does so only when some request for that window is
> issued.  (Moving the fvwm window does not move the client window
> directly but the frame.)
>
> If you type "xsync" in FvwmConsole, does that kill the window?
> (This forces all pending requests and events to be delivered in
> both directions.)  My guess is that it doesn't, i.e. no event is
> pending.
>
>
​Typing xsync into FvwmConsole did not trigger the removal of the windows.
​

> > In all cases trying to get any info from the xserver closes the
> > windows. I have tried xprop, xwinfo and even just xdpyinfo and xvinfo
> > will close all the windows that were left open when running that
> > command.
>
> Does it also kill the window to request information from a
> different (non-zombie) window?
>
>
​It kills them before I even get a chance to pick the window to identify. I
am not able to find away to get any info on the zombie windows, as soon as
I query xorg with xprop or xwinfo, all zombie windows are removed, then it
gives me a pointer to pick a window. If I use FvwmIconMan (which still has
the windows) to Identify via FvwmIdent (using the window ops menu), the
windows disappear and I get no output from FvwmIdent. No errors in
.xsession-errors either.

jaimos

Re: Sometimes windows remain after the process has died.

[Dominik Vogt]

On Thu, Apr 27, 2017 at 05:00:33PM -0600, Jaimos Skriletz wrote:
> On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt  wrote:
> > On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote:
> >> Sometimes when a process stops the window will remain open until some
> >> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
> >> will remove the window.
> >
> > That is not possible unless either
> > ...
> 
> The process do not appear in 'ps fax' and the script outputs [Done] on
> all the jobs that were run in the background in the shell, so this is
> not the case.
> 
> >  2) the X server has a bug,
> 
> This does seem to be the case. The user and myself both tested this
> running an xsession with only an xterm. We could not reproduce it with
> only running an xterm.
> 
> I decided to test another window manager, openbox in this case, and
> was able to reproduce the issue in openbox. So it seems to be some bug
> with how the xserver but may require a window manager to trigger it.

I wonder what that trigger could be.  If the window can be moved,
fvwm is communicating with the X server in both directions, so if
a destroy event was pending it should have been delivered to fvwm
before any mouse motion events.  Maybe the X server itself has
destroyed the window internally but not yet sent the event for
some reason, and does so only when some request for that window is
issued.  (Moving the fvwm window does not move the client window
directly but the frame.)

If you type "xsync" in FvwmConsole, does that kill the window?
(This forces all pending requests and events to be delivered in
both directions.)  My guess is that it doesn't, i.e. no event is
pending.

> In all cases trying to get any info from the xserver closes the
> windows. I have tried xprop, xwinfo and even just xdpyinfo and xvinfo
> will close all the windows that were left open when running that
> command.

Does it also kill the window to request information from a
different (non-zombie) window?

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Re: Sometimes windows remain after the process has died.

[Jaimos Skriletz]

On Thu, Apr 27, 2017 at 4:21 PM, Dominik Vogt  wrote:
> On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote:
>> Sometimes when a process stops the window will remain open until some
>> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
>> will remove the window.
>
> That is not possible unless either
>
>  1) the process is not really dead,

The process do not appear in 'ps fax' and the script outputs [Done] on
all the jobs that were run in the background in the shell, so this is
not the case.

>  2) the X server has a bug,

This does seem to be the case. The user and myself both tested this
running an xsession with only an xterm. We could not reproduce it with
only running an xterm.

I decided to test another window manager, openbox in this case, and
was able to reproduce the issue in openbox. So it seems to be some bug
with how the xserver but may require a window manager to trigger it.

In all cases trying to get any info from the xserver closes the
windows. I have tried xprop, xwinfo and even just xdpyinfo and xvinfo
will close all the windows that were left open when running that
command.

Thanks for the help, I will forward this bug on to xorg as it affects
more than just fvwm.

jaimos

Re: Sometimes windows remain after the process has died.

[Dominik Vogt]

On Thu, Apr 27, 2017 at 11:04:14AM -0600, Jaimos Skriletz wrote:
> Sometimes when a process stops the window will remain open until some
> event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
> will remove the window.

That is not possible unless either

 1) the process is not really dead,
 2) the X server has a bug,
 3) fvwm does not destroy the frame after the window has gone.

I've spent lots of time to get rid of any cases of #3, and what
you describe does not sound like "empty frame remains".

> The following script was provided by the user which launches and
> closes a large number of xterms. When running this script some of the
> xterm windows will remain even though the process is no longer
> running.
> 
> On Wed, Apr 26, 2017 at 6:13 PM, Vincent Lefevre  wrote:
> > Simpler test case:
> >
> > 
> > #!/bin/sh
> >
> > n=${1:-200}
> > n=$((n+0))
> >
> > for i in `seq $n`; do xterm -geometry 80x24+$((2*i))+$((2*i)) -e true & done
> >
> > wait
> > 

That's how I've tested that the frame always gets removed.

> After this script ends a few windows remain and can be moved,
> iconified, shaded, resized. But if you run FvwmIdent something is
> triggered which removes all the affected windows.
> 
> I was not able to reproduce this on my main machine (though rarely I
> would have a window stick around for a second or two before it was
> removed, most weren't even drawn), but I was able to reproduce this
> with the default config on both the debian 2.6.7-3 package and the
> master branch from git inside a virtual machine.

Maybe it's a problem with the X server in a virtual machine?  I
don't have such a setup to test that, but it doesn't happen on a
plain X server with or without config and neither in Xnest for me.


Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Sometimes windows remain after the process has died.

[Jaimos Skriletz]

Hello,

This was reported by a Debian user. Please retain the CC to
855206-forwar...@bugs.debian.org in your response, so that
the Debian BTS has a record.

Sometimes when a process stops the window will remain open until some
event is triggered in fvwm (in my test I use FvwmIdent) in which fvwm
will remove the window.

The following script was provided by the user which launches and
closes a large number of xterms. When running this script some of the
xterm windows will remain even though the process is no longer
running.

On Wed, Apr 26, 2017 at 6:13 PM, Vincent Lefevre  wrote:
> Simpler test case:
>
> 
> #!/bin/sh
>
> n=${1:-200}
> n=$((n+0))
>
> for i in `seq $n`; do xterm -geometry 80x24+$((2*i))+$((2*i)) -e true & done
>
> wait
> 

After this script ends a few windows remain and can be moved,
iconified, shaded, resized. But if you run FvwmIdent something is
triggered which removes all the affected windows.

I was not able to reproduce this on my main machine (though rarely I
would have a window stick around for a second or two before it was
removed, most weren't even drawn), but I was able to reproduce this
with the default config on both the debian 2.6.7-3 package and the
master branch from git inside a virtual machine.

thanks for your time,

jaimos