BOCCARA Michael (MICHAEL.BOCCARA++at++siege.aerospatiale.fr)
Thu, 13 Mar 1997 19:04:50 +0100
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.
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
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.
I would like to catch the error with dbx.
In multiprocess mode, since the draw process is forked, I cannot get any call
stack with dbx in this process, which is the place where the pfdirtcheck
error occurs.
I used a notify handler to catch the calls to pfNotify, in order to be able
to stop the program at this function, and get the curent calling stack :
main()
<
pfNotifyHandler(notify_handler);
....
>
void
notify_handler(pfNotifyData *nfy_data)
<
pfDefaultNotifyHandler(nfy_data);
if(strstr(nfy_data->emsg, "unref")) <
pfNotify(PFNFY_ALWAYS, PFNFY_PRINT, "He He !!!");
if(strstr(nfy_data->emsg, "pfDirtCheck")) <
pfNotify(PFNFY_ALWAYS, PFNFY_PRINT, "Ha Ha !!!");
//kill(getpid(), SIGSEGV);
>
>
That's why you see the "He He" and "Ha Ha" captions in a few of the pfNotify
outputs.
The problem is : I still cannot stop correctly the program in the
"notify_handler" function.
I set a breakpoint at the line number where I write "He He", and the
breakpoint is set one line above. So the program stops every time the
pfNotify function is called, even if the severity is beyond the PFNFY_LEVEL
limit ; this is impossible to manage !
I also tried another technique, which is to provocate a SIGSEGV signal inside
the notify_handler ( kill(getpid(), SIGSEGV); )
But dbx does not stop at this point. Instead, the program exits, with a
message "Exiting program because of SIGCHILD signal". dbx always places
itself in the parent process (APP) point of vue, so tht I never can intercept
correctly a SIGSEGV inside a forked DRAW process.
Is there an option to set to dbx to make it debug in a given forked process ?
I hope this mail was not too ununderstandable. There are both bugs and
attempts to intercept them, which may not be very clear...
Thanks in advance for any help.
Mike
===================================List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:53 PDT