Re: Distorted picture sometimes and: _pfDirtCheck: pfRealloc of 0 bytes returned NULL.
Don Burns (don_burns++at++peru.csd.sgi.com)
Wed, 16 Dec 1998 12:47:34 -0800 (PST)
> 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...
Mystery indeed. Something is still wrong, however. The code for isOpen is
simply an inline :
int isOpen() const { return ((mode & _PFWIN_STATE_OPEN_MASK) ==
_PFWIN_STATE_OPEN); }
The only reason this would crash (by crash, I assume you mean, abort, core
dump, exit, etc.) is if PipeWin was not a valid pointer, and therefore the
reference to "mode" is invalid. I do not believe this is a race condition.
Have you verified that the Multiprocessing model is indeed the same (does the
Octane have two processors?)? Can you verify if PipeWin is a valid pointer?
-don
This archive was generated by hypermail 2.0b2
on Wed Dec 16 1998 - 12:49:07 PST