Subject: lots of iconify bugs

From: Dominik Vogt <[email-masked]>
Date: Wed, 19 Jan 2000 19:17:47 +0100

Out of boredom is started clicking on one of my FvwmIconMan
buttons - and discovered a host of bugs:

Configuration:

  SloppyFocus
  FvwmAnimate active

 1) Clicking really fast and then waiting for fvwm to catch up:
    my mutt window is sometimes drawn 'hollow', i.e. fvwm thinks
    it's already iconified but still shows the frame (you can even
    shade it).

 2) Very rarely FvwmIconMan just vanishes (i.e. no error message,
    no core dump).  I guess this can happen only happen in
    ReadFvwmPipe() in fvwm.c if ReadFvwmPacket fails.

 3) Then I ran this script:

      # repeat 1000; do FvwmCommand "All iconify on"; FvwmCommand "All (iconic) iconify off"; done

    (try a lower repeat count first!)

    Every few second the cursor changed to the crosshair and the process
    stopped until I clicked anywhere each time this happened, some trash
    appeared in my open FvwmConsole window:

---------------------- snip -----------------------
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'exit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ct'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ify'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'l'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ct'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'fy'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'exit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ct'
[FVWM][FvwmErrorHandler]: <<ERROR>> *** internal error ***
[FVWM][FvwmErrorHandler]: <<ERROR>> Request 12, Error 8, EventType: 0
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'connect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'y'
[FVWM][ExecuteFunction]: <<ERROR>> No such command '@exit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'on'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'exit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ct'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'connect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'y'
[FVWM][FvwmErrorHandler]: <<ERROR>> *** internal error ***
[FVWM][FvwmErrorHandler]: <<ERROR>> Request 12, Error 8, EventType: 0
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ify'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'l'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ct'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'fy'
[FVWM][ExecuteFunction]: <<ERROR>> No such command '(iconic)'
[FVWM][ExecuteFunction]: <<ERROR>> No such command '@exit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command ')'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command '@connect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'fy'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 't'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'y'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'iconic)'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'exit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'y'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'iconic)'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'exit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ct'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'connect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'y'
[FVWM][ExecuteFunction]: <<ERROR>> No such command '@exit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'on'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'conic)'
[FVWM][ExecuteFunction]: <<ERROR>> No such command '@connect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'xit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 't'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'onnect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'off'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'conify'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'exit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'on'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'onic)'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'connect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'it'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'conify'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'nnect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'off'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'onify'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'll'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'xit'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'n'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'nic)'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'onnect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 't'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'onify'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'nect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ff'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'nify'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'l'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'it'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ic)'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'nnect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'nify'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'll'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'f'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ify'
[FVWM][ExecuteFunction]: <<ERROR>> No such command '(iconic)'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 't'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'c)'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'nect'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ify'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'l'
[FVWM][ExecuteFunction]: <<ERROR>> No such command 'ct'
---------------------- snip -----------------------

I'm really worried about (2) and (3). To me it looks like
as if module communication is very broken.  Some of the
commands are mangled ("ify", "conic)", ...), but some
of the strings have never been sent by any module
("@exit", "@connect").  I don't care about the X errors -
they are probably the cause of the selection cursor.

This might also be the reason why e.g. FvwmAuto dies
from time to time for some people.  Possibly this explains
other 'module xyz dies' problems.

Could anybody with better knowledge of the module interface
debug into this?

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [email-masked]
--
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: Dominik Vogt <[email-masked]>
Date: Wed, 19 Jan 2000 19:34:56 +0100

> buttons - and discovered a host of bugs:
... 
>     ReadFvwmPipe() in fvwm.c if ReadFvwmPacket fails.

My guess was wrong.  FvwmIconMan simply gets signal 13
(dead pipe) and returns from the main loop.  I have found
a way to reproduce this over 50% of the time (FvwmAnimate
active):

Click on the button of a maximised rxvt window with a background
pixmap three times in fast succession.  Clicking more often
actually decreases the probability of a dead pipe.  It works
with smaller.  The probability grows with the time X needs to
draw the window.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 19 Jan 2000 20:01:56 +0100

...

>     appeared in my open FvwmConsole window:

More info:

 - I cant make the X error happen again.
 - FvwmAuto dies when I run this command (at least once)!
 - "repeat 100" is enough, but if the repeat count is much
   lower it doesn't happen for me.
 - It happens more often if FvwmAnimate isn't running
   (and of course it's much faster).

Bye

Dominik ^_^

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 20 Jan 2000 07:11:22 -0500

Dominik,

I noticed your commit to functions.c for complex functions that
require select, could a change here be related to the selection cursor
occasionally appearing?

Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
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: Dominik Vogt <[email-masked]>
Date: Thu, 20 Jan 2000 13:27:31 +0100

> require select, could a change here be related to the selection cursor

I don't think so.  My FvwmCommand based test didn't issue
complex functions.  It simply calls 'All'.  I'm quite sure
that the selection cursor appears because the Iconify()
function doesn't find the window it is asked to operate on.
Or perhaps it's called with tmp_win = NULL.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 21 Jan 2000 00:36:32 +0100

>     appeared in my open FvwmConsole window:

I'm fairly sure where the problems come from.  Consider this
code from My_NextXEvent() (event.c):

    if (read(readPipes[i], &targetWindow, sizeof(Window)) > 0) {
          DBUG("My_XNextEvent","calling HandleModuleInput");
          HandleModuleInput(targetWindow, i, NULL);
    } else {
          DBUG("My_XNextEvent","calling KillModule");
          KillModule(i);
    }

With pipes there is no guarantee that any bytes can be
successfully read.  The reason is that the read may be
interrupted. In this case read returns zero and sets
errno to EINTR.  Also, according to the Linux man page
an EIO error may be caused by disk or tape activity:

       EINTR   The call was interrupted by a  signal  before  any
               data was read.

       EIO     I/O  error.  This will happen for example when the
               process is in a background process group, tries to
               read  from  its  controlling tty, and either it is
               ignoring or blocking SIGTTIN or its process  group
               is  orphaned.   It  may also occur when there is a
               low-level I/O error while reading from a  disk  or
               tape.

So we can't simply kill the module when nothing was read
although the FD_ISSET signaled a change.  Furthermore
I guess it's possible that only a part of the input has
been read.  In this case we must keep reading until a
line end is found (or the pipe dies).

So, what is the right fix for this?  Would this logic
work 100% of the time:

  bytes_to_read = sizeof(Window);
  while (bytes_to_read)
  {
    int i;

    i = read(..., ..., bytes_to_read);
    if (i > 0)
    {
      bytes_to_read -= i;
      if (bytes_to_read == 0)
      {
         /* okay */ ...
      }
      else
      {
        continue; /*reading*/
      }
    }
    else if (errno == EIO || errno == EINTR)
    {
      continue; /*reading*/
    }
    else
    {
      /* kill the module */ ...
    }
  }

...

> they are probably the cause of the selection cursor.

The @exit and @connect come from FvwmCommand communicating
with FvwmCommandS

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Thu, 20 Jan 2000 19:38:13 -0500

> So, what is the right fix for this?  Would this logic

I wasn't aware there was any module reading taking place in event.c,
the logic to handle EINTR is in module_interface.c.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Chris Rankin <[email-masked]>
Date: Fri, 21 Jan 2000 20:26:55 +1100 (EST)

>                low-level I/O error while reading from a  disk  or

If the read() is interrupted (before it has read any data) then it
returns -1, but the OS will restart the read anyway if the relevant
signal handler is installed SA_RESTART.

I shall modify FvwmAuto so use SA_RESTART instead of SA_INTERRUPT,
hoping that other systems (like Linux) ALWAYS allow select() to be
interrupted. Maybe this will solve the inexplicable-exit bug?

Chris.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 21 Jan 2000 10:59:39 +0000

> >       # repeat 1000; do FvwmCommand "All iconify on"; FvwmCommand "All (iconic) iconify off"; done
Could your problems be due to using FvwmCommand? It uses a pipe to get
the the FvwmCommandS server.  Does the same thing happen with FvwmPipe?
What if you write a function that does the same thing and run it from
FvwmTalk?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 21 Jan 2000 13:33:04 +0100

> interrupted. Maybe this will solve the inexplicable-exit bug?

No, I think the reason why FvwmAuto exits is that fvwm terminates
the connection when it reads no bytes from the pipe as I described
above.  Before we fix FvwmAuto we have to fix fvwm.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 21 Jan 2000 16:19:21 +0100

> the logic to handle EINTR is in module_interface.c.

You're right, there is some code to handle EINTR and a few other
signals there, but only when writing to the pipes.  All read()
calls I found in module_interface.c don't handle any error
codes.  The module is simply killed if not enough bytes are
read.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 21 Jan 2000 17:54:32 +0100

> interrupted. Maybe this will solve the inexplicable-exit bug?

Chris,

the patch you made to fvwm.c didn't help.  fvwm still kills my
FvwmIconMan.

BTW, this all happens only on one of my Linux machines
(both SuSE 6.2, Kernerl 2.2.10).

Bye

Dominik ^_^

---

From: Chris Rankin <[email-masked]>
Date: Sat, 22 Jan 2000 09:53:58 +1100 (EST)

> the patch you made to fvwm.c didn't help.  fvwm still kills my

Interesting - in an infuriating sort of way. Calls to read() and
write() on pipes should now be immune to the effects of passing
signals in both fvwm and in FvwmIconMan. And I am running Linux 2.2.14
and have *never* had FvwmIconMan die on me - it sits happily in my
button - bar. Can you provide any information about which code path
fvwm is taking when it kills it?

Chris

---

From: "Paul D. Smith" <[email-masked]>
Date: 21 Jan 2000 18:08:35 -0500

>> the patch you made to fvwm.c didn't help.  fvwm still kills my

  cr> Interesting - in an infuriating sort of way. Calls to read() and
  cr> write() on pipes should now be immune to the effects of passing
  cr> signals in both fvwm and in FvwmIconMan. And I am running Linux
  cr> 2.2.14 and have *never* had FvwmIconMan die on me - it sits
  cr> happily in my button - bar. Can you provide any information about
  cr> which code path fvwm is taking when it kills it?

I think we need to investigate the logic more thoroughly.  There can be
subtle weirdness in signal handling and interrupts.

I believe this problem is the same or similar to the issue of FvwmAuto
dying.  I've had it happen (very rarely, like once a month) for a while
now on both Solaris and Linux, both of which should be well-behaved
(read, POSIX-compliant) for signal handling.

Recall that one of the first bugs in the bug DB is my description of the
problem that used to cause FvwmAnimate's configure tools to choke (this
was fixed by working around the problem).  Don't know if it's related.

It may be time to re-examine and maybe even rewrite the module messaging
logic... :-/.

At any rate, some systems don't "do" SA_INTERRUPT and SA_RESTART, so
those should be autoconf'd unless we want to forget supporting
non-POSIX-y things like SunOS 4.x.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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: Chris Rankin <[email-masked]>
Date: Sat, 22 Jan 2000 10:16:17 +1100 (EST)

> non-POSIX-y things like SunOS 4.x.

The SA_RESTART code is always used as:

#ifdef SA_RESTART
  sigact.sa_flags = SA_RESTART;
#else
  sigact.sa_flags = 0;
#endif

I take this to mean that "restart" semantics are the default if
SA_RESTART is not defined. It's admittedly ugly; autoconf-ing would
probably be a good thing here.

Chris.

---

From: "Paul D. Smith" <[email-masked]>
Date: 21 Jan 2000 20:46:30 -0500

>> non-POSIX-y things like SunOS 4.x.

  cr> The SA_RESTART code is always used as:

  cr> #ifdef SA_RESTART
  cr>   sigact.sa_flags = SA_RESTART;
  cr> #else
  cr>   sigact.sa_flags = 0;
  cr> #endif

  cr> I take this to mean that "restart" semantics are the default if
  cr> SA_RESTART is not defined. It's admittedly ugly; autoconf-ing would
  cr> probably be a good thing here.

The bad news is that some older hosts don't support sigaction() at all.

And even some that do support sigaction() don't support restartable
system calls.  I'm at home and my POSIX stuff is at work but IIRC POSIX
doesn't require this.

IOW, you can't just set SA_RESTART and not worry about EINTR, if you
want to be portable.  I haven't looked at the code itself so I'm not
saying you did that :).

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 24 Jan 2000 14:42:41 +0100

> fvwm is taking when it kills it?

It happens in module_interface.c, PositiveWrite().  The write() call
returns -1 with errno == EAGAIN.  There are lots of places in
module_interface.c where the module is called when any error occurs
in a read() or write() call. Same in events.c.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 24 Jan 2000 17:14:14 +0100

> It happens in module_interface.c, PositiveWrite().  The write() call
                                                          ^^^^^^^

Replace this with 'read()'

> in a read() or write() call. Same in events.c.

Ignonre the part about write().  I need glasses :-)

Bye

Dominik ^_^

---

From: Chris Rankin <[email-masked]>
Date: Tue, 25 Jan 2000 08:03:01 +1100 (EST)

> Ignonre the part about write().  I need glasses :-)

OK; EAGAIN in a read() means that it tried to read data but there
wasn't anything there to read (and that the descriptor was
non-blocking). So the questions are "why did fvwm think there was
something to read?", and "where did this something go?".

Chris.

---

From: Chris Rankin <[email-masked]>
Date: Tue, 25 Jan 2000 07:54:50 +1100 (EST)

> in a read() or write() call. Same in events.c.

EAGAIN in a write() means that the pipe is temporarily too full to
accept any more data. Is the pipe descriptor non-blocking? Does it
need to be? If so then we need to embed this write() in a loop with
fvwmSelect() so that we can check for "writability", alternately
sleeping and writing untill the entire message has been sent.

Chris.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 25 Jan 2000 12:08:43 +0100

> something to read?", and "where did this something go?".

Here is a stack trace forced with abort() in PositiveWrite:

---
#0  0x4013aab1 in __kill () from /lib/libc.so.6
#1  0x4013a6bf in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x4013bef3 in abort () at ../sysdeps/generic/abort.c:88
#3  0x8073370 in PositiveWrite (module=6, ptr=0xbfffe86c, size=60)
    at module_interface.c:1219
#4  0x8072720 in BroadcastPacket (event_type=256, num_datum=11)
    at module_interface.c:777
#5  0x80711db in Iconify (tmp_win=0x80c54a0, def_x=351, def_y=711)
    at icons.c:1229
#6  0x80713f7 in iconify_function (eventp=0x8092e60, w=58720258, 
    tmp_win=0x80c54a0, context=1, action=0x80cc537 "", Module=0xbfffedc4)
    at icons.c:1329
#7  0x8076575 in ExecuteFunction (Action=0xbfffedf8 "Iconify", 
    tmp_win=0x80c54a0, eventp=0x8092e60, context=1, Module=6, 
    expand_cmd=EXPAND_COMMAND) at functions.c:821
#8  0x807241c in HandleModuleInput (w=58720258, channel=6, expect=0x0)
    at module_interface.c:618
#9  0x805e2c0 in My_XNextEvent (dpy=0x80943e8, event=0x8092e60)
    at events.c:2257
#10 0x805b618 in HandleEvents () at events.c:243
#11 0x805f56f in main (argc=3, argv=0xbffff754) at fvwm.c:707
---

So, fvwm simply sent an 'M_ICONIFY' packet to the window via
PositiveWrite (indirectly).  PositiveWrite expects some kind
of answer if the module asked for synchronised transmission.
This answer doesn't arrive on the first attempt.  Above the
faulty code I there is a comment:

  /* dje, from afterstep, for FvwmAnimate, allows modules to sync with fvwm.
   * this is disabled when the server is grabbed, otherwise deadlocks happen.
   * M_LOCKONSEND has been replaced by a separated mask which defines on
   * which messages the fvwm-to-module communication need to be lock
   * on send. olicha Nov 13, 1999 */

Dan, Olivier - any more insights on this problem?

Bye

Dominik ^_^

---

From: Chris Rankin <[email-masked]>
Date: Tue, 25 Jan 2000 22:36:56 +1100 (EST)

OK, here is the code-fragment. It looks as if it is trying to *disable*
non-blocking IO on the pipe descriptor, which implies that it doesn't
expect to receive EAGAIN. However, Dominik, didn't you say that EAGAIN
is the whole problem? This therefore implies that the fcntl() call is
failing - the error code here is being silently thrown away and so
no-one notices. Finally, the codes tries to reinstate non-blocking
mode.

    int e;

    FlushQueue(module);
    fcntl(readPipes[module],F_SETFL,0);
    while ((e = read(readPipes[module],&targetWindow, sizeof(Window))) > 0) {
      if (HandleModuleInput(targetWindow, module, NULL) == 66) {
        break;
      }
    }
    if (e <= 0) {
      KillModule(module);
    }
    fcntl(readPipes[module],F_SETFL,O_NDELAY);

Rather than switch between blocking and non-blocking modes, (which
doesn't seem to be working), maybe we should try fvwmSelect()? To the
people who are seeing modules die suddenly on them: are you running
fvwm on a particularly speedy processor? It looks like fvwm's is
reaching the read() before the module can write().

Chris.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 25 Jan 2000 16:14:40 +0100

> reaching the read() before the module can write().

I've spent the morning tracing the problem.  It looks really strange.
My latest debug code modified PositiveWrite like this:

----------------------
int foo = 0;
int PositiveWrite(int module, unsigned long *ptr, int size)
{
...
  if ((SyncMask[module] & ptr[1]) && !myxgrabcount)
  {
    Window targetWindow;
    int e;

int finished = 0;
int rc;
fprintf(stderr, "\n\n+++ 1\n");
    FlushQueue(module);
    fcntl(readPipes[module],F_SETFL,0);
    {
      while(!finished)
      {
foo = 1;
fprintf(stderr, "+++ 2\n");
        while ((e = read(readPipes[module],&targetWindow, sizeof(Window))) > 0)
        {
fprintf(stderr, "+++ 3\n");
          if ((rc = HandleModuleInput(targetWindow, module, NULL)) == 66)
          {
fprintf(stderr, "+++ 4\n");
finished = 1;
            break;
          }
fprintf(stderr, "+++ 5\n");
        }
fprintf(stderr, "+++ 6: e=%d,f=%d,foo=%d\n", e, finished,foo);
        if (e <= 0)
        {
fprintf(stderr, "+++ 7\n");
          KillModule(module);
finished = 1;
        }
      }
    }
fprintf(stderr, "+++ 8: done\n");
foo=0;
    fcntl(readPipes[module],F_SETFL,O_NDELAY);
return size;
  }
  return size;
}
----------------------

When the problem shows up I get this output:

+++ 1
+++ 2
+++ 3
+++ 4
+++ 6: e=4,f=1,foo=1
+++ 8: done
*
+++ 5
+++ 6: e=-1,f=0,foo=0
+++ 7
pipeName = FvwmIconMan
+++ 8: done

So at first the function runs through (123468) and exits properly
(it got the 'Unlock' it was waiting for).  The '*' is printed
in the parent function (BraodcastPacket) right after the PositiveWrite
call.  But then execution continues at (5) without passing (1) to (4)!!!
The value of the global variable 'foo' proves that somehow the
program counter jumped into the mid of the function.

I tried this with egcs-2.91.66 and gcc 2.7.2.3 and both show the
same problem (gcc 2.7.2.3 works for me at home).  Thus I assume
it must be a stack problem.  If I only could predict when this
happens.  Then I could set a breakpoint and fire up the debugger
when it happens.

Bye

Dominik ^_^

---

From: Chris Rankin <[email-masked]>
Date: Wed, 26 Jan 2000 08:20:38 +1100 (EST)

> happens.  Then I could set a breakpoint and fire up the debugger

Sounds like a job for "Purify". However, you seem to have changed the
code quite a bit and yet still got the same buggy behaviour rather
than a SIGILL, core-dump, for instance. Doesn't this imply that the
problem is extremely local? There are so many variable-arguments
functions in module_interface.c that maybe one of them has gone
hopelessly wrong and the compiler is unable to spot it?

Chris.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 26 Jan 2000 12:15:04 +0100

> hopelessly wrong and the compiler is unable to spot it?

I'm still strugglinjg to identify the problem, but in the mean
time I'm convinced that there is no stack corruption.  I
suspect nested handling of module input to be the culprit, but
I don't yet understand my debug output.  Will need at least one
more day to debug this.  The current theory is that either
fvwm tries to sync a packet transmission when it shouldn't
or that a non-sync'ed packet eats away the 'Unlock' message.
Dan, can you think of a situation where this happens?

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 26 Jan 2000 08:31:59 -0500

> Dan, can you think of a situation where this happens?

The code  has  changed since  the original  lockonsend  change, but it
looks to me like synchonous  read-write is the same as non-synchronous
except that fvwm waits for a response after a write.

I don't see how that explains the symptoms.

I'm not that clear on all the symptoms you've described, it might help
to restate them.

The one symptom you reported about bad execution flow, still sounds
to me like a compiler bug.  Have you looked at the generated code?

In general, fvwm closes a pipe on a non-zero return code to a read
or write.  Are we seeing the actual errno in all cases?

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 26 Jan 2000 16:35:19 +0100

> I'm not that clear on all the symptoms you've described, it might help

Okay.  Forget everything about code flow.  It's correct.
It is possible that PositiveWrite calls itself via
HandleModuleInput(). Hence the 'mysterious' flow.

My preliminary analysis of the situation is this:

 - By clicking fast on the button in IconMan I manage to
   trigger multiple 'iconify' and 'deiconify' requests
   before fvwm answers (because while the first 'iconify'
   is processed, FvwmAnimate freezes the X server).

 - Then, while fvwm is processing the second request,
   it sends e.g. M_ICONIFY and waits for an 'Unlock'
   from FvwmIconMan, but it reads the next 'iconify'
   request first.  Thus, PositiveWrite calls
   HandleModuleInput to properly handle the request.

 - The recursive call executes (De)Iconify() again which
   in turn calls BroadcastPacket and thus PositiveWrite
   to send another M_(DE)ICONIFY.  This happens multiple
   times.  Several packets require an 'unlock' before
   continuing.

 - ... I'm not sure what exactly happens then ...

 - ... but when finally all recursive calls of HandleModuleInput
   have returned, the 'Unlock' we have been waiting for in the
   first place has already been read off the pipe.  Therefore
   read() finally returns with EAGAIN (i.e. the pipe is empty).

==> Somewhere one 'Unlock' message is read and thrown away
    where it shouldn't.

I'm still struggling to identify all the packets that are
broadcast and to find the place where 'Unlock' is accidentally
dropped.

Bye

Dominik ^_^

---

From: "Paul D. Smith" <[email-masked]>
Date: 26 Jan 2000 10:56:02 -0500

Something that I've found helpful for this kind of debugging is to keep
a counter that goes up every time you enter the function and down when
you exit it; then prefix all debugging messages with that counter.  You
can decipher the "depth" of the stack that way.  You can also use
indentation; set a string to N spaces according to the depth and print
that string before the debugging message to indent it.  This makes it
simple to see.

Also, a monotonically increasing counter (once per function call) can
help figure this stuff out; match the lines with the same counter
value.

I'm sure you've used these before too, so just ignore me... :)

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 26 Jan 2000 17:48:16 +0100

I still get the effects described in (1) and (3).  The next problem
to focus on is (3).

On Wed, Jan 19, 2000 at 07:17:47PM +0100, [email-masked] wrote:
...
> Configuration:
doesn't matter
>     ReadFvwmPipe() in fvwm.c if ReadFvwmPacket fails.

This is finally fixed.  The cause was that due to some
synchronisation problem FvwmIconMan didn't get the chance
to send back the 'Unlock' in time.  A simple 'usleep(1)'
fixes that problem.

>       # repeat 100; do FvwmCommand "All iconify on"; FvwmCommand "All (iconic) iconify off"; done
> 
...
...

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 27 Jan 2000 01:09:12 +0100

> that string before the debugging message to indent it.  This makes it

Yes, exactly what I did :-)

> I'm sure you've used these before too, so just ignore me... :)

:-)

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 27 Jan 2000 18:06:07 +0100

>     appeared in my open FvwmConsole window:

With my latest patches, all the bugs in this thread are fixed :-)

Bye

Dominik ^_^

---

From: "Paul D. Smith" <[email-masked]>
Date: 27 Jan 2000 14:42:39 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> With my latest patches, all the bugs in this thread are fixed :-)

Based on what you changed, do you think it might solve the "FvwmAuto
dying" problem too?

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 31 Jan 2000 12:16:57 +0100

> Based on what you changed, do you think it might solve the "FvwmAuto

I'm not sure.  I may be incorrect, but I remember that someone said that
FvwmAuto crashes while the system is idle.  In this case the patch
definitely won't help.  But on the other hand my memory may be failing
me.  Let's try it out.

Bye

Dominik ^_^