Re: pfNode::isect() on deep scenes.

New Message Reply Date view Thread view Subject view Author view

From: Bram Stolk (bram++at++sara.nl)
Date: 04/11/2002 09:06:00

On Thu, 11 Apr 2002 11:49:17 -0400 (EDT)
Jason Daly <jdaly++at++ist.ucf.edu> wrote:

>
> Something similar, yes. I've sent in at least three messages on this topic
> in the past and have gotten no reply. Our problem is that the
> pfNode::isect() call completes, but when we query the path, it is incomplete.
> The first few nodes (always a multiple of 32) are valid, but the rest
> are NULL, even though the space has been allocated for them.

Eh.. I think it is more serious than you describe here, because
I get my crash BEFORE I query the path.

Also, I make sure not to reference any elt above 31 in paths,
and all the other elts I extract from the path, I check for
nil. This indeed sometimes happens, and I simply ignore those
cases.

So I get my crash inside pfNode::isect() itself, not by referencing
illegal pfPath elements.

Also, I checked the SGI known bugs database.
See:
http://support.sgi.com/irix/bugs/browse/Performer_by_num.scr.html

It is not listed.
Maybe it should be filed officially? Or is the recommended way
of bug reporting via this list?

thx,

  Bram

>
> We've seen it consistently at 32 nodes or deeper under IRIX. Under Linux
> occasionaly happens at 32 nodes, but it seems to happen more often at 64
> nodes. We don't have any scenes deeper than 90 or so, so I'm not sure
> if the multiple of 32 trend would continue at 96.
>
> Nobody has commented on it, so we ended up implementing a workaround that
> traces the pfPath and checks for a NULL value that happens prematurely
> (based on the length of the path as reported by pfPath::getNum()). It then
> backs up one path element, transforms the pfSeg's and does another isect().
> It's ugly, and there are occasional instances where it doesn't seem to work,
> but it's better than nothing.
>
> I'd love to have this problem fixed. I believe it has existed since at
> least Performer 2.2. It would be great if someone from the Performer
> team could at least acknowledge the problem. I'd be happy to send
> a minimal test case that we've put together.
>
>
> On Thu, 11 Apr 2002, Bram Stolk wrote:
>
> > Hello,
> >
> >
> > I am getting crashes on pfNode::isect() when isecting with geometry
> > that has been deeply nested.
> >
> > I get bus errors and segm violations.
> >
> > Interestingly, I can intersect geometry that is at lvl 30 with
> > no problem, even if the entire scene is 100 deep.
> > But if I intersect something in the same scene at levels of
> > 32 and above, I get crashes.
> >
> > I do my intersections with pfPath specifications enabled.
> >
> > Maybe pfPaths cannot be larger than 32 entries?
> >
> > The crash occurs in pfNode::isect() itself, before I can
> > access the pfPath structure.
> >
> > I am on IRIX and an Onyx IR2.
> > For a dbx trace, see:
> >
> >
> > > 0 pfList::reset(void)(0x3ed17245, 0x0, 0x400, 0x0, 0x4becb60, 0x0, 0x0, 0x49b0fe74) ["/build/perfbuild/perftot1/perf/lib/libpr/pfList.C":536, 0x4525008]
> > 1 pfNode::pf_isect(pfSegSet*,pfHit***,pfChannel*,pfMatrix*)(0x3ed17245, 0x0, 0x0, 0x0, 0x4becb60, 0x0, 0x0, 0x49b0fe74) ["/build/perfbuild/perftot1/perf/lib/libpf/pfNode.C":1388, 0x43b5400]
> > 2 pfNode::nb_isect(pfSegSet*,pfHit***)(0x3ed17245, 0x0, 0x400, 0x0, 0x4becb60, 0x0, 0x0, 0x49b0fe74) ["/build/perfbuild/perftot1/perf/lib/libpf/pfNode.C":875, 0x43b3fe0]
> > 3 pfNode::isect(pfSegSet*,pfHit***)(this = 0x481d9fd0, segSet = 0x7fff1e88, hits = 0x7fff2308) ["/usr/include/Performer/pf/pfNode.h":193, 0x49fc89c]
> > 4 Selector::FindIntersected(pfNode*,pfMatrix&,float)(this = 0x101e6600, root = 0x481d9fd0, mat = 0x49b16740, grabsize = 4.0) ["/home/sara/bram/saradist/src/sarasim/selector.C":170, 0x49fd1f8]
> >
> > Anyone experienced something similar?
> >
> > thx
> >
> > Bram
>
>
> --"J"
>
> "I'm a castaway stranded in a desolate land,
> I can see the footprints in the virtual sand."
> --Neil Peart
>
> 

-- 
------------------------------------------------------------------------------
 Bram Stolk, VR Specialist.
 SARA Academic Computing Services Amsterdam, PO Box 94613, 1090 GP  AMSTERDAM
 email: bram++at++sara.nl   Phone +31-20-5923059  Fax +31-20-6683167

 "I heard if you play the NT-4.0-CD backwards, you get a satanic message."
 "Thats nothing, if you play it forward, it installs NT-4.0"
------------------------------------------------------------------------------

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Apr 11 2002 - 09:09:41 PDT

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