Subject: FVWM: -pipe option not used for acc

From: Christopher Wolf <[email-masked]>
Date: Mon, 9 Sep 1996 15:41:49 -0500 (CDT)

The Makefiles for fvwm-2.0.42 and 2.0.43 both have the option -pipe in them.

For acc V2.0, the manual states it is an obsolete option.
For acc V3.0, it is NOT an option, and it tries to pass it on to the
linker/loader -- which results in an error.

Please remove -pipe from the CCOPTIONS for acc.

-Wolf

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Christopher Wolf <[email-masked]>
Date: Mon, 9 Sep 1996 17:01:21 -0500 (CDT)

On 9 Sep 1996, Jason L Tibbitts III wrote:

>Huh?  There aren't any Makefiles in fvwm-2.0.4(2|3):
>
>You generate the Makefile using xmkmf, which uses the Imake configuration
>on your system to generate the proper Makefile options.  If the generated
>Makefile is onforrect, then Imake is incorrectly configured on your
>machine.

**smack**

Yes, of course.  Sorry to bother.

---

From: Jason L Tibbitts III <[email-masked]>
Date: 09 Sep 1996 16:55:13 -0500

>>>>> "CW" == Christopher Wolf <[email-masked]> writes:

CW> The Makefiles for fvwm-2.0.42 and 2.0.43 both have the option -pipe in
CW> them. 

XYX:lucien:~> tar xfz fvwm-2.0.43.tar.gz 
XYX:lucien:~> find fvwm-2.0.43 -name Makefile -print
XYX:lucien:~> 

CW> Please remove -pipe from the CCOPTIONS for acc.

You should send that to your system administrator or whoever configured
Imake at your site.

 - J<

---

From: Thomas Leitner <[email-masked]>
Date: Tue, 10 Sep 1996 09:11:14 +0200 (MET DST)

-----BEGIN PGP SIGNED MESSAGE-----

Hi,

My problem is still not solved and I have reports from someone that it
also occurs under Solaris 2.5. 

The problem is this: When the X server is killed or crashes, fvwm2
as well as FvwmButtons continues to run and both sit there and eat
all CPU time they can get.

I think this is a serious problem and really should be fixed. Apart
from that it is rather annoying for me due to my special X setup which
just kills the X server when logging out and fvwm2 and FvwmButtons
need to be killed manually after logging out. 

I've already made two modifications as suggested in this list. I've
changed the DeadPipe routine in module.c like this: 

void DeadPipe(int nonsense)
{
  struct stat buf;
  if (fstat(XConnectionNumber(dpy), &buf) == -1) exit(1);
  signal(SIGPIPE, DeadPipe);
}

Likewise I've changed the DeadPipe routine in FvwmButtons.

Well. It does not work. Same problem.

Does anyone know a cure for that? I think fvwm is not ready for version
2.1 before this problem is solved.

Thanks -- Tom

- --------------------------------------------------------------------------
T o m   L e i t n e r                       Dept. of Communications
                                            Graz University of Technology, 
e-mail    : [email-masked]      Inffeldgasse 12
Phone     : +43-316-873-7455                A-8010 Graz / Austria / Europe
Fax       : +43-316-463-697
Home page : http://wiis.tu-graz.ac.at/people/tom.html
PGP public key on : ftp://wiis.tu-graz.ac.at/pgp-keys/tom.asc or send 
mail with subject "get Thomas Leitner" to [email-masked]
- --------------------------------------------------------------------------

---

From: Grant McDorman <[email-masked]>
Date: Tue, 10 Sep 1996 10:05:15 -0400 (EDT)

I hadn't followed up on my earlier postings on this since I was
doing some testing (and have also been busy on the things I'm
paid for <grin>). It turns out that the problem with FvwmButtons
looping is more likely the fact that it was doing Xlib calls in
the signal handler, which is supposed to be illegal. I've changed
it to just set a flag, which would force exit from the main loop
and then do the cleaup, but it doesn't seem to work properly yet
(swallowed programs get left running on a restart).

Based on this, I suspect your problem may not be the signal handler.
What I suggest you do is break into the looping process(es) with your
debugger, get the call stack, and post it to the list. We can proceed
from there.

I'll post the change to FvwmButtons when I'm sure it works okay.

On 10-Sep-96 13:11:14 Thomas Leitner wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: latin1
> 
> iQCVAwUBMjUUlNEZPSczow+VAQH02gP/VOMLsrI+6Hx8FdxC076Y6uVeWQPn5XmL
> ZjMDB/9jAQuHUmAnqqOk1utLbjpi3vHhGMWlltgk7v1GpjAr0Q+BFHMbbdT0jo+p
> mGYxRONMlSZn+PaWCC9fVo5d1kGAb9B9FV9TEQO2UTk797XGKnCaCWM5kf/KsJHU
> RaVh4+sPdHM=
> =s/3G
> -----END PGP SIGNATURE-----
> 
> --
Grant McDorman <[email-masked]>
				ISG Technologies, Inc.

---

From: "Charles Hines" <[email-masked]>
Date: Tue, 10 Sep 1996 10:54:40 -0400

>>>>> "GM" == Grant McDorman <[email-masked]> writes:

GM> I hadn't followed up on my earlier postings on this since I was
GM> doing some testing (and have also been busy on the things I'm
GM> paid for <grin>). It turns out that the problem with FvwmButtons
GM> looping is more likely the fact that it was doing Xlib calls in
GM> the signal handler, which is supposed to be illegal.

Yeah, that's definitely bad, but I hadn't noticed it before...

GM> I've changed it to just set a flag, which would force exit from
GM> the main loop and then do the cleaup, but it doesn't seem to work
GM> properly yet (swallowed programs get left running on a restart).

Sounds like the right idea though.  I'll have to browse through that
code.

GM> Based on this, I suspect your problem may not be the signal handler.
GM> What I suggest you do is break into the looping process(es) with your
GM> debugger, get the call stack, and post it to the list. We can proceed
GM> from there.

Good idea, although where it's actually looping may not have anything
to do with how it got there.

GM> I'll post the change to FvwmButtons when I'm sure it works okay.

Ok.

Chuck

---

From: Thomas Leitner <[email-masked]>
Date: Wed, 11 Sep 1996 09:48:34 +0200 (MET DST)

Hi Grant,

Thanks for your reply.

> debugger, get the call stack, and post it to the list. We can proceed

O.K. I had a 1 hour debugging session this morning before I had to do
what I get paid for :-)

1.) FVWM2 didn't always loop when exiting X. Sometimes I dumped core
    as well. I got the following traceback for that:

    (gdb) r
    Starting program: /home/users/tom/sources/fvwm-2.0.43/fvwm/fvwm2
    X connection to finwal01:0.0 broken (explicit kill or server shutdown).

    Program received signal SIGSEGV, Segmentation fault.
    0x3ff8046fdb8 in XQueryPointer ()
    (gdb) bt
    #0  0x3ff8046fdb8 in XQueryPointer ()
    #1  0x120025eec in WaitForButtonsUp () at menus.c:852
    #2  0x12001da98 in ExecuteFunction (
        Action=0x140001850 "Function ExitFunction", tmp_win=0x0,
        eventp=0x140004980, context=8, Module=-1) at functions.c:183
    #3  0x120020600 in Done (restart=0, command=0x0) at fvwm.c:1076
    #4  0x120020948 in CatchFatal (dpy=0x140008000) at fvwm.c:1149
    #5  0x3ff80485cf4 in _XIOError ()
    #6  0x3ff80482054 in _XRead ()
    #7  0x3ff80483664 in _XReply ()
    #8  0x3ff8047b6a0 in XSync ()
    #9  0x12002760c in Destroy (Tmp_win=0x14005d300) at misc.c:116
    #10 0x12001bc48 in HandleUnmapNotify () at events.c:931
    #11 0x120019e78 in DispatchEvent () at events.c:232
    #12 0x120019ed8 in HandleEvents () at events.c:253
    #13 0x12001ebd0 in main (argc=1, argv=0x11ffff9a8) at fvwm.c:447
    (gdb)

    The reason whas, that I had an "ExitFunction" defined which was
    supposed to kill FvwmButton. I saw this in a posting in the list
    and though it might be good idea. Actually when the ExitFunction
    was defined, ExecuteFunction is called which in turn makes some
    X calls again which dump core since the connection is already
    broken.

2.) Now for the looping problem. As expected, I get a SIGPIPE when X
    is killed. When I execute the SIGPIPE Handler with "signal 13"
    (13 = SIGPIPE) I found that this:

           struct stat buf;

    is not working! The program does not exit. Instead:

    is executed and the program continues. 

    Now the program loops and eats cpu time. When I interrupt it with
    the debugger I get the following traceback:

    (gdb) bt
    #0  0x3ff80481398 in _XFlush ()
    #1  0x3ff80485fd4 in _XData32 ()
    #2  0x3ff80472888 in XConfigureWindow ()
    #3  0x120010e0c in SetupFrame (tmp_win=0x14006af20, x=79, y=1055,w=921,
        h=981, sendEvent=1) at borders.c:1154
    #4  0x120034408 in MoveViewport (newx=0, newy=0, grab=0) at virtual.c:393
    #5  0x1200205b0 in Done (restart=0, command=0x0) at fvwm.c:1071
    #6  0x120020948 in CatchFatal (dpy=0x140008000) at fvwm.c:1149
    #7  0x3ff80485cf4 in _XIOError ()
    #8  0x3ff80481614 in _XFlush ()
    #9  0x3ff804835fc in _XReply ()
    warning: Hit heuristic-fence-post without finding
    warning: enclosing function for address 0x4a40537248019600

    Apparently "CatchFatal" is correctly called but in turn calls
    X functions and ends up in XFlush which sits there and loops.
    XFlush never returns.

    Examining the source reveals that the 'Done' routine does:

    #ifndef NON_VIRTUAL
       MoveViewport(0,0,False);
    #endif

    I don't know what this is for but it is definately the reason
    for the troubles.

So all in all I come to the following conclusions:

    a.) ExitFunctions are not good !! The can cause fvwm2 to dump core
        when exiting!
    b.) The MoveViewPort call in 'Done' is the reason for the troubles.

I don't have too much insight in fvwm to decide if its appropriate just
to remove this call from the 'Done' routine.

So how can we solve the problem?

Thanks for your help everybody -- Tom

--------------------------------------------------------------------------
--------------------------------------------------------------------------

---

From: Grant McDorman <[email-masked]>
Date: Wed, 11 Sep 1996 09:18:09 -0400 (EDT)

>     is executed and the program continues. 

The 'fstat' code was just a stab in the dark.

> to remove this call from the 'Done' routine.

It should be possible to just remove the 'Done' and replace it with exit(1);
for now. The problem in your case appears to be that it is not permissable
to call X functions from the X fatal I/O error handler.

The XLib Reference Manual (for 'R5) says nothing about calling X functions
from the fatal error handler; it does say it isn't permissable to call them
from the regular error handler. Obviously, though, making X calls from the
fatal error handler is a Bad Thing.

>From an inspection of the code, it appears the only safe thing from Done()
that could be invoked in the fatal I/O error handler is ClosePipes().

This means, by the way, that the ExitFunction won't get invoked on a server
shutdown, unless some way of preventing all X calls during its operation can
be put in place.

The SIGSEGV in the ExitFunction may be the same problem.

I am attaching a patch to fvwm.c which changes the CatchFatal to call
ClosePipes() and exit(1), and the patch FvwmButtons which changes the signal
handling.

Chuck may have more to say on this, of course.

---

From: Thomas Leitner <[email-masked]>
Date: Wed, 11 Sep 1996 15:54:10 +0200 (MET DST)

-----BEGIN PGP SIGNED MESSAGE-----

Hi Grant,

> Chuck may have more to say on this, of course.

Thanks for the patch. I'll apply it and see if it works. I hope that
a final solution for the problem (perhaps with ExitFunction being called
even on a server shutdown) will be in 2.1.

Thanks again -- Tom

---

From: Thomas Leitner <[email-masked]>
Date: Wed, 11 Sep 1996 16:41:05 +0200 (MET DST)

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 11 Sep 1996, Grant McDorman wrote:

> I just noticed that the FvwmButtons patch is bad. The attached patch should
> be used instead; or, change line 204 in the patched FvwmButtons.c from
>    running = 1;
> to
>    running = 0;
> 
> Sorry about that.

No problem. Thanks for the hint.

Tom

---

From: Grant McDorman <[email-masked]>
Date: Wed, 11 Sep 1996 10:32:16 -0400 (EDT)

Sorry about that.

On 11-Sep-96 19:54:10 Thomas Leitner wrote:
> -
> -
> iQCVAwUBMjbEhNEZPSczow+VAQHwswP/VP6VmiQrJ5l3ziEoaaGALdy7munjeteW
> QxA9riMRRFYOfTWGyWt+SbvWzQhFAxvzZ+1Ighv+M+7D3Qcz4mISjcfGrrUek5Os
> P/RIA8RXsRsG9+7RdiLt6BdhiLx/Tu8SGdB3zExsJjpaTeTY/9AzZ+2sSriJlIeQ
> Z50Ler5btbI=
> =1JUK