Subject: FvwmAnimate being killed

From: Tim Phipps <[email-masked]>
Date: Fri, 15 Dec 2000 09:44:43 +0000

Configuration Information [Automatically generated, do not change]:
uname output: SunOS silver 5.5.1 Generic_103640-34 sun4u sparc SUNW,Ultra-5_10
Compiler: gcc
Compilation CFLAGS: -g -O2
prefix: /u/phippst/sunos

FVWM Version:	2.3.26
FVWM_MODULEDIR:	/u/phippst/sunos/libexec/fvwm/2.3.26
FVWM_DATADIR:	/u/phippst/sunos/share/fvwm
FVWM_USERDIR:	/u/phippst/.fvwm

Description:
	FvwmAnimated gets killed (no core, maybe by fvwm) with the following
	in the log file:

grab_stats (grabbed): 1 0 0 1 0 0 0 
grab_stats (-ungrab): 0 0 0 0 0 0 0 
grab_stats (grabbed): 1 0 0 1 0 0 0 
grab_stats (-ungrab): 0 0 0 0 0 0 0 
[FVWM][Echo]:  SendToModule FvwmAnimate animate 642 62 638 473 961 298 2 2
[FVWM][PositiveWrite]: <<ERROR>> Failed to read descriptor:
- data available=Y
- terminate signal=N
	
	I don't know if the "grab_stats" lines are related to this.
	
Repeat-By:
	Sorry if this is a bit complex but it's how I do my window death
	spiral:

*FvwmAnimateEffect Frame
*FvwmAnimateIterations 25
*FvwmAnimateTwist 1.0
*FvwmAnimateDelay 10
*FvwmAnimateWidth 4
*FvwmAnimatePixmap resize.rainbow.xpm

*FvwmEventPassId
*FvwmEvent destroy_window my_zap_event

Key Pause       A       N       my_kill

DestroyFunc my_kill
AddToFunc my_kill 
+ I DestroyFunc my_zap_anim
+ I PipeRead "bash -c 'echo AddToFunc my_zap_anim I echo SendToModule FvwmAnimate animate $[w.x] $[w.y] $[w.width] $[w.height] $(($[w.x] + $[w.width] / 2)) $(($[w.y] + $[w.height] / 2)) 2 2'"
+ I PipeRead "bash -c 'echo AddToFunc my_zap_anim I SendToModule FvwmAnimate animate $[w.x] $[w.y] $[w.width] $[w.height] $(($[w.x] + $[w.width] / 2)) $(($[w.y] + $[w.height] / 2)) 2 2'"
+ I DestroyFunc my_zap_event
+ I AddToFunc my_zap_event I my_zap_test $$0 $w
+ I Close

# dummy placeholder
DestroyFunc my_zap_event
AddToFunc my_zap_event 
+ I NOP

# this is called from my_zap_event after a window has been closed with my_kill
# $0 is decimal, $1 is hex but bash comes to the rescue with the maths test construct
# so only the window closed with my_kill get animated
DestroyFunc my_zap_test
AddToFunc my_zap_test 
+ I PipeRead "bash -c '(($0 == $1)) && echo my_zap_anim'"
--
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: Sun, 17 Dec 2000 01:46:35 +0100

> 	I don't know if the "grab_stats" lines are related to this.

No, this is more likely related to signal handling.  Chris?

> + I PipeRead "bash -c '(($0 == $1)) && echo my_zap_anim'"

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: Dominik Vogt <[email-masked]>
Date: Sat, 23 Dec 2000 01:37:13 +0100

> [FVWM][PositiveWrite]: <<ERROR>> Failed to read descriptor:

To reproduce this, the easy way is:

  addtofunc foo
  + i piperead "sh -c 'echo SendToModule FvwmAnimate animate 0 247 492 342 246 418 2 2'"

then start FvwmAnimate and run 'foo'.  FvwmAnimate gets killed
about 90% of the time.  The output from fvwm comes from this
code (module_interface.c, around line 1305):

  if ((SyncMask[module] & ptr[1]))
  {
    Window targetWindow;
    fd_set readSet;
    struct timeval timeout;
    int channel = readPipes[module];

    FlushMessageQueue(module);

    FD_ZERO(&readSet);
    do
    {
      /*
       * We give the read a long timeout; if the module fails to
       * respond within this time then it deserves to be KILLED!
       *
       * NOTE: rather than impose an arbitrary timeout on the user,
       *       we will make this a configuration parameter.
       */
      timeout.tv_sec = moduleTimeout;
      timeout.tv_usec = 0;
      FD_SET(channel, &readSet);

->    /* Wait for input to arrive on just one descriptor, with a timeout */
->    /* (fvwmSelect <= 0) or read() returning wrong size is bad news */
->    if ((fvwmSelect(channel + 1, &readSet, NULL, NULL, &timeout) <= 0)
->        || (read(channel, &targetWindow, sizeof(targetWindow))
->            != sizeof(targetWindow)))
->    {
->      /* Doh! Something has gone wrong - get rid of the offender!! */
->      fvwm_msg(ERR, "PositiveWrite",
->               "Failed to read descriptor:\n"
->               "- data available=%c\n"
->               "- terminate signal=%c\n",
->               (FD_ISSET(channel, &readSet) ? 'Y' : 'N'),
->               isTerminated ? 'Y' : 'N');
->      KillModule(module);
->      break;
->    }

      /* Execute all messages from the module until UNLOCK is received
       * N.B. This may cause recursion if a command results in a sync message
       * to another module, which in turn may send a command that results in
       * another sync message to this module.

       * Hippo: I don't think this will cause deadlocks, but the third time we
       * get here the first times UNLOCK will be read and then on returning up
       * the third level UNLOCK will be read at the first level. This could be
       * difficult to fix without turning queueing on.  Turning queueing on
       * may be bad because it can be useful for modules to be able to inject
       * commands from modules in a synchronous manner. e.g. FvwmIconMan
       * can tell FvwmAnimate to do an animation when a window is de-iconified
       * from the IconMan, queueing make s this happen too late.
       */
    }
    while (!HandleModuleInput(targetWindow, module, ModuleUnlock, False));
  }

A perror() call reveals that either the select() or read() call
failed because of 'Interrupted system call'.  This only happens if
the sendtomodule command is read via piperead.

  addtofunc foo
  + i SendToModule FvwmAnimate animate 0 247 492 342 246 418 2 2

works well.  (If the 'sh -c' is omitted, it still happens, but
much less frequently for me - probably timing related).

Further investigation reveals that select() failed with EINTR.
I don't have the slightest idea why, but it must be related to the
piperead process.  I have made a patch that retries the select()
call (with a fresh timeout) if it failed.  But since I don't know
much about select wrt signal handling I'd be grateful if somebody
else takes a look at this.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 23 Dec 2000 02:04:21 +0100

>   + i piperead "sh -c 'echo SendToModule FvwmAnimate animate 0 247 492 342 246 418 2 2'"

I do not know why this happen. I can just say that similar errors arise
with fvwm-themes when using the luthien or the cde colors scheme (these
FvwmTheme config files are read via FvwmM4 in a locked way, I can send 
more details but the FvwmAnimate example seems better to work with).
In this case FvwmTheme die with a "Failed to read descriptor" error.
The only interesting thing I can say is that these errors do not
happen with fvwm-2.3.23.

Olivier

---

From: Chris Rankin <[email-masked]>
Date: Sat, 23 Dec 2000 14:21:22 +1100 (EST)

> else takes a look at this.

It must be a SIGCHLD signal from when the pipe process dies. That's
fine, but we can't just retry the select() because somebody might have
sent us a SIGTERM instead and be waiting for FVWM to die. I have
modified the loop to check the "isTerminated" flag as well, and also
modified fvwmSelect so that it always sets errno correctly.

Chris