Re: _pfDirtCheck - dbx catch - DRAW process

New Message Reply Date view Thread view Subject view Author view

Sharon Clay (src++at++rose.asd.sgi.com)
Thu, 20 Mar 1997 02:39:58 -0800


+>---- On Mar 14, 1:02pm, David Florek wrote:
> Subject: Re: _pfDirtCheck - dbx catch - DRAW process
->

->I also have submitted a report regarding pfApplyFog() generating the
->following apparent bug (message approximated):
->
->PF Warning/Internal: _pfDirtCheck: attempt to reallocate 0 bytes
-> from/for a NULL pointer
->
->with about the same level of response. About all I've heard is that this
->sporadically shows up as a result of various apply() calls (i.e., in C++
->internally, fog->apply()).

I have not heard this!
I looked for your hot-line call and could not find it - by any chance
did you file a test case and can you send me the call number?

->It would seem to me that any attempt to
->reallocate 0 bytes for a NULL pointer is indeed a bug and should be
->handled before any call to pfRealloc or whatever _pfDirtCheck() is calling.
->I suspect that the system is attempting to copy the structure internally,
->and isn't correctly checking for NULL pointers, but since Performer has
->been so kind as to encapsulate its structure definitions, I can't do much
->in the way of tracking the actual cause of the bug.
->
->Does anyone on the Performer team wish to address the recurring
->_pfDirtCheck() issues?

_pfDirtCheck is really a simple end-of-food-chain routine and the most likely
problem (unless you are hitting the N32 bug that was in Performer2.0)
is that _pfDirtCheck is a victim of some other earlier memory corruption
which caused malloc to return NULL inside _pfDirtCheck.
In later versions of Performer,
including Performer 2.0.2 where we fixed the N32 problem, we check
for a null return from the realloc routine.
For general memory corruption, the dmalloc libarary from our web page
can help find these things, otherwise, a test case will be necessary (and
welcome!) for us to help more. I know that can be hard in things like
this, but I really can't make any further helpful guesses at this point.

src.

-- 
-----{-----{---++at++   -----{----{---++at++   -----{----{---++at++   -----{----{---++at++
Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev.
src++at++sgi.com  (415) 933 - 1002  FAX: (415) 965 - 2658  MS 8U-590
-----{-----{---++at++   -----{----{---++at++   -----{----{---++at++   -----{----{---++at++
=======================================================================
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:55 PDT

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