Subject: Purify of latest stuff.

From: "Paul D. Smith" <[email-masked]>
Date: Fri, 20 Nov 1998 14:35:30 -0500 (EST)

Latest log.  Looks a lot cleaner; it seems to me that somehow fvwm is
getting a pointer to what it _thinks_ is an FvwmWindow, but actually is
something completely different; I think the "badness" starts at the ABR
around line 615 in the log.  Note it says:

  * Address 0x10898c is 77 bytes past end of a malloc'd block at 0x1088d8 of 104 bytes.

Now, an FvwmWindow structure is over 500 bytes long, so that t is
definitely not pointing to one of those if the allocated block is only
104 bytes.

Not sure how this could happen, really, but there you go.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 23 Nov 1998 12:04:47 +0100

On Fri, Nov 20, 1998 at 02:35:30PM -0500, [email-masked] wrote:
> Latest log.  Looks a lot cleaner;

I think I cleaned up everything except:

 - the coredump
 - the ABR with DoGetNextToken. Try as I might, I can't see anything
   that might be causing the ABR. I'm beginning to suspect your
   compiler is broken (?) I checked read.c, Parse.c, SetGlobalOpts
   etc. but found nothing. Since I don't have purify someone else
   should investigate that. It seems to be a whole class of violations
   not necessarily related to DoGetNextToken. They all seem to cause
   the ABR 69 or 87 bytes behind __new_handler.

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

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 23 Nov 1998 12:07:12 +0100

Could you try to get fvwm running by commenting the Close/Delete/Destroy
lines? I can't do much about the coredump without purify, but if you
have some output with memory leaks I can at least do something.

Bye

Dominik