Subject: RE: FVWM: Premature close of OpenInterface GUI

From: Ryan Daly <[email-masked]>
Date: 18 Dec 2002 20:01:54 -0500

Guys,

I have been experiencing the exact problem that you described in your
various e-mails.

I can't pinpoint what causes the problem, but I experience it quite
often.  It seems that stopping FVWM and restarting will cure the problem
for a bit, but after (something happens) the problem crops up once
again.

The application I started seeing this with is the GUI that accompanies
the EMC Data Manager.  I know immediately if things are working or not
because the window immediately gets closed.  I usually get an error
similar to the following:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  3 (X_GetWindowAttributes)
  Resource id in failed request:  0x2800001
  Serial number of failed request:  921
  Current serial number in output stream:  922

Today I started to attempt to "debug" this, and looked for help on any
debugging options when I came across this thread.  I shut FVWM down and
restarted it.  I stopped and started the application numerous times with
no trouble.  I'm not sure if the number of windows I had open has
anything to do with things or not, but the problem came back after I had
a few XTerms open.  Now that I don't have that many XTerms open, the
problem has gone away (but then again, I have 5 or 6 Mozilla windows
open).

I also saw the same problem with rm6 (release 06.22.01.54).  I just
installed the app today and started to familiarize myself with the it. 
The initial window comes up with no problems.  When I open any of the
other windows (i.e. Configuration, Status, Recovery, etc.) I get the
window, again with no trouble.  That newly created window closes,
however, when I move the mouse over the buttons near the top of the
window (just below the File, Module, Options, Help section).

Both premature closes happen during the same time frame.  Meaning, if I
start the EDM window and it immediately closes, then I can also get rm6
windows to close just by moving the mouse over the buttons, and vice
versa.  If the action is happening with rm6, then the EDM window will
not start.

Once one application starts functioning properly, the other does as
well.

I'm sad to say that for a while I had moved to GNOME because I was not
seeing these problems there.  But I can't handle GNOME any more and
wanted to come back 'home'.

Please let me know what I can do to help track this problem down.

I'm running on Red Hat 7.3 if that matters.

Am I taking the previous e-mails correct when I say that it appears that
these problems do not crop up on :1, and only on :0?

Thanks for helping!

-- 

Ryan Daly
Unix Administrator/Network Engineer
Concurrent Technologies Corporation             (v) 814.269.6889
100 CTC Drive                                   (f) 814.269.2685
Johnstown, PA US 15904-1935

        91 3E E1 09 16 D1 5A 67 1A CA 16 C7 E0 C1 74 72
            ftp.ctcgsc.org:/pub/PGP-keys/daly.asc
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Wed, 18 Dec 2002 21:07:41 -0500

> similar to the following:

Thats pretty strange, any chance EMC Data Manager and rm6 use
the same GUI toolkit?  If you do an ldd on the EMC binary do you
see anything that looks like libndcore, libndvgm?

Note that in the case of rm6, the rm6 was not the binary,
it was just a shell, I had to look in the shell to figure out
what the real name of the binary was.

>   Current serial number in output stream:  922

OK, the application is calling XGetWindowAttributes and
getting a bad window return code.  Ie. the window doesn't
exist.  The window id is 0x2800001.  You can see window
id's with the xwininfo command.  The easiest way is to type:

xwininfo -root -tree

The window id will be different each time you run, so run
this command just before you create the problem.  Then
we should know which window its trying to read the
attributes on that it can't find.

> Please let me know what I can do to help track this problem down.

Well, I think you've given us some useful hints.

> these problems do not crop up on :1, and only on :0?

Strange as it seems, thats what we observed.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: "S. Anderson" <[email-masked]>
Date: Wed, 18 Dec 2002 19:53:33 -0700

> > I have been experiencing the exact problem that you described in your

I too have experienced some problem im not sure its the same...

it is with the GIMP, I can reproduce it by:

1) starting fvwm (cvs version last updated Dec 16 2002) with no rc file
2) open FvwmConsole and start FvwmPager
3) start the gimp (close all of its dialog windows)
4) make sure the gimp window is the last to have focus then go
   to the pager and change to a different page.
5) restart fvwm with the root menu.

after fvwm restarts, the gimp dissapears (no longer listed by ps aux)
and I get this message:

Gdk-ERROR **: BadWindow (invalid Window parameter)
  serial 12833 error_code 3 request_code 15 minor_code 0

I thought this was a gimp/gtk bug, but it seems related to this one.
can any one reproduce this?

gtk-config --version
1.2.10
gimp-config --version
1.2.3
fvwm-config --version
2.5.6
XFree86 Version 4.2.99.2
Linux 2.4.20

thanks,
sa

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 19 Dec 2002 10:55:22 +0100

> can any one reproduce this?

I do think it is a simp/gtk bug and I don't think it is related.
It looks like gtk is fiddling with one of the windows created by
fvwm and does not catch the situation when this window was already
destroyed.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 19 Dec 2002 10:10:01 -0500

Ryan Daly <[email-masked]> writes:
> On Wed, 2002-12-18 at 21:07, Dan Espen wrote:
> Yep, here's the output:

Good, that confirms that the EMC problem is the same problem
as we see with rm6.  Its the same toolkit is being used in
both products.

> : edm 23#; ldd `which edm`
> **      libndvgm.so =>   /usr/epoch/lib/libndvgm.so
...
> I wasn't sure whether you wanted me to run this on the Linux box or on
> the EDM, so I've attached the output from both.  The file names are
> pretty descriptive as to what each file contains.  (Although, if the
> DISPLAY variables are the same, not sure that this really matters
> anyway.)

Run this on the Linux machine, (the display with the problem).

Please send BOTH the error message from EDM and the
xwininfo that existed just before the error message is
generated.  There is a window id in the error message that
I want to find in the xwininfo output.

> I just started :1 and verified things act the same as :0.

I think that shows that the problem has some kind of random
component to it.  The same thing with vmware, its not vmware
itself causing the problem, it just changing something enough
to make this problem start to appear.

---

From: Ryan Daly <[email-masked]>
Date: 19 Dec 2002 09:38:58 -0500

Yep, here's the output:

: edm 23#; ldd `which edm`
        libcdl.so.1 =>   /usr/epoch/lib/libcdl.so.1
        libdbapi.so.1 =>         /usr/epoch/lib/libdbapi.so.1
        libebfs.so.2 =>  /usr/epoch/lib/libebfs.so.2
        libtrail.so.2 =>         /usr/epoch/lib/libtrail.so.2
        librvm.so.1 =>   /usr/epoch/lib/librvm.so.1
        libmedup.so.1 =>         /usr/epoch/lib/libmedup.so.1
        librdb.so.1 =>   /usr/epoch/lib/librdb.so.1
        libepochrpc.so.1 =>      /usr/epoch/lib/libepochrpc.so.1
        libcscomm.so.1 =>        /usr/epoch/lib/libcscomm.so.1
        libcd_api.so.1 =>        /usr/epoch/lib/libcd_api.so.1
        liblogging.so.1 =>       /usr/epoch/lib/liblogging.so.1
        libutil.so.1 =>  /usr/epoch/lib/libutil.so.1
        libeerrno.so.1 =>        /usr/epoch/lib/libeerrno.so.1
        libndscvrb.so =>         /usr/epoch/lib/libndscvrb.so
        libndcoresvr.so =>       /usr/epoch/lib/libndcoresvr.so
        libndgw.so =>    /usr/epoch/lib/libndgw.so
        libndtkit.so =>  /usr/epoch/lib/libndtkit.so
**      libndvgm.so =>   /usr/epoch/lib/libndvgm.so
        libndscrpt.so =>         /usr/epoch/lib/libndscrpt.so
        libndres.so =>   /usr/epoch/lib/libndres.so
        libndcore.so =>  /usr/epoch/lib/libndcore.so
        libndoapom.so =>         /usr/epoch/lib/libndoapom.so
        libndoaba.so =>  /usr/epoch/lib/libndoaba.so
**      libndcorex.so =>         /usr/epoch/lib/libndcorex.so
        libndsec.so =>   /usr/epoch/lib/libndsec.so
        libX11.so.4 =>   /usr/openwin/lib/libX11.so.4
        libXext.so.0 =>  /usr/openwin/lib/libXext.so.0
        libposix4.so.1 =>        /usr/lib/libposix4.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libCrun.so.1 =>  /usr/lib/libCrun.so.1
        libw.so.1 =>     /usr/lib/libw.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libsfp.so =>     /usr/epoch/lib/libsfp.so
        libdbapirpc.so.1 =>      /usr/epoch/lib/libdbapirpc.so.1
        libmvr.so.1 =>   /usr/epoch/lib/libmvr.so.1
        lib_drv.so.1 =>  /usr/epoch/lib/lib_drv.so.1
        lib_devutil.so.1 =>      /usr/epoch/lib/lib_devutil.so.1
        libddl_drive.so.1 =>     /usr/epoch/lib/libddl_drive.so.1
        librwtool.so.2 =>        /usr/epoch/lib/librwtool.so.2
        libintl.so.1 =>  /usr/lib/libintl.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

This is certainly interesting.  I'm sure you'll pick this up by looking
at the xwininfo output I've attached.  This seems to be pretty
consistent.  I'm running VMWare when the problem exists, when I exit
VMWare, the problem goes away.  I don't even have to be running the
virtual machine, either.  I just have to have the initial window up and
running.

The problem with rm6 is when I move over those buttons, it trys to
display pop-up text.  When VMWare is running, it causes the window to
close.  Without VMWare, the window stays up.  Sometimes it loses focus,
but once I move the pointer out and back in again, things are fine from
there on out.

> Well, I think you've given us some useful hints.

Hopefully this helps some more.

-- 

Ryan Daly

---

From: Ryan Daly <[email-masked]>
Date: Thu, 19 Dec 2002 16:26:48 -0500

On Thu, 19 Dec 2002 10:10:01 -0500

> I want to find in the xwininfo output.

There were 4 attachments to the last e-mail.  If they didn't come across
properly, let me know.  But the output from before and after should be
there.

> to make this problem start to appear.

All enough just to make it wonderful to track, huh?

---

From: Dan Espen <[email-masked]>
Date: Thu, 19 Dec 2002 16:45:20 -0500

> properly, let me know.  But the output from before and after should be

There were 4 attachments, but the error message with the windowid
was missing.  I need the windowid of the window, just before the
problem occurs.

Again, I need 2 things, the error message that Fvwm prints,
just before the problem occurs and the xwininfo that goes with
that particular message.

The window id changes every time a window is created, an old
message or xwininfo won't do.  They both have to be from the
same debug session.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 20 Dec 2002 10:23:01 +0100

> properly, let me know.  But the output from before and after should be

Please compress large attachments.  There are people on the list
who dial in with a modem.  Downloading 300k mails is a pain.

Bye

Dominik ^_^  ^_^