Scott A. Friedman (scott++at++gsaup.ucla.edu)
Mon, 12 Feb 1996 11:23:43 -0800
I dug a little further and it appears that I am having a similar problem that showed up
here on info-performer a week or so ago. The pfBuffer::merge is crashing in
Process 15432: Stopped on signal SIGSEGV: Segmentation violation (default)
pfGroup::nb_clean(<stripped>) ["pfGroup.C":144, 0x5e8a773c]
Dave Russell wrote:
>
> John Rohlf wrote:
> >
> > A bug in 2.0 requires you to create parents before children
> > in the DBASE task. Death in pfGroup::nb_clean() is symptomatic of
> > this problem.
>
I don't think this is my problem either.
>
> I was aware of this bug, but I don't _think_ that this is my problem; unless,
> of course, the structure returned by pfdLoadFile is susceptible to this bug.
> In my code all that I do is set up a pfBuffer, call the loader and then
> attach the structure returned by the loader to the scene with a pfbufferAddChild.
> When I call pfBuffer::merge(), the forked process just stops and never returns
> (not to mention the model never appears in the scene).
>
Same thing - except I am not using pfdLoadFile - I am creating manually
>
> Unfortunately, this does not seem to be my only problem. In other code that
> I've been trying to develop, I never call the loader, and I'm certain that my
> code creates the tree from the top down. Here, unfortunately, the crash does
> not occur when I call merge, but rather when I call pfbufferAddChild.
>
I do not have the problem with pfBufferAddChild.
I am using the release version of Performer 2.0 running on an Indigo Impact.
Again,
Scott Friedman
UCLA
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:24 PDT