From: Tom Flynn (flynnt++at++cthulhu.engr.sgi.com)
Date: 08/01/2000 16:57:55
On Tue, 1 Aug 2000, Aline Normoyle wrote:
>
> 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?)
ElectricFence is one, you can also setenv MALLOC_CHECK_ to 0, 1, or 2
(see man malloc). There are also some purify-like things you can compile
into gcc, but I haven't had much luck with those.
>
> Looking inside pfuNewEventQ(), what's the diference between pfDPoolFind
> and pfDPoolAlloc?
I suspect the difference you're running into is that pfDPoolFind() will
loop through a linked list before returning the pointer to memory and
pfDPoolAlloc() will allocate the size needed (if enough space exists) and
then will return a pointer to the memory.
In 2.4, when the data pool is created, we make sure the next pointer for
the internal linked list is set to NULL. In 2.3, that one line isn't
there. I suspect what you're running into is a derefrencing of that next
pointer.
> 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?
So long as you're doing your own inter-process communication stuff and not
relying on any of the Shared Arena stuff being there (including using
pfMalloc() on a shared arena), you should be fine.
hope that helps,
tom
>
> 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."
> >
>
> -----------------------------------------------------------------------
> 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 - 16:57:59 PDT