Subject: Re: purify menu UMR

From: Brad Giaccio <[email-masked]>
Date: Tue, 1 Feb 2000 13:18:10 -0500

On Mon, Jan 31, 2000 at 03:37:54PM +0100, Dominik Vogt wrote:
> 
> menus.c, line 739:
> 
>     if (!pop_menu_up(&(pmp->menu), pmp->parent_menu, pmp->pTmp_win,
> 		     pmp->pcontext, x, y, prefer_left_submenus,
> 		     key_press /*warp*/, pmp->pops, NULL, &do_warp_to_title))
> 
> Brad, can you isolate which of the parts of *pmp points to the
> stack?  Perhaps purify gives better output if you put lines like
> 
>   { void *foo = (void *)(pmp->menu); }
> 
> before the if-clause? (make sure the optimizer is turned off).
> 

Dominik, 

I give I just spent 2 hours with the debugger, purify and prints
statements and I can't figure out what it thinks is not initialized,
however it seems to only happen with the builtin windowlist, and it
isn't causeing a problem so I would say ignore it for now.

However I did manage to get purify to give me the memory leaks this
time.  And I thought you might be able to track them, check SUBJECT:
purify memory leaks.

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: 01 Feb 2000 14:20:19 -0500

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

  bg> I give I just spent 2 hours with the debugger, purify and prints
  bg> statements and I can't figure out what it thinks is not
  bg> initialized, however it seems to only happen with the builtin
  bg> windowlist, and it isn't causeing a problem so I would say ignore
  bg> it for now.

Are there bitfields in the vicinity?

One thing I discovered when playing with GNU make and Purify is that
Purify doesn't grok individual bitfields being set as initializing.

For example, if you have a bitfield and you init just that one bit:

  struct { foo:1; bar:1; } baz;

  baz.bar = 0;

    ...

  if (baz.bar) ...

Purify (at least in my tests) would report a UMR for the if-statement; I
guess it doesn't see setting just one bit of the int as initializing the
whole thing, and it only has a char granularity or something.

If you zero the entire struct with memset() or similar, then Purify
doesn't complain.

Not sure if that's the case here, just thought I'd pass that along...

-- 
-------------------------------------------------------------------------------
 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: Brad Giaccio <[email-masked]>
Date: Wed, 2 Feb 2000 09:52:50 -0500

Well I've managed to track down the ABR's thanks to gdb.  Here is the
fix witch I will commit but if anyone sees any weird button results from
there configs let me know.

The problem was we do an sscanf twice using offset to increase the
s pointer however in my case the second sscanf returned -1 which we
checked, but on a failed sscand the value of oofset didn't change, so it
incremented the pointer when it shouldn't have.

Brad
--- builtins.c  2000/01/31 21:10:08     1.241
+++ builtins.c  2000/02/02 14:47:26
@@ -1315,8 +1315,8 @@
       else
       {
        b = BUTTON_INDEX(b);
-      }
       s += offset;
+      }
       if (b >= 0 && b < NUMBER_OF_BUTTONS)
        LoadDefaultButton(df, b);
       else

On Mon, Jan 31, 2000 at 08:48:10AM -0500, Brad Giaccio wrote:
> ****  Purify instrumented /home/bgiaccio/fvwm23/bin/fvwm2.bgiaccio (pid 14249)  ****
> ABR: Array bounds read:
>   * This is occurring while in:
> 	SkipSpaces     [Parse.c:130]
> 	DoPeekToken    [Parse.c:211]
> 	DoGetNextToken [Parse.c:323]
> 	GetNextToken   [Parse.c:335]
> 	ReadDecorFace  [builtins.c:1478]
> 	ReadTitleButton [builtins.c:1666]
> 	do_button_style [builtins.c:2224]
> 	AddButtonStyle [builtins.c:2245]
> 	ExecuteFunction [functions.c:829]
> 	AddToDecor     [builtins.c:1727]
> 	add_item_to_decor [builtins.c:1957]
> 	ExecuteFunction [functions.c:829]
>   * Reading 1 byte from 0x1398e0 in the heap.
>   * Address 0x1398e0 is 6 bytes past end of a malloc'd block at 0x1398c0 of 27 bytes.
>   * This block was allocated from:
> 	malloc         [rtlib.o]
> 	safemalloc     [safemalloc.c:42]
> 	expand         [functions.c:468]
> 	ExecuteFunction [functions.c:816]
> 	AddToDecor     [builtins.c:1727]
> 	add_item_to_decor [builtins.c:1957]
> 	ExecuteFunction [functions.c:829]
> 	run_command_stream [read.c:81]
> 	run_command_file [read.c:154]
> 	ReadFile       [read.c:209]
> 	ExecuteFunction [functions.c:829]
> 	HandleModuleInput [module_interface.c:615]
>