segfault in pfuProcessClipCenters caused by flight loader

New Message Reply Date view Thread view Subject view Author view

Daniel Oberlin (dan++at++mak.com)
Tue, 2 Feb 1999 11:39:13 -0500

Hello again,
   I recently wrote the list about some problems that I was having with a
segfault in pfuProcessClipCenters in my application. Since my previous
post, I have discovered that this problem only occurs when I statically link
the Performer flight loader to my application. In fact, the problem can be
reproduced by statically linking the flight loader to perfly by adding
"-L/usr/lib32/Performer/Static/libpfdb -lpfflt_ogl" to the link line.
  To summarize, when I run our application on our IMPACT machine (not
cliptexture capable), it segfaults in pfuProcessClipCenters. When I run on
an IR, things work fine. My original post is included below.
   Is this a known problem, and if so, are there any workarounds? Our
application needs to be cliptexture capable and we like to provide a
statically linked version of our application to our customers.

Thanks,
Daniel Oberlin

>
>Greetings pfAll,
> I am trying to add cliptexture functionality to a Performer application.
>Our application is based on a version of perfly which predates
cliptextures.
>My strategy has been to try adding the code in perfly which deals with
>cliptextures. I don't have time to learn the Performer cliptexture API and
>I am hoping that the pfutility functions used in perfly will automatically
>handle cliptextures for me.
> I have added the following code to initChannel(), initSceneGraph(), and
>preCull() as is done in perfly. As far as I can tell, this is the only
code
>in perfly that deals with cliptextures:
>
>-----
>
>initChannel()
>{
>
>...
>
>/* to indicate that the cliptexture center is to be set by masterChannel.
> this has to be done after channels are initialized */
>
> {
> pfList *mpcliptextures = pfNewList(sizeof(pfMPClipTexture*), 1,
>pfGetSharedArena());
> pfuProcessClipCentersWithChannel((pfNode *)ViewState->sceneGroup,
>mpcliptextures, ViewState->masterChan);
> pfDelete(mpcliptextures);
> }
>}
>
>
>int initSceneGraph(pfScene *scene)
>{
>
>...
>
>/* Process all the cliptextures in the scene */
>
> {
> void *arena = pfGetSharedArena();
> pfPipe *masterPipe = pfGetPipe(0);
>
> pfList *mpcliptextures = pfNewList(sizeof(pfMPClipTexture*), 1,
>arena);
> pfuProcessClipCenters((pfNode *)scene, mpcliptextures);
> (void)pfuAddMPClipTexturesToPipes(mpcliptextures, masterPipe,
NULL);
> pfDelete(mpcliptextures);
>
> /* set cliptexture incremental state to the visual channel - GUI is
>chan 0 */
> for(i = pfGetMultipipe() - 1; i >= 0; i--)
> {
> pfPipe *p = pfGetPipe(i);
> if(p == masterPipe)
> pfPipeIncrementalStateChanNum(masterPipe, 1);
> else
> pfPipeIncrementalStateChanNum(p, 0);
> }
> }
>
>...
>
>}
>
>
>void preCull(pfChannel *chan, void *data)
>{
> /*
> * Handle gridify toggle.
> * Only the input process modifies ViewState->gridify, and only the
> * cull process modifies ViewState->gridified (always attempting to
make
> * it equal to ViewState->gridify, and doing the actual gridification/
> * ungridification). This way there are no races
> * and the current state of gridification is unambiguous from the
> * point of view of either process.
> *
> * Gridify should only do master cliptextures; the slaves own no
> * tiles, and invalidating the master will invalidate slaves as well.
> */
> if(chan != ViewState->masterChan)
> return;
>
>printf("**: preCull\n");
> if (ViewState->gridify != ViewState->gridified)
> {
> int i;
> for (i = pfGetMultipipe()-1; i >= 0; --i)
> {
> pfPipe *pipe = pfGetPipe(i);
> int j;
> for (j = pfGetPipeNumMPClipTextures(pipe)-1; j >= 0; --j)
> {
> pfClipTexture *cliptex =
>
>pfGetMPClipTextureClipTexture(pfGetPipeMPClipTexture(pipe,j));
>if (ViewState->gridified)
> (void)pfuUnGridifyClipTexture(cliptex);
> else
> (void)pfuGridifyClipTexture(cliptex);
> }
> }
>
> ViewState->gridified = !ViewState->gridified;
> }
>}
>
>-----
>
>When I load a database without cliptextures on a non-IR machine, I get a
>segfault in pfuProcessClipCenters:
>
>-----
>
>Process 4116 (Stealth) stopped on signal SIGSEGV: Segmentation violation
>(default) at [pfMemory::isOfType(pfType*):75 ,0x5e3f4f20]
> Source (of /build/perfbuild/perftot0/perf/lib/libpr/pfType.h) not
>available for Process 4116
>(dbx) where
>> 0 pfMemory::isOfType(pfType*)(0x18efdd90, 0x0, 0x1badbebe, 0x18340dc0,
>0x18efdd90, 0x1, 0x1bad0000, 0x3a)
>["/build/perfbuild/perftot0/perf/lib/libpr/pfType.h":75, 0x5e3f4f20]
> 1 pfMemory::isOfType(const void*,pfType*)(0x0, 0x0, 0x1badbebe,
>0x18340dc0, 0x18efdd90, 0x1, 0x1bad0000, 0x3a)
>["/build/perfbuild/perftot0/perf/lib/libpr/pfMemory.C":859, 0x5e4f6d9c]
> 2 ::pfIsOfType(0x18efdd90, 0x0, 0x1badbebe, 0x18340dc0, 0x18efdd90, 0x1,
>0x1bad0000, 0x3a)
["/build/perfbuild/perftot0/perf/lib/libpr/cMemory.C":142,
>0x5e5688ac]
> 3 cbProcessClipCenterNodes(0x18efdd90, 0x0, 0x1badbebe, 0x18340dc0,
>0x18efdd90, 0x1, 0x1bad0000, 0x3a)
>["/build/perfbuild/perftot0/perf/lib/libpfutil/clipcenter.c":75, 0x42da00]
> 4 pfuTraverse(0x1, 0x7fff2dc0, 0x1badbebe, 0x18340dc0, 0x18efdd90, 0x1,
>0x1bad0000, 0x3a)
>["/build/perfbuild/perftot0/perf/lib/libpfutil/trav.c":245, 0x450a54]
> 5 pfuProcessClipCenters(0x18efdd90, 0x0, 0x194b7a10, 0x18340dc0,
>0x18efdd90, 0x1, 0x1bad0000, 0x3a)
>["/build/perfbuild/perftot0/perf/lib/libpfutil/clipcenter.c":127, 0x42db3c]
>
>-----
>
>I have been trying to fix the problem by looking for any Performer related
>differences between my application and perfly, but I have had little
>success. If anyone can suggest what the problem might be, or at least
point
>me in the right direction, I would greatly appreciate it.
>
>Thanks,
>Dan Oberlin
>
>
>

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Tue Feb 02 1999 - 08:41:59 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.