Subject: Purify test

From: "Paul D. Smith" <[email-masked]>
Date: Wed, 18 Nov 1998 16:39:55 -0500 (EST)

I started to run the purify test, but it hangs forever for me when
trying to execute this line in the sample .fvwm2rc:

  piperead cat

The stack trace is:

#3  0xef2d77dc in fgets ()
#4  0x6e498 in ReadSubFunc (eventp=0xa1238, junk=42, tmp_win=0x0, context=8, 
    action=0x1 <Address 0x1 out of bounds>, Module=0xeffff18c, piperead=1)
    at ../../fvwm/fvwm/read.c:162
#5  0x6e714 in PipeRead (eventp=0xa1238, junk=42, tmp_win=0x0, context=8, 
    action=0x1154c1 "cat\n", Module=0xeffff18c) at ../../fvwm/fvwm/read.c:210
#6  0x4f820 in ExecuteFunction (Action=0x1 <Address 0x1 out of bounds>, 
    tmp_win=0x0, eventp=0xa1238, context=8, Module=-1)
    at ../../fvwm/fvwm/functions.c:247
#7  0x6e488 in ReadSubFunc (eventp=0xa1238, junk=42, tmp_win=0x0, context=8, 
    action=0xd <Address 0xd out of bounds>, Module=0xeffff704, piperead=0)
    at ../../fvwm/fvwm/read.c:161
#8  0x6e5dc in ReadFile (eventp=0xa1238, junk=42, tmp_win=0x0, context=8, 
    action=0xb169d ".fvwm2rc", Module=0xeffff704) at ../../fvwm/fvwm/read.c:182
#9  0x4f820 in ExecuteFunction (Action=0x1 <Address 0x1 out of bounds>, 
    tmp_win=0x0, eventp=0xa1238, context=8, Module=-1)
    at ../../fvwm/fvwm/functions.c:247
#10 0x508a8 in main (argc=649728, argv=0x9e800) at ../../fvwm/fvwm/fvwm.c:381

It's run a popen on cat, which won't close until its input pipe is
closed, which it won't be because fvwm doesn't close it, so it sits
forever.  Perhaps your implementation of cat does something different?
Anyway I suggest this test be modified :)

BTW, I got the same problem with these lines:

  piperead cat /nonexistent/foo/bar
  piperead 	cat	  /tmp/purify.read

because the first argument ("cat") is the command name and the rest are
assumed to be options to the command (this is odd; why aren't the
options first?  Annoying).  Anyway, I had to quote them:

  piperead "cat /nonexistent/foo/bar"
  piperead "	cat	  /tmp/purify.read"

Then, I got a lot further but I eventually got a coredump :(

I'll describe that in a followup message.

-- 
-------------------------------------------------------------------------------
 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.hpc.uh.edu/fvwm/>.
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, 19 Nov 1998 13:52:51 +0100

On Wed, Nov 18, 1998 at 04:39:55PM -0500, [email-masked] wrote:
> ...

Well, I don't get coredumps on my Linux box, but that doesn't
mean anything. I've probably the same stack errors but they
don't cause a segfault. Anyway that's part of the test. Obviously
this Piperead command has to be examined carefully. Unfortunately
I have no idea what we can do to prevent the hang. Perhaps my
Linux cat knows that it does not run in an interactive environment
and terminates itself while yours does not?

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: [email-masked] (Paul D. Smith)
Date: 19 Nov 1998 09:51:07 -0500

>> Anyway I suggest this test be modified :)

  dv> Well, I don't get coredumps on my Linux box, but that doesn't mean
  dv> anything. I've probably the same stack errors but they don't cause
  dv> a segfault. Anyway that's part of the test.

No, the segfault came a lot further down; see my next message.  I don't
think it's related to this issue.  I'm suggesting the test be changed to
not use cat, because if you use it then the test hangs and never
completes, waiting for input.

  dv> Unfortunately I have no idea what we can do to prevent the
  dv> hang. Perhaps my Linux cat knows that it does not run in an
  dv> interactive environment and terminates itself while yours does
  dv> not?

Doubtful, since it's perfectly legitimate to use cat outside of an
interactive environment--I think it more likely your version of popen()
behaves differently than mine--maybe closes stdin of the subprocess.
Either way I'm not suggesting that we (right now) try to fix the
hang--as you say, how to do that isn't clear.

I'm just saying we shouldn't put that into the test since it _does_ hang
on some systems.

One idea would be to close stdin to the subprocess... but I'm not sure
if that would be a good idea, and also it would mean we'd have to write
our own fork/exec function instead of relying on popen().

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 19 Nov 1998 16:48:10 +0100

> I'm just saying we shouldn't put that into the test since it _does_ hang

That's ok. It is more important that we get a valid purify log and
can address other problems later. However, please don't remove the
lines but comment them out and write a short description into the
file why they were taken out (there are other places where I did this).

> our own fork/exec function instead of relying on popen().

No, definitely not. I have still the vague idea that fvwm should
never hang or coredump regardless of what it is told to do.

Bye

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 20 Nov 1998 13:46:16 -0500

>> our own fork/exec function instead of relying on popen().

  dv> No, definitely not. I have still the vague idea that fvwm should
  dv> never hang or coredump regardless of what it is told to do.

"No, definitely not" to which part :)?

Anyway, certainly fvwm should _never_ dump core, but I don't see any
possible way to avoid hangs if the user does something silly.

The already-provided example with cat is one.  Another is something like:

    piperead "sleep 500000"

How can you protect against this?  The only way I can see is to install
some sort of timer signal that goes off after some amount of time, and
wakes up fvwm from the read(2) so it can kill the pipe or something.
That's a _LOT_ of complexity to avoid luser-stupidity :)