Subject: Purify run on 2.5.6

From: Dan Espen <[email-masked]>
Date: Wed, 11 Dec 2002 14:40:02 -0500

I've been working with Tomi on the premature close of OpenInterface
GUI problem without much success.  I've been able to recreate the
problem once or twice but not very consistently.

I've never created the problem with gdb attached or with debug
information printing.  Even without gdb or debug, its not consistent.

Anyway, I'll keep at it.

Since I saw inconsistent behavior I thought it might help to do some
Fvwm runs with Purify.  I don't think I'm going to be able to use
Purify with the GUI in question due to some firewall issues, but I did
run a few GUIs with child windows, resize windows, iconify windows
switch pages, and pop up menus.

2.5.6 looked pretty good.   All I see  are a few UMRs.  (Uninitialized
Memory Reads.)   Often  UMRs aren't  a problem.    Its  fine to   copy
uninitialized memory.  As long as you aren't  doing tests against that
memory there is no problem.

Here are the UMRs:

UMR: Uninitialized memory read:
  * This is occurring while in:
	__execute_function [functions.c:545]
	execute_function [functions.c:1176]
	StartupStuff   [fvwm.c:1498]
	My_XNextEvent  [events.c:3320]
	HandleEvents   [events.c:3240]
	main           [fvwm.c:2412]
	_start         [crt1.o]
  * Reading 4 bytes from 0x2c7480 in the heap.
  * Address 0x2c7480 is 16 bytes into a malloc'd block at 0x2c7470 of 124 bytes.
  * This block was allocated from:
	malloc         [rtlib.o]
	calloc         [rtlib.o]
	safecalloc     [safemalloc.c:64]
	exc_create_null_context [execcontext.c:96]
	exc_create_context [execcontext.c:117]
	StartupStuff   [fvwm.c:1465]
	My_XNextEvent  [events.c:3320]
	HandleEvents   [events.c:3240]
	main           [fvwm.c:2412]
	_start         [crt1.o]

UMR: Uninitialized memory read:
  * This is occurring while in:
	_SetFocusWindow [focus.c:922]
	HandleEnterNotify [events.c:1706]
	dispatch_event [events.c:3204]
	HandleEvents   [events.c:3242]
	main           [fvwm.c:2412]
	_start         [crt1.o]
  * Reading 4 bytes from 0xffbed118 on the stack.
  * Address 0xffbed118 is local variable "sf_args" in function _SetFocusWindow.

UMR: Uninitialized memory read:
  * This is occurring while in:
	DrawIconPixmapWindow [icons.c:1012]
	DrawIconWindow [icons.c:1250]
	HandleExpose   [events.c:1769]
	dispatch_event [events.c:3204]
	HandleEvents   [events.c:3242]
	main           [fvwm.c:2412]
	_start         [crt1.o]
  * Reading 4 bytes from 0xffbed0a0 on the stack.
  * Address 0xffbed0a0 is local variable "fra" in function DrawIconPixmapWindow.

-- 
Dan Espen                               E-mail: [email-masked]
--
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: Dominik Vogt <[email-masked]>
Date: Thu, 12 Dec 2002 12:58:22 +0100

> memory there is no problem.

While you're at it, please try out the new window shade features.

> 	HandleEvents   [events.c:3240]

I don't understand this one.  What code do you have in
functions.c, line 545?

> 	DrawIconPixmapWindow [icons.c:1012]

Should both the "fixed".  They are not really UMRs.  Purify seems
to be unable to handle btructs with bit fields properly.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 12 Dec 2002 09:02:32 -0500

> I don't understand this one.  What code do you have in

	if (expaction[0] == '*')

> to be unable to handle btructs with bit fields properly.

Thats right, there are a few things Purify gets wrong.
I'm not surprised that it doesn't track things at the bit level.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 12 Dec 2002 15:19:10 +0100

> > I don't understand this one.  What code do you have in

Hm.  Perhaps it's because the string is somthing between 13 and 15
characters, but expaction[0] reads four bytes?

> I'm not surprised that it doesn't track things at the bit level.

Maybe using bit fileds isn't this clever at all.  Sure it saves
several hundred bytes per window, but we pay this with additional
code and slower execution.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 12 Dec 2002 09:41:52 -0500

Dominik Vogt <[email-masked]> writes:
> > > >   * Address 0x2c7480 is 16 bytes into a malloc'd block at 0x2c7470 of 1
> 24 b
> > > ytes.

If the compiler caused code to be generated that accessed 4 bytes,
I think it generated bad code.  If you don't see anything wrong
then I think you should forget it.  Its not a perfect tool.

> code and slower execution.

If I remember correctly, we checked the code generated by the compilers
and bit field access generated code comparable to byte access.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 12 Dec 2002 16:12:12 +0100

> and bit field access generated code comparable to byte access.

But not when writing a bit.  To write a whole byte, the compiler
can just put the value into the byte.  But to write a single bit
in a bit filed structure a la

  struct
  {
    unsigned is_foo : 1;
    unsigned has_bar : 1;
  } flags;

It has to read the corresponding byte, set or delete the target
bit, then write it back.  At least if the assembler does not
support atomic bit operations.

Bye

Dominik ^_^  ^_^