Re: Purify

New Message Reply Date view Thread view Subject view Author view

Don Hatch (hatch++at++hell.asd.sgi.com)
Fri, 13 Dec 1996 19:53:12 -0800

On Dec 13, 8:02am, Ted Purcell wrote:
> Subject: Purify
> Hello Micheal and to All Peoples Concerned,
>
> I recently received your email regarding Purify and its abilities to detect
> errors in "real-time" applications (not run-time, which Purify detects). I
> am very curious as to what error messages that you were receiving from
> Purify on the mentioned app. Please forward this information to me so that I
> may provide you with the proper answer to your problems.
>
> We have recently upgraded Purify/ PureCoverage to versions 4.0 respectively,
> which may have alleviated the problems. Were you using this version or a
> later version of the tool?
>
> We are dedicated to providing high quality software development tools to our
> customers and if you can help us in accomplishing this goal, with any new
> information, we would be greatly appreciative!
>
> Have a great day and thank you very much in advance for your valuable time
> in this matter.
>
>
>
> To: info-performer++at++sgi.com
> From: "Michael M. Allbright" <m-allbright1++at++ti.com>
> Subject: Real-Time Debugging of Performer Apps
> Date: Thu, 12 Dec 1996 13:43:28 -0800
> Reply-To: "Michael M. Allbright" <m-allbright1++at++ti.com>
>
>
> Has anyone had any success with real time debugging applications such as
> Purify, Insure++, etc. in debugging Performer applications.
>
> I have spent some time debugging with Purify, to no avail. In order to perform
> the tests, I locked down to one processor and created a wrapper to translate
> amalloc and afree calls to malloc and free respectively (amalloc and afree are
> called by pfMalloc and pfFree). Nevertheless, Purify spat out thousands of
> errors messages which, on inspection, appeared to be in error themselves.
>
> I just got an evaluation copy of Insure++, but I wanted to see if anybody out
> there had any experience with this before I invest further time.
>
> Thanks
> --Mike
>
> Ted Purcell Jr. "Improving Software
> Corporate Sales Quality Everywhere!"
> Ph. (408) 524-3207 Pure Atria Corporation
> Fx. (408) 720-9200 1309 S. Mary Avenue
> tpurcell++at++pureatria.com Sunnyvale, CA. 94087
>
> Web Address: http://www.pureatria.com
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Ted Purcell

Hi Ted,

There are three big problems that keeps Purify from
being as useful as it could be for Performer programs
(multithreaded graphics programs in general).
These problems exist with Purify version 4.0 on SGI machines.

1. Purify does not know about amalloc/afree/arealloc, which are
   the shared memory allocation routines used by virtually
   every part of Performer.
   Part of this missing functionality in Purify can be regained by
   recompiling with those functions defined as malloc/free/realloc,
   and then forcing Performer to run in single-process mode (i.e. partially
   lobotomizing Performer), as Michael Allbright described.

   There are also other memory allocation routines
   (usmalloc, etc.) which I think are also not recognized by Purify,
   though they are less frequently used.

2. Performer's memory allocation routines pfMalloc et al.
   are wrappers for amalloc/afree/arealloc
   that allocate a chunk of memory slightly bigger
   than requested, and prepend a small header that is used internally.
   Accessing the header outside of pfMalloc etc.
   should be an illegal memory access, but Purify can not catch it.

3. There are hundreds of graphics routines (different for different
   kinds of SGI graphics hardware) that Purify does not work well with,
   mostly generating UMRs and ZPWs.
   Probably these are what Michael is referring to.
   I believe the UMRs are mostly from kernel calls that fill in memory
   that Purify does not know about.
   Deciding which of these errors are worth pursuing requires
   a lot of guesswork on the part of the developer.

   Fixing these problems will require a lot of
   work and communication between graphics engineers at SGI and Pure Atria,
   to sort out which bugs are SGI's and which are Purify's,
   and to come up with a general plan for making Purify know about
   graphics routines on existing and future machines.
   Unfortunately this is not happening, and Purify continues to fall
   distressingly short of being the incredibly useful tool that
   it should be (and would be with the proper support from SGI).

Don

-- 
Don Hatch  hatch++at++sgi.com  (415) 933-5150  Silicon Graphics, Inc.
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:09 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.