Subject: Core file from the menu code

From: Dan Espen <[email-masked]>
Date: Sun, 25 Oct 1998 16:50:47 -0500

I managed to produce this stack trace using the 2.0.47d menu code:

(gdb) where
#0  0x3abd4 in FMenuMapped (menu=0x0) at menus.c:290
#1  0x3c210 in MenuInteraction (menu=0x103ae8, menuPrior=0x0,
    pmiExecuteAction=0xeffff0a0, cmenuDeep=1, fSticks=0) at menus.c:725
#2  0x3a540 in do_menu (menu=0x103ae8, menuPrior=0x0,
    pmiExecuteAction=0xeffff0a0, cmenuDeep=1, fStick=0, key_press=1)
    at menus.c:160
#3  0x22d88 in popup_func (eventp=0x6a650, w=41, tmp_win=0x0, context=8,
    action=0x10baee "MenuFvwmAnimate", Module=0xeffff1c4) at builtins.c:1041
#4  0x3344c in ExecuteFunction (Action=0x6e798 "Popup MenuFvwmAnimate",
    tmp_win=0x0, eventp=0x6a650, context=8, Module=-1) at functions.c:245
#5  0x2f634 in HandleKeyPress () at events.c:362
#6  0x2ed6c in DispatchEvent () at events.c:156
#7  0x2edc8 in HandleEvents () at events.c:177
#8  0x34808 in main (argc=1, argv=0xeffff73c) at fvwm.c:464
(gdb) print menu
$1 = (MenuRoot *) 0x0

I fixed it by making this change around line 725:

	  mrPopup = MrPopupForMi(mi);
	  if (mrPopup && !FMenuMapped(mrPopup)) {
              ^^^^^^^^^^
This seemed to work, but I really didn't follow what's going on with
this logic.  (Not that I looked a long time.)

One  thing that may be different  here  is this occured in FvwmAnimate
right after I   issued a FvwmAnimateStop.   Stop  destroys the current
menus and creates a new set  of menus.  I notice  that on my slow home
system, I  am operating the menus as  they are being reconstructed.  I
don't think this should have any bearing on the core file creation...

I'm hoping one of our menu experts will get a chance to look at this.

Thanks.
--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
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: Greg Badros <[email-masked]>
Date: 26 Oct 1998 07:49:02 -0800

> 	  if (mrPopup && !FMenuMapped(mrPopup)) {

Sounds like a race condition to me.  The code confirms
IS_POPUP_MENU_ITEM(mi) before calling MrPopupForMi(mi); if the data
structures have maintained their integrity, I'd not expect MrPopupForMi
to return NULL.  I'm not positive why it is returning NULL, but checking
that it's not NULL is a good thing given that the invariant seems to be
broken.  

Greg

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 25 Oct 1998 15:06:24 +0100

> that it's not NULL is a good thing given that the invariant seems to be

I can't remeber the details, but I know I fixed this
in the menu position patch. This is all a bit foggy, but
I am nearly convinced that this was really simple and
perfectly OK for MrPopupForMi to return NULL. I would
not worry about this.

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].