Subject: Re: Notification: incoming/1449

From: George "Nephrite" Potapov <[email-masked]>
Date: Fri, 1 Oct 2004 12:44:36 +0400

On Thu, 30 Sep 2004 18:12:57 +0200  Dominik Vogt wrote about "Re: Notification: incoming/1449":

> On Thu, Sep 30, 2004 at 08:41:53AM -0500, fvwm-bug wrote:
> > FVWM Bug Tracking notification
> > 
> > new message incoming/1449
> > 
> > From: [email-masked]
> > To: [email-masked]
> > Subject: fvwm crashes when QUIT'ing firefox
> > 
> > Full_Name: George 'Nephrite' Potapov
> > Version: 2.5.10
> > CVS_Date: 
> > OS: FreeBSD-5.3BETA5
> > X_Server: Xorg-6.7.0
> > Submission from: (NULL) (217.171.1.2)
> > 
> > I'm using firefox 0.9.3
> > When I select file/quit from firefox menu, fvwm crashes and dumps core.
> > When closing firefox windows using 'Close' fvwm function, everithing's OK.
> > Happens every time, just start firefox and try to quit using firefox menu.
> > 
> > I'd think it's firefox issue unless fvwm dumped core :-)
> 
> Can you please fetch a stack trace and post it to the fvwm-workers
> list?
> 
>   $ gdb fvwm core
>   (gdb) where
>

Strangely, but after I'd rebuilt fvwm with debugging symbols included (cc -g) it ceased to happen. As to old core file it was not useful because of a huge stack trace with no function names. I'll try to send a new one as soon as it happens again. However, judging from all the events, now it seems to be some bugs/misconfiguration in my beta FreeBSD libc.

-- 
wbr,
George 'Nephrite' Potapov
Inline Technologies
--
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: George "Nephrite" Potapov <[email-masked]>
Date: Fri, 1 Oct 2004 14:49:45 +0400

[skip]

> Can you please fetch a stack trace and post it to the fvwm-workers

I managed to get the stack trace for recent fvwm crash, here it is:

== start ==

Core was generated by `fvwm'.
Program terminated with signal 11, Segmentation fault.
#0  0x0806a208 in HandleUnmapNotify (ea=0xbfbfe384) at events.c:3374
3374				XUnmapWindow(dpy, te->xunmap.window);
#0  0x0806a208 in HandleUnmapNotify (ea=0xbfbfe384) at events.c:3374
#1  0x0806a850 in dispatch_event (e=0xbfbfe3b0) at events.c:3616
#2  0x0806a91a in HandleEvents () at events.c:3661
#3  0x080951f2 in main (argc=2, argv=0xbfbfe80c) at fvwm.c:2524

== end ==

Everything else the same: it was caused by firefox file/quit menu

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 1 Oct 2004 16:30:14 +0200

> 3374				XUnmapWindow(dpy, te->xunmap.window);

??? It can't have crashed in that line!  The only possible case
would be if te is invalid, but then it should have crashed
earlier, in line 3353:

  unsigned long win = (unsigned long)te->xunmap.window;

Besides, te is *never* invalid as it points to stack memory.  Can
you please post the output of the following gdb commands (while
debugging the core file):

  (gdb) p te
  (gdb) p te->xunmap.window
  (gdb) p dpy
  (gdb) p ea
  (gdb) p ea->exc
  (gdb) p ea->exc->x

> Everything else the same: it was caused by firefox file/quit menu

Ciao

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]

---

From: George "Nephrite" Potapov <[email-masked]>
Date: Mon, 4 Oct 2004 10:10:48 +0400

On Fri, 1 Oct 2004 16:30:14 +0200  Dominik Vogt wrote about "Re: Notification: incoming/1449":

[some skip]

>   (gdb) p te->xunmap.window

Sure, here it is:

== start ==

(gdb) p te
$1 = (const XEvent *) 0x0
(gdb) p te->xunmap.window
Cannot access memory at address 0x14
(gdb) p dpy
$2 = (Display *) 0x811a000
(gdb) p ea
$3 = (const evh_args_t *) 0xbfbfe384
(gdb) p ea->exc
$4 = (const exec_context_t *) 0x818ee00
(gdb) p ea->exc->x
$5 = {etrigger = 0x818ee1c, elast = 0x810ade0}

== stop ==

Looks like te is NULL :-(

---

From: George "Nephrite" Potapov <[email-masked]>
Date: Tue, 5 Oct 2004 12:58:13 +0400

I seem to have the same effect when doing like this:

I have an application panel'ed in FvwmButtons (namely psi)
I open the panel
Then, minimize the application with titlebar minimize button
Then, press the button on FvwmButtons to close panel

fvwm crashes, dumps core, and the stack trace looks the same:

== start ==

#0  0x0806a208 in HandleUnmapNotify (ea=0xbfbfe7b4) at events.c:3374
#1  0x0806a850 in dispatch_event (e=0xbfbfe7e0) at events.c:3616
#2  0x0806a91a in HandleEvents () at events.c:3661
#3  0x080951f2 in main (argc=2, argv=0xbfbfec30) at fvwm.c:2524

== stop ==

and those gdb commands you asked me to execute :-)
looks the same:

== start ==

(gdb) p te
$1 = (const XEvent *) 0x14
(gdb) p te->xunmap.window
Cannot access memory at address 0x28
(gdb) p dpy
$2 = (Display *) 0x811a000
(gdb) p ea
$3 = (const evh_args_t *) 0xbfbfe7b4
(gdb) p ea->exc
$4 = (const exec_context_t *) 0x8140180
(gdb) p ea->exc->x
$5 = {etrigger = 0x814019c, elast = 0x810ade0}

== stop ==

So I suppose this is a bug in fvwm code for handling unmapping windows in general rather than exclusive firefox issue

---

From: George "Nephrite" Potapov <[email-masked]>
Date: Tue, 5 Oct 2004 14:29:39 +0400

On Tue, 5 Oct 2004 11:45:16 +0200  Dominik Vogt wrote about "Re: Notification: incoming/1449":

[giga skip]

> I think I've found the reason.  The FCheckIfEvent() call writes
> over the te variable because the wrong pointer is passed to it
> (&win instead of &args).  Can you please try the attached patch
> and tell me if it fixes the problem?

It works! No more crashes.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 5 Oct 2004 11:45:16 +0200

> #3  0x080951f2 in main (argc=2, argv=0xbfbfec30) at fvwm.c:2524

[snip]

> $1 = (const XEvent *) 0x14
[snip]

> So I suppose this is a bug in fvwm code for handling unmapping
> windows in general rather than exclusive firefox issue

It can be reduced to a simple formula:

  Core dump = bug

:-)

Ciao

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
--- events.c.orig	Tue Oct  5 11:27:53 2004
+++ events.c	Tue Oct  5 11:39:47 2004
@@ -3350,17 +3350,16 @@
 
 	if (weMustUnmap)
 	{
-		unsigned long win = (unsigned long)te->xunmap.window;
 		Bool is_map_request_pending;
 		check_if_event_args args;
 
-		args.w = win;
+		args.w = te->xunmap.window;
 		args.do_return_true = False;
 		args.do_return_true_cr = False;
 		/* Using FCheckTypedWindowEvent() does not work here.  I don't
 		 * have the slightest idea why, but using FCheckIfEvent() with
 		 * the appropriate predicate procedure works fine. */
-		FCheckIfEvent(dpy, &dummy, test_map_request, (char *)&win);
+		FCheckIfEvent(dpy, &dummy, test_map_request, (char *)&args);
 		/* Unfortunately, there is no procedure in X that simply tests
 		 * if an event of a certain type in on the queue without
 		 * waiting and without removing it from the queue.