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:23:07 -0800

+>---- On Mar 13, 7:04pm, BOCCARA Michael wrote:
> Subject: _pfDirtCheck - dbx catch - DRAW process
->
->[ plain text
-> Encoded with "quoted-printable" ] :
  Hi Performers,
->
->It's been a vlong time I get a pfdirtcheck error infinite loop in my program.
->Such an error occurs when I use PFMP_APPCULL_DRAW mode, and disapears in
->PFMP_APPCULLDRAW mode.
->
->I asked this bug on the pfmailinglist several weeks ago.
->Since I felt it was linked with the use of the libpfpfb library, Sharon Rose
->Clay and Rob Mace (the libpfpfb master) told me to load the patch for
->Performer 2.0.2.

Actually, the reason we asked you to load the 2.0.2 patch is that this
sounds _exactly_ like the only bug we have ever known with pfDirtCheck
which was an N32 compiler bug that cause an end-condition on a loop
in that routine to not pass and we could inf loop through memory, as
shown below. It only happened after a large number of deleted objects
to cause us to get into that section of code.
Anyway, we put a work-around for this bug N32 into the 2.0.2 patch in libpf.

->I did it, with no success.
->I am working on an Onyx RE2, 1 RM4, 2 R4400 CPU's, IRIX 5.3, and now
->Performer 2.0.2

Well, if you are 5.3 then you aren't running N32.
In which case _pfDirtCheck could potentially be a victim of memory
corruption elsewhere. By any chance have you tried our debugging
malloc library that can catch some cases of memory corruption and
is available from the ftp area on our web page.

Barring that, by any chance does perfly show this problem if you
load your database into it? Can you make a test case that you
can file with the hotline? (and send me the case number which makes
it easier to find the call).

         

->Question 1 : does any of you have an experience of this bug ?
->
->PF Notice/Usage: pfMemory::unref() Attempt to unreference
->memory with 0 reference count.
->PF Print: He He !!!
->PF Notice: Using 60Hz video rate.
->PF Notice/Usage: pfMemory::unref() Attempt to unreference
->memory with 0 reference count.
->PF Print: He He !!!
->PF Notice/Usage: pfMemory::unref() Attempt to unreference
->memory with 0 reference count.
->PF Print: He He !!!
->
->....
->
->PF Warning/Internal: _pfDirtCheck: bad pfObject index 420546736
->PF Print: Ha Ha !!!
->PF Warning/Internal: _pfDirtCheck: bad pfObject index 420546736
->PF Print: Ha Ha !!!
->PF Warning/Internal: _pfDirtCheck: bad pfObject index 420546736
->PF Print: Ha Ha !!!
->PF Warning/Internal: _pfDirtCheck: bad pfObject index 420546736
->PF Print: Ha Ha !!!
->
->and so on ...
->
->A you see this is not a fatal error, but an infinite loop that occurs in the
->DRAW process. In some of the first frame loops I also get this
->"pfMemory::unref" error.
-

-- 
-----{-----{---++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.