On Sun, Jan 03, 2010 at 02:05:48AM +0000, Thomas Adam wrote:
> On Sat, Jan 02, 2010 at 01:49:27PM -0500, des...@verizon.net wrote:
> > I bring up a menu, pin it with button 2 on the title bar, then
> > click on a pixmap on the title bar with an X.
> > The button is bound to:
> 
> [...]
> 
> Thanks.  I think I was able to reproduce this, by inferring the backtrace
> you sent, and me using a config which utterly broke FVWM when trying to
> tear-off a menu using either a MenuFace of TiledPixmap or Pixmap.
> 
> Does the attached patch fix the problem for you?  I've not committed it to
> CVS because I am still unsure if the problem this patch fixes is related to
> yours or not.  :P

Or better yet, does the second version of this patch do the trick?  Other
than the belt and braces stuff around the picture copying, the problem
turned out to be that we really *shouldn't* be copying over the original
pixel value when copying styles.

This seems to work quite well.  See attached.  Thoughts?


-- Thomas Adam

-- 
"It was the cruelest game I've ever played and it's played inside my head."
-- "Hush The Warmth", Gorky's Zygotic Mynci.
? fvwm/fix-tear-off-background-crash.patch
Index: fvwm/menustyle.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/menustyle.c,v
retrieving revision 1.43
diff -u -r1.43 menustyle.c
--- fvwm/menustyle.c	14 Mar 2008 17:22:42 -0000	1.43
+++ fvwm/menustyle.c	3 Jan 2010 02:26:34 -0000
@@ -133,11 +133,28 @@
 	case PixmapMenu:
 	case TiledPixmapMenu:
 		fpa.mask = (Pdepth <= 8)?  FPAM_DITHER:0;
-		destmf->u.p = PCacheFvwmPicture(
-			dpy, Scr.NoFocusWin, NULL, origmf->u.p->name,
-			fpa);
+	
+		/* Should never happen. */	
+		if (destmf->u.p) 
+		{
+			PDestroyFvwmPicture(dpy, destmf->u.p);
+			destmf->u.p = NULL;
+		}
+
+		if (origmf->u.p)
+		{
+			destmf->u.p = PCacheFvwmPicture(
+				dpy, Scr.NoFocusWin, NULL, origmf->u.p->name,
+				fpa);
+		}
+	
+		/* TA:  20090103: Don't copy the source colour, it's already
+		 * taken care of.  Doing so just overwrites that area of
+		 * memory with gibberish, ultimately crashing FVWM when
+		 * tear-off menus are in use.
+		 */	
 		fvwmlib_copy_color(
-			dpy, &destmf->u.back, &origmf->u.back, False,True);
+			dpy, &destmf->u.back, &origmf->u.back, False,False);
 		destmf->type = origmf->type;
 		break;
 	default:

Reply via email to