Subject: FVWM: App crashes fvwm

From: Dan D Niles <[email-masked]>
Date: Thu, 25 Oct 2001 14:14:35 -0500

I have an app (cgoban) that crashes fvwm every time I start it.
I am using fvwm 2.4.3.  It worked fine with fvwm 2.2.5 and prior.

Any suggestions as to what might be causing this, or where to
begin to debug this would be appreciated.

Thanks in advance,

Dan D Niles
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
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: Dan Espen <[email-masked]>
Date: Thu, 25 Oct 2001 15:31:08 -0400

> begin to debug this would be appreciated.

A stack trace might help.  Type:

gdb `whence fvwm2` $HOME/core

type in "where", send the result.

If you don't have "gdb", try the same command with "dbx".

-- 
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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan D Niles <[email-masked]>
Date: Thu, 25 Oct 2001 14:48:34 -0500

> gdb `whence fvwm2` $HOME/core
 
fvwm did not leave a core.  Do I need to coerce it somehow?
(BTW, whence does not exist on most systems, use which.)

Dan

---

From: Dan Espen <[email-masked]>
Date: Thu, 25 Oct 2001 15:58:17 -0400

> (BTW, whence does not exist on most systems, use which.)

In my experience, if it crashes, it leaves a core.

Does it leave a message on stderr?

Sorry about whence, when I'm not in ksh, I'm in sh.

---

From: Dan D Niles <[email-masked]>
Date: Thu, 25 Oct 2001 15:46:43 -0500

Apparenly the default somewhere in slackware 8 is to not do
cores.  I added 'ulimit -c unlimited' to my .xsession and got
a core.

gdb `which fvwm2` core
where 

produced:

#0  0x807e54a in XMapRaised ()
#1  0xbffff118 in ?? ()
#2  0x807fa5d in XMapRaised ()
#3  0x806717e in XMapRaised ()
#4  0x80670f1 in XMapRaised ()
#5  0x8069282 in XMapRaised ()
#6  0x8069318 in XMapRaised ()
#7  0x808603f in XMapRaised ()
#8  0x401742eb in __libc_start_main (main=0x8084d20 <XMapRaised+231828>, 
    argc=1, ubp_av=0xbffff794, init=0x804b374 <_init>, fini=0x809197c <_fini>, 
    rtld_fini=0x4000c130 <_dl_fini>, stack_end=0xbffff78c)
    at ../sysdeps/generic/libc-start.c:129

---

From: Dan Espen <[email-masked]>
Date: Thu, 25 Oct 2001 19:56:15 -0400

>     at ../sysdeps/generic/libc-start.c:129

I don't think anyone is going to be able to get anywhere with that.

Note that the stack doesn't lead back up to main() and
that there are bunch of functions at different addresses all claiming
to be XMapRaised.

I see this frequently, but I haven't got a good list of the causes.

Perhaps fvwm just needs to be recompiled with -g, or your gdb
needed to be upgraded to match the gcc that this was compiled with,
or the fvwm2 in your path doesn't match the core file, or the file
system the core file is on ran out of space and got truncated.

---

From: Dan D Niles <[email-masked]>
Date: Fri, 26 Oct 2001 14:34:38 -0500

Dan Espen writes:
 > [clip]

I didn't think that looked very useful.  The fvwm2 binary was
being stripped so even though it was compiled with -g there
was no symbol info.  Here is a fixed gdb output:

#0  0x809354a in setup_window_placement (tmp_win=0x80f02b0, pstyle=0xbffff1c0)
    at add_window.c:578
#1  0x809533a in AddWindow (w=23069835, ReuseWin=0x0) at add_window.c:1426
#2  0x8073402 in HandleMapRequestKeepRaised (KeepRaised=0, ReuseWin=0x0)
    at events.c:1040
#3  0x8073340 in HandleMapRequest () at events.c:1004
#4  0x80764e2 in DispatchEvent (preserve_Tmp_win=0) at events.c:2785
#5  0x80765aa in HandleEvents () at events.c:2838
#6  0x809dd7f in main (argc=2, argv=0xbffff794) at fvwm.c:718
#7  0x401742eb in __libc_start_main (main=0x809c4d0 <main>, argc=1, 
    ubp_av=0xbffff794, init=0x804b3dc <_init>, fini=0x80adc3c <_fini>, 
    rtld_fini=0x4000c130 <_dl_fini>, stack_end=0xbffff78c)
    at ../sysdeps/generic/libc-start.c:129