Re: pfBuffer/userData problems
John Rohlf (jrohlf++at++tubes)
Tue, 20 Feb 96 10:16:17 PST
>
>
> On Feb 19, 4:41pm, Ken Sakai wrote:
> > Subject: pfBuffer anomaly
> >
> >
> >
> > Fellow info-performers,
> >
> > I too am having troubles with pfBuffer/pfDBase.
> > I am successfully able to add a number of Inventor objects to my scene
> > using a pfDBase process taking the precautions mentioned previously in
> > info-performer. My problem occurs when I use pfNode::setUserData() in the
> APP
> > process on a seemingly successfully merged pfNode that has been created in
> the
> > DBASE process. My program cores with the following dump:
> >
> > > 0 pfMemory::getMemory(const void*)(0x10041bc0, 0x5be4088c, 0x65, 0x65)
> ["../../../lib/libpr/pfMemory.C":834, 0x5ae5889c]
> > 1 pfMemory::ref(void*)(0x10041bc0, 0x5be4088c, 0x65, 0x65)
> ["../../../lib/libpr/pfMemory.C":718, 0x5ae6f9c0]
> > 2 pfObject::setUserData(void*)(0x181d5e10, 0x10041bc0, 0x65, 0x65)
> ["../../../lib/libpr/pfObject.C":213, 0x5af4fcb0]
> > 3 pfUpdatable::pf_applyUpdate(const pfUpdatable*,int)(0x181d5e10,
> 0x181d7480, 0x65, 0x65) ["../../../lib/libpf/pfUpdatable.C":112, 0x5af13f28]
> > 4 pfNode::pf_applyUpdate(const pfUpdatable*,int)(0x10041bc0, 0x181d7480,
> 0x65, 0x70) ["../../../lib/libpf/pfNode.C":170, 0x5ae7ccfc]
> > 5 pfGeode::pf_applyUpdate(const pfUpdatable*,int)(0x181d5e10, 0x5be4088c,
> 0x65, 0x65) ["../../../lib/libpf/pfGeode.C":102, 0x5aec3c74]
> > 6 pfBuffer::pf_propagateUpdates(pfBuffer*,int)(0x18083800, 0x18076410,
> 0x0, 0x65) ["../../../lib/libpf/pfBuffer.C":229, 0x5ae68dc4]
> > 7 beginForkedCull(void)(0x10041bc0, 0x5be4088c, 0x65, 0x65)
> ["../../../lib/libpf/pfProcess.C":3473, 0x5ae74f80]
> > 8 mpCull(void)(0x10041bc0, 0x5be4088c, 0x65, 0x65)
> ["../../../lib/libpf/pfProcess.C":3551, 0x5ae7ad70]
> > 9 pfConfig(0x10041bc0, 0x180773a0, 0x0, 0x65)
> ["../../../lib/libpf/pfProcess.C":1630, 0x5aea9378]
> > 10 vdeApp::doit(int,char**)(this = 0x10007f28, argc = 2, argv =
> 0x7fffaf04) ["/lfs/smokey/uf1/sakai/vde075/src/app/app.cc":101, 0x40cfe0]
> > 11 main(argc = 2, argv = 0x7fffaf04)
> ["/lfs/smokey/uf1/sakai/vde075/src/vde.cc":18, 0x40c740]
> > 12 __start() ["crt1text.s":133, 0x40c4dc]
> >
> > Other than the call to pfBuffer::merge() in my pfDBaseFunc, what else do I
> > have to do in order to modify the pfNode's data in my APP process? Or is
> this
> > another one of pfBuffer's problems? I have been fighting this thing for
> > a while. Any help would be greatly appeciated.
> >
> > Thanks,
> >
> > Kenneth N. Sakai Email: sakai++at++lmsc.lockheed.com
> > Research Specialist/Computer Graphics Phone: (408) 756-0682
> > Lockheed Martin Missiles & Space
> > Sunnyvale, CA 94088-3504
> >-- End of excerpt from Ken Sakai
>
> On Feb 20, 11:32am, Morten Eriksen wrote:
> > Subject: Re: pfObject userData
> > > Question: Does the userData pointer have to point to a Performer
> > > reference counted memory? Man page examples always show userData being of
> that
> > > type.
> >
> > Ordinary application-allocated memory pointed to by userData will lead
> > to immediate exit upon the first cull process if you're running on
> > a multiprocessor machine.
> >
> > Morten
> >-- End of excerpt from Morten Eriksen
>
>
>
> On Feb 19, 8:56pm, Michael Jones wrote:
> > Subject: user data
> > does it work in the case where the user data is pfMalloc'ed?
> >
> > Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590
> > Michael T. Jones Silicon Graphics, Advanced Systems Division
> > mtj++at++sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
> > "Du musst Amboss oder Hammer sein" -- Goethe
> >-- End of excerpt from Michael Jones
>
>
> The user data that I was inserting was pointer to a non-pfMalloc'd C++
> object. I modified the C++ object's class by inserting operator new and
> operator delete that pfMalloc'ed and pfFree'ed object memory. My core
> problem disappeared. Is Morten Eriksen's above statement accurate? Do
> the pfObject man pages need a little clarification? I guess that I was
> just dodging these bullets in the past when I had done the same thing on
> non-pfDBase loaded nodes and not had a core dumping problem.
User data, like geoset attribute arrays, is one of those fuzzy areas
where non-pfMalloc'ed data usually works. However, we've found that
trying to support arbitrary data pointers is more trouble than
it's worth. Consequently, 2.0 has a formal policy that all
data supplied in the form of void*'s should be pfMalloc'ed.
Unfortunately, the pfObject man page was missed in the
documentation sweep.
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:52:26 PDT