pfBuffer/userData problems
Ken Sakai (sakai++at++sgi600.msd.lmsc.lockheed.com)
Tue, 20 Feb 1996 08:32:39 -0800
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.
Thanks
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:52:26 PDT