Re: Distorted picture sometimes and: _pfDirtCheck: pfRealloc of 0 bytes returned NULL.
Marc Erich Latoschik (marcl++at++TechFak.Uni-Bielefeld.DE)
Tue, 15 Dec 1998 09:46:51 +0100
Don Burns wrote:
>
> On Nov 20, 10:14am, Marc Erich Latoschik wrote:
> > Subject: Distorted picture sometimes and: _pfDirtCheck: pfRealloc of 0 byt
> > Hello friends
> > i have a new one that you might have encountered before.
> >
> > As i wrote in a former mail i am currently porting a Performer 2.0 based
> > n32 application on irix 6.2 compiled with CC 7.2 to
> > Performer 2.2 on Irix 6.4 (Octane) and compiler version 7.2.1.
> >
> > First i encountered "_pfDirtCheck: pfRealloc of 0 bytes returned NULL"
> > during
> > every start of the ported application. (The old one is running fine with
> > no problems)
> > I could get rid of this error by linking SGI's specific lib malloc into
> > the app.
> > You might allready know the definition problem of realloc(0) in
> > different
> > stdlibs.
> > Now the new application starts "most of the time". Meaning sometimes i
> > get the
> > error again. Restarting it then helps most of the time...;).
> >
> > BUT...
> > In about 9 of 10 cases you can see nothing or distorted geometry on the
> > screen,
> > the window stays blank or it displays only red flickering tiles or
> > stripes
> > where objects should be displayed on the screen. The application runs
> > on, and no errors occure.
> > I have lots of debug output in my code and it says that the application
> > is
> > doing what it should. Well, but as u can inspect it doesnt do it
> > visually of course.
> >
> > I really don't know if this is a software or hardware (pipe) problem. I
> > think it is
> > software (due to the realloc problem?). Maybe something with the memory
> > management.
> > Because i can start all other viewers, gview, perfly or even when i use
> > the maschine
> > as a remote display and let the old (not ported) application run on a
> > different maschine
> > everything is fine.
> > The behaviour obly starts when i use the newly compiled app on the local
> > irix6.4 maschine.
> >
> > I have no further clues...
> > Does somebody have one?
> >
>
> Just a guess: I have seen this error when calling process specific class
> functions. For example, if you try to do a pfTexture->apply() in APP, or CULL,
> you can get the same error message. Make sure that you are not making any
> calls that require a graphics context from a process that does not have a
> graphics context.
>
> If this is correct, then the fact that it works "sometimes", is an indication
> that either you are lucky when it does run, or, there is something different in
> the multiprocess model from one run to another (PFMP_DEFAULT may use
> PFMP_APPCULLDRAW in some cases).
>
> Hope that helps,
Nope it doesn't...:)
But after exhausted debugging i think i tracked the bug down and
you might be interested in. After i configure the pipewindows
in a config callback, where the FB is set and the windows are opened
via pfOpen (of course using the C++ API, so PipeWin->open() ),
i check every possible return value to see if the configuration
i was requesting (how many windows, what place, how many channels,pipes
and attached
objects) was fullfilled.
And i check PipeWin->isOpen()
Obviously that one crashes on the ported application.
Why?
The old program runs on Indigo2 Extremes
The ported one on an Octane.
And there seems to be a "race condition". The octane is to fast, it
reaches
the isOpen() much earlier then the Indigo2's. On the octane the windows
are
not yet opened (Multiprocessing). And the isOpen() doesn't return false,
no
it crashes with the described behaviour. If i comment the statement out
everything is fine. As does a sleep(3) (sleep(2) is not enough
***lol***)
So there is the mystery...
>
> -don
>
> --------------------------------------------------------------
> Don Burns
> Graphics Consulting Practice 650-933-8611
> Silicon Graphics Computer Systems don_burns++at++sgi.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
--
bye
Marc
********************************************************************************
Marc Erich Latoschik, AG-WBS, Technische Fakultaet der Universitaet
Bielefeld
Universitaetsstrasse 25
Postfach 100 131
33501 Bielefeld
Raum M4-122
Fon: (0521) 106 2919
Fax: (0521) 106 2962
marcl++at++techfak.uni-bielefeld.de
http://www.TechFak.Uni-Bielefeld.DE/techfak/persons/marcl/
********************************************************************************
This archive was generated by hypermail 2.0b2
on Tue Dec 15 1998 - 00:47:07 PST