From: Aline Normoyle (aline++at++mak.com)
Date: 08/01/2000 14:54:07
Hi Tom,
Unfortunately, I'm still having problems in my pfuInitInput function.
Our app (the "stealth") keeps crashing when it tries to create an event
queue. I've checked the ordering in main and it seems to be o.k. (I've
copied main below -- sorry about its messiness). I've spent some time
trying to use dmalloc to get a clue about what's going on, but I still
don't have a clue! (BTW, Do you guys know any good memory corruption/leak
tracking software for Linux?)
Looking inside pfuNewEventQ(), what's the diference between pfDPoolFind
and pfDPoolAlloc? Creating the queue using pfDPoolAlloc doesn't crash my
app immediately like pfDPoolFind does (the stealth still crashes later
though when it tries to use the queue). Is there a way that this other
function could be used instead? Using pfDPoolFind works great when
creating the mouse and xio stuff. Why is the queue different?
Lastly, I should mention that our product is mutliprocess -- though after
the work I did last week, all the performer stuff should be in the same
process. Do you think this is still problematic?
thanks,
Aline
********** here's our main() function *******A
int FreeInitCPUs = 1;
int AppCPU=-1, CullCPU=-1, DrawCPU=-1;
int
main(int argc, char *argv[])
{
pfNotifyLevel(PFNFY_ALWAYS);
pfInit();
InitSharedMem();
// Create the application object
#if DtDISVERS >= 5
application = new StApplication();
#endif
stealthOptions(argc, argv);
// Initialize plugins
stealthPluginInit();
setupDbCoordSys();
InitSharedMem2();
startXgui();
pfuInit();
InitConfig();
stealthInitTriBuffs();
// Fixes problems with aggregate billboards on IR
pfFeature(PFFTR_GLSPRITE, 0);
pfConfig();
stealthInit();
InitPipe();
pfFrame();
if (PrioritizeProcs)
pfuPrioritizeProcs(TRUE);
InitChannel();
pfuInitInput(pfGetChanPWin(ViewState->masterChan), ViewState->input);
stealthInitEvents();
if (ViewState->procLock == ((uint)~0))
{
if (AppCPU > -1)
pfuLockDownProc(AppCPU);
else
pfuLockDownApp();
}
pfFrameRate(ViewState->frameRate);
pfPhase(ViewState->phase);
stealthStart();
while (!SimDone())
{
pfSync();
pfFrame();
stealthTick();
}
/*
* Cleanup and exit.
*/
stopXgui();
stealthCleanup();
pfuFreeCPUs();
pfuExitInput();
pfuExitUtil();
pfExit();
return(0);
}
On Thu, 20 Jul 2000, Tom Flynn wrote:
>
> The the current single processor build of Performer on Linux is API
> compatable with Performer 2.2 on IRIX. Therefore all the datapool or
> arena calls still exist, but may be stubbed out or replaced with malloc()
> / free() etc. or contain other work arounds.
>
> The problem with pfuInitInput() you're seeing is probably related to where
> it is placed within main(). Try putting it after pfdInitConverter() and
> before pfConfig(). If the problem persists, please send us an email at
> mongoose-feedback++at++corp.sgi.com.
>
> hope that helps,
> tom
>
> On Thu, 20 Jul 2000, Aline Normoyle wrote:
>
> >
> > Hi,
> >
> > We're in the process of trying to port a performer application to linux
> > (Red Hat 6.2, gcc version egcs-1.1.2) using Performer 2.3.1. Throughout
> > the documentation, I keep seeing that Shared Arenas and pfDataPools are
> > not functional. I'm not sure what this means exactly, however, since the
> > calls still exist in the libraries and work most of the time (calls such
> > as pfGetSharedArena() are even being called in the perfly application).
> >
> > For example, in our application we are occasionally getting crashes in
> > pfDataPool::find. Here's the call stack:
> >
> > #0 0x40883e43 in pfDataPool::find () from /usr/lib/libpr.so
> > #1 0x408717b7 in pfDPoolFind () from /usr/lib/libpr.so
> > #2 0x4030d240 in pfuNewEventQ () from /usr/lib/libpfutil_ogl.so
> > #3 0x8143ac8 in initDataPool () at libpfu_input.c:130
> > #4 0x8143d6d in pfuInitInput (pw=0x86048a0, mode=2) at libpfu_input.c:252
> > #5 0x810b3ba in main (argc=4, argv=0xbffff7d4) at main.cxx:502
> >
> > libpfu_input.c is based on the file input.c from libpfutil and the two
> > functions, pfuInitInput and initDataPool, are identical to the ones which
> > came with 2.3.1.
> >
> > What types of things should we be doing to get around "not supported"
> > functions? Are there any obvious errors which would result in
> > pfDataPool::find to crashing?
> >
> > Any information regarding the current state of these memory functions
> > would be extremely helpful!
> >
> > thanks, Aline
> >
> > ***********************************************
> > * Aline Normoyle
> > * MaK Technologies Product Group
> > * (617) 876 - 8085 X 137
> > * aline++at++mak.com
> > ***********************************************
> >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
> >
>
> --
> "Mongooses are famous for their snake-fighting ability, and are
> almost always victorious because of their speed, agility, and timing
> and also because of their thick coat."
>
This archive was generated by hypermail 2b29 : Tue Aug 01 2000 - 14:55:13 PDT