Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!uunet!lotus!paulk
From: paulk@lotus.com (Paul Kleppner LID-02264)
Newsgroups: comp.sys.next
Subject: Re: MallocDebug Incompatible with ProcessMonitor?
Keywords: -lMallocDebug,ProcessMonitor,MallocDebug
Message-ID: <1991Feb11.181205.16113@lotus.com>
Date: 11 Feb 91 18:12:05 GMT
References: <4616@network.ucsd.edu>
Reply-To: paulk@lotus.UUCP (Paul Kleppner)
Organization: Lotus Development Corp.
Lines: 30

In article <4616@network.ucsd.edu> pbiron@weber.ucsd.edu (Paul Biron) writes:
[problems about MallocDebug, and ProcessorMonitor]

Here's a suggestion for one of the ProcessMonitor problems you mentioned
in your article ("can't connect to an app started from
the command-line").  I bet if you use the "open" command
to start your app from the shell, ProcessMonitor will be able to see it.
(See open(1) for details.)

A couple of other problems I've noticed using MallocDebug.

The first is:  MallocDebug "fakes" the use of zones.  Although a report
generated by MallocDebug shows the zone numbers that were requested
for each node, the nodes are not actually placed into zones.  This could
be confusing for anybody who is looking at the MallocDebug output and
attempting to correlate the node addresses with memory pages.

The second is: when using the MallocDebug libraries,  the NXZoneFromPtr()
only works when passed a pointer to the beginning of an allocated node.
It does NOT work when passed an address somewhere in the middle of
the allocated node.  (It always returns the default zone in this case.)
If the MallocDebug libraries are not used, NXZoneFromPtr() works in
both cases.

These bugs notwithstanding, I must say that MallocDebug is a *very*
nice tool to have.

Paul Kleppner
Lotus
paulk@lotus.com