Subject: FvwmAuto problem

From: "Robert H. Ford II" <[email-masked]>
Date: Thu, 02 Dec 1999 11:09:04 -0600

All,

With the last several beta versions of Fvwm, I've been having problems with
FvwmAuto.

It appears that the process just dies.  If I run a "ps" while FvwmAuto works I
can see the process, but if I run a "ps" when it doesn't work there is no
process to be seen.  I can restart it without any problems, but that is becoming
tiresome.

Is there anything I can do to help debug this problem?  No core file is created.

Thank you for any help/advise.

Bob
-- 
    _/_/_/     _/  _/   _/_/_/_/   _/_/_/_/_/_/ Robert H. Ford II
   _/   _/    _/  _/   _/           _/    _/    Lucent Technologies
  _/_/_/     _/_/_/   _/_/_/       _/    _/     Bell Labs Innovations
 _/   _/    _/  _/   _/           _/    _/      Naperville IL, 60566-7045
_/    _/   _/  _/   _/         _/_/_/_/_/_/     mailto:[email-masked]
                                                Voice: (630) 713-4957
__________________________________________________
|  M R spiders!                    |      |   |  |
|  M N O spiders!                  |      |   |  |
|  O S A R - C D E D B D I's?      |      |   |  |
|  Y I B, M R spiders...           |      |   *  |
|                                  *      |      |
|                                         *      |
--------------------------------------------------
--
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: [email-masked] (Paul D. Smith)
Date: 02 Dec 1999 12:32:58 -0500

I've seen this too, _very_ intermittently (it's probably happened twice
to me so far).  No core and no messages in the log file.

I suggest you attach to a running FvwmAuto with gdb, set a breakpoint at
abort(), _exit(), etc., then continue and leave it, and keep working
normally.  Next time you notice FvwmAuto has died, go back to that xterm
and it should be stopped in the debugger; you should be able to get some
info about what is going on.

-- 
-------------------------------------------------------------------------------
 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: "Robert H. Ford II" <[email-masked]>
Date: Mon, 06 Dec 1999 17:51:47 -0600

"Paul D. Smith" wrote:
> 
> %% "Robert H. Ford II" <[email-masked]> writes:
> 
>   rhf> FvwmAuto died again.  That's twice so for today.
> 
>   rhf> Here is what gdb reported:
> 
>   rhf> (gdb) c
>   rhf> Continuing.
> 
>   rhf> Program received signal SIGPIPE, Broken pipe.
>   rhf> 0xef439690 in _write () from /usr/lib/libc.so.1
> 
>   rhf> I know this is not much to go on but I did not know where to set
>   rhf> breakpoints (didn't know where to start).
> 
> Set breakpoints on abort() and exit() and _exit(), to start with.
> 
>   rhf> Is there anything else I can do to to get more detail on why
>   rhf> FvwmAuto is receiving a SIGPIPE?
> 
> Well, at least run a "bt" and see what the stack is like.  Looks like
> the pipe is being closed by fvwm (or FvwmAuto itself, I suppose) for
> some reason.  Be sure you've compiled with -g (debugging) or else your
> stack trace won't have much useful info in it.
> 
> Once you have that info you might post it to fvwm-workers to see if
> anyone else has an idea.
> 
> --

Well, I couldn't figure out how to set a simple breakpoint in gdb so I just ran
it and hoped that bt would give some useful info... Well it didn't.  Here is
what back trace reported:

(gdb) bt
#0  0xef439690 in _write () from /usr/lib/libc.so.1
#1  0x11024 in _init ()
#2  0x10dd8 in _init ()
(gdb) 

I don't know if this is enough in information to help debug this problem or not.

As you can see, FvwmAuto dies at least three to four times daily.

Bob

---

From: Michael Han <[email-masked]>
Date: Mon, 06 Dec 1999 17:29:00 -0800

Previously from "Robert H. Ford II"
>Well, I couldn't figure out how to set a simple breakpoint in gdb so I just ra

To set a breakpoint in gdb, do a:

(gdb) break _exit
(gdb) break exit
(gdb) break abort

and that should do it. Then you give a

(gdb) continue

and wait for it to die on you... at *that* point a backtrace should be
informative (it'll show how FvwmAuto came to close). Incidentally, you
can always issue

(gdb) help

in gdb. It actually is fairly helpful, I find. Otherwise there's
always the <shudder> GNU info documentation... Ick.
-- 
[email-masked]                         http://www.best.com/~mikehan/
coffee achiever                              San Francisco, California
"It is better for people to think your [sic] a fool, than for you to open
your mouth and remove all doubts." - some fool
--
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, 08 Dec 1999 13:15:31 -0500

> As you can see, FvwmAuto dies at least three to four times daily.

Unless _init  is recursing into  _init and  doing a write,  it doesn't
look like a valid stack trace.

I just changed  FvwmAuto (in the current  CVS), so that if you compile
it  with CFLAGS set to "-DDEBUGTOFILE",  it will put  its debug output
into $HOME/.FvwmAutoDebug.

I did find a bug in the debug logic itself, but I don't think that
had anything to do with the symptoms you reported.

I do suggest you try to recreate the problem with debugtofile enabled.

--
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: Olivier Chapuis <[email-masked]>
Date: Sun, 12 Dec 1999 22:20:22 +0100

> I do suggest you try to recreate the problem with debugtofile enabled.

I have noted the same problems and enable debugtofile (Auto die quite
rarely on my machine)

start 58 (ri = 0, hnw = 1, usec = 1000)
select: delay = 1000 usecs
pw = 0x4000003, fw=0x4000003, rw = 0x4c0004e, lw=0x4c0004e
raise packet 0x4000003
its the old window: don't raise
Leaving via DeadPipe

The others messages never contain "its the old window: don't raise".

Here my FvwmAuto config:

+  "I" FvwmAuto 1 GoodAutoRaise GoodAutoLower

DestroyFunc GoodAutoRaise
AddToFunc GoodAutoRaise 
+ "I" Current (FvwmSAppliButtons) RaiseFvwmSAppli
+ "I" Current (FvwmSAppliStart) RaiseFvwmSAppli
+ "I" Current (FvwmWAppletButtons) RaiseFvwmWApplet
+ "I" Current (FvwmWAppletPanelCpu) RaiseFvwmWApplet
+ "I" Current (FvwmWAppletPanelClock) RaiseFvwmWApplet
+ "I" Current (FvwmWAppletPanelCd) RaiseFvwmWApplet
+ "I" Current (FvwmWAppletPanelMore) RaiseFvwmWApplet
+ "I" Current (FvwmWAppletStartNW) RaiseFvwmWApplet
+ "I" Current (FvwmWinOpsButtons) RaiseFvwmWinOps
+ "I" Current (FvwmWinOpsStart) RaiseFvwmWinOps
+ "I" Current (FvwmWinList) Raise
+ "I" Current (FvwmIconMan) Raise
+ "I" Current (FvwmTaskBar) Raise
+ "I" Current (FvwmIconBox) Raise
+ "I" Current (FvwmButtonsPager) RaiseButtonsPager
+ "I" Current (FvwmButtonsPagerPanel) RaiseButtonsPager
+ "I" Current (panel) Raise

DestroyFunc GoodAutoLower
AddToFunc GoodAutoLower 
+ "I" Prev (FvwmSAppliButtons) LowerFvwmSAppli
+ "I" Prev (FvwmSAppliStart) LowerFvwmSAppli
+ "I" Prev (FvwmWinOpsButtons) LowerFvwmWinOps
+ "I" Prev (FvwmWinOpsStart) LowerFvwmWinOps

DestroyFunc RaiseFvwmSAppli
AddToFunc RaiseFvwmSAppli I All (FvwmSAppli*) Raise

DestroyFunc RaiseASApplet
AddToFunc RaiseASApplet I All (ASApplet*) Raise

DestroyFunc RaiseFvwmWApplet
AddToFunc RaiseFvwmWApplet I All (FvwmWApplet*) Raise

DestroyFunc RaiseButtonsPager
AddToFunc RaiseButtonsPager I All (FvwmButtonsPager*) Raise
+ "I" All (FvwmPager*) Raise

DestroyFunc RaiseFvwmWinOps
AddToFunc RaiseFvwmWinOps I All (FvwmWinOps*) Raise

DestroyFunc LowerFvwmSAppli
AddToFunc LowerFvwmSAppli I All (FvwmSAppli*) Lower

DestroyFunc LowerFvwmWinOps
AddToFunc LowerFvwmWinOps I All (FvwmWinOps*) Lower

---

From: "Robert H. Ford II" <[email-masked]>
Date: Tue, 14 Dec 1999 16:08:14 -0600

> I do suggest you try to recreate the problem with debugtofile enabled.

Well it died again, (fourth time today).

Here is what I get from gdb: (nothing different)

(gdb) break _exit
Breakpoint 1 at 0xef436f74
(gdb) break exit
Breakpoint 2 at 0xef474a2c
(gdb) break abort
Breakpoint 3 at 0xef43a568
(gdb) c
Continuing.

Program received signal SIGPIPE, Broken pipe.
0xef439690 in _write () from /usr/lib/libc.so.1
(gdb) bt
#0  0xef439690 in _write () from /usr/lib/libc.so.1
#1  0x11254 in _init ()
#2  0x10fc8 in _init ()
(gdb) 

I don't see anything useful in .FvwmAutoDebug.  The file is 4106 lines long, if
anyone would like to see it, I will send it to you.  Here are the last 74 or so
lines:

start 747 (ri = 0, hnw = 0, usec = 500000)
select: delay = infinite
pw = 0x840000e, fw=0xa80000e, rw = 0xa80000e, lw=0xa80000e
focus change
its a new window

start 748 (ri = 0, hnw = 1, usec = 500000)
select: delay = 500000 usecs
pw = 0xa80000e, fw=0x840000e, rw = 0xa80000e, lw=0xa80000e
raise packet 0xa80000e

start 749 (ri = 0, hnw = 1, usec = 500000)
select: delay = 500000 usecs
must raise now
raising 0x840000e

start 750 (ri = 0, hnw = 0, usec = 500000)
select: delay = infinite
pw = 0x840000e, fw=0x840000e, rw = 0x840000e, lw=0x840000e
raise packet 0x840000e

start 751 (ri = 0, hnw = 0, usec = 500000)
select: delay = infinite
pw = 0x0, fw=0x840000e, rw = 0x840000e, lw=0x840000e
focus change
its a new window

start 752 (ri = 0, hnw = 1, usec = 500000)
select: delay = 500000 usecs
must raise now
raising 0x0

start 753 (ri = 0, hnw = 0, usec = 500000)
select: delay = infinite
pw = 0x900000e, fw=0x0, rw = 0x840000e, lw=0x0
focus change
its a new window

start 754 (ri = 0, hnw = 1, usec = 500000)
select: delay = 500000 usecs
must raise now
raising 0x900000e

start 755 (ri = 0, hnw = 0, usec = 500000)
select: delay = infinite
pw = 0x900000e, fw=0x900000e, rw = 0x900000e, lw=0x900000e
raise packet 0x900000e

start 756 (ri = 0, hnw = 0, usec = 500000)
select: delay = infinite
pw = 0x0, fw=0x900000e, rw = 0x900000e, lw=0x900000e
focus change
its a new window

start 757 (ri = 0, hnw = 1, usec = 500000)
select: delay = 500000 usecs
pw = 0x900000e, fw=0x0, rw = 0x900000e, lw=0x900000e
focus change
no new window

start 758 (ri = 0, hnw = 1, usec = 500000)
select: delay = 500000 usecs
must raise now
raising 0x900000e

start 759 (ri = 0, hnw = 0, usec = 500000)
select: delay = infinite
pw = 0x0, fw=0x900000e, rw = 0x900000e, lw=0x900000e
focus change
its a new window

start 760 (ri = 0, hnw = 1, usec = 500000)
select: delay = 500000 usecs
pw = 0x900000e, fw=0x0, rw = 0x900000e, lw=0x900000e
raise packet 0x900000e

Bob

---

From: "Robert H. Ford II" <[email-masked]>
Date: Wed, 15 Dec 1999 10:46:49 -0600

Okay,  I have my first FvwmAuto failure of the day and here is what got printed
into .FvwmAutoDebug:

start 799 (ri = 0, hnw = 1, usec = 500000)
select: delay = 500000 usecs
pw = 0x6c000fa, fw=0x780000e, rw = 0x6c000fa, lw=0x6c000fa
raise packet 0x6c000fa
Leaving via DeadPipe

Does this help any?

The back trace still reports the same message.

Is there anything else I can do to help resolve this problem?  It is really
becoming an annoyance.

Thank you all for the help thus far.

Bob Ford II

---

From: Dan Espen <[email-masked]>
Date: Wed, 15 Dec 1999 15:01:16 -0500

> pw = 0x6c000fa, fw=0x780000e, rw = 0x6c000fa, lw=0x6c000fa

Well, it doesn't look like its any particular packet that causes the
problem.

> Is there anything else I can do to help resolve this problem?  It is really

Yep, bugs, I hate em.

I've started to run FvwmAuto myself, but so far, no luck.

It sorta looks like fvwm is stopping the module.

Perhaps you might start with a print in fvwm/module_interface.c in the
KillModule function, just  to  see if  fvwm  is deciding to  stop  the
module or if the pipe is just going bad for some reason.

This is untested, but:

fprintf(stderr,"Killing module %s\n",
	 (pipeName[channel] ? pipeName[channel] : "Noname"));

---

From: "Robert H. Ford II" <[email-masked]>
Date: Fri, 17 Dec 1999 12:44:40 -0600

> > Thank you all for the help thus far.

Okay I put the fprintf in fvwm/module_interface.c, I see "Killing module FvwmM4"
and "Killing module FvwmBanner" when these are done, but when FvwmAuto stops
working there is no message printed.

The same message is printed into .FvwmAutoDebug:

start 636 (ri = 0, hnw = 1, usec = 500000)
select: delay = 500000 usecs
pw = 0x880007b, fw=0x0, rw = 0x880007b, lw=0x880007b
raise packet 0x880007b
Leaving via DeadPipe

Is there another way to duplicate what FvwmAuto does?  I'm starting to think
this is a hopeless case.

---

From: Dan Espen <[email-masked]>
Date: Fri, 17 Dec 1999 14:14:08 -0500

> Is there another way to duplicate what FvwmAuto does?  I'm starting to think

You can do everything FvwmAuto does with FvwmEvent, (I think),
but we've barely scratched the surface on debugging this thing.

So far we've tried:

1) breakpoints in gdb at the exit point and we had "nonsense" results.

2) turning on debug which seemed to indicate that "DeadPipe" was being
called by the modules signal handler.

3) debug logic in fvwm  to see if fvwm  was closing the pipe to  cause
the signal.   It doesn't seem  to be, so the origin  of  the SIGPIPE is
mysterious.

I've had FvwmAuto  running  a few  days without   any problem.  I   am
running  it   under "purify"  and   my configuration  for  FvwmAuto is
probably different...

Here are some more things to try:

1. To tell for sure if the modules signal handler is calling Deadpipe,
change:

  signal (SIGPIPE, DeadPipe);

to

  signal (SIGPIPE, DebugRoutine);

In "DebugRoutine", print a message and call "DeadPipe".

2. If a "sigpipe" signal is being raised, we don't yet see why.
Attaching "truss" to FvwmAuto and fvwm might help.  (You'll get a whole
bunch of output.)

3. The "gdb" output didn't make sense to me.  Have you tried "dbx"?

4. The "gdb" output didn't make sense, perhaps the stack would make
more sense if you added this to the "Deadpipe" function:

  strcpy(0,"a");  /* Force a core dump */

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 17 Dec 1999 14:31:55 -0500

>   strcpy(0,"a");  /* Force a core dump */

I find calling abort() leaves a much better core dump.

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: "Paul D. Smith" <[email-masked]>
Date: 17 Dec 1999 16:29:01 -0500

%% Brad Giaccio <[email-masked]> writes:

  >> strcpy(0,"a");  /* Force a core dump */

  bg> I find calling abort() leaves a much better core dump.

Also, please double- and triple-check that you've compiled with
debugging on (-g) and it might be helpful to compile with optimization
off (no -O).  And recheck that your ModulePath isn't set or is set to
the right value so you're really running the right FvwmAuto.

I have to say I've always run FvwmAuto and except for that one time I
mentioned in my first response to you I've never had it die on me.