Re: pfHighlight crash

New Message Reply Date view Thread view Subject view Author view

Rob Jenkins (robj++at++quid)
Wed, 11 Dec 1996 15:53:34 -0800


Kaylor

This is another case where I'd say it may be worth your while logging a support
call. If anyone on this list has ideas that solve your problem then great but
in the event of that not happening we can work it with you. The sort of thing
we'd look at first are what patches you have, if anything in particualar causes
the crash and all that. Have you tried narrowing the code down to a small
example that shows the same problem ? It may prove useful if you could. The
whole SYSLOG output would be helpful too. Have you run the code through a
profiler, say Workshop to look for memory leaks etc ?

You certianly ought to have the Performer patch 1414 and there's a list of
other recommended Onyx patches that may depend in part on you situation.

Cheers
Rob
On Dec 11, 1:33pm, Kaylor Brett wrote:
> Subject: pfHighlight crash
> All,
>
> Long time listener, first time caller. I am using an ONYX, RE2 (2
> pipes),
> 2 R4400, 5.3, Performer 2.0.
>
> I create a pfHighlight from the SharedArena. I re-use the same
> highlight and do not
> delete it.
>
> I have tried pfuTravNodeHlight as well as geoSet->setHlight on the
> geoSets I want to highlight (not both methods at once).
>
> My application turns on and off the highlights rapidly.
>
> Now, my application may run correctly for hours, but other times just
> minutes.
> It crashes one of two ways.
>
> One is the death of child draw. The highlight causes the draw process
> to crash
> deep inside pfDraw. Here is the callstack.
>
> -----------------------------------------------------------------------
> ----- --------------------------------------
> drawX_FLAT_TRISTRIPS_NvVv(gset = 0x1832f230, coords = 0x18313208 =
> "=6\0214>j\026\036<P\023\251=\002\fJ>j\026\036<P\023\251=6\0214>w\027Y",
> norms = 0x18296c60 = "\200", colors = <null pointer>, texCoords = <null
> pointer>) ["gststrip.C":732]
> pfHighlight::pr_hlFill(this = 0x1833d7f0) ["pfHighlight.C":939]
> pfHighlight::pr_draw(this = 0x1833d7f0) ["pfHighlight.C":780]
> pfGeoSet::pr_drawHlightOnly(this = 0x18398840, _hl = 0x1833d7f0)
> ["gsdraw.C":4402]
> pfGeoSet::pr_drawHlighted(this = 0x18398840, _coords = 0x183131f0 =
> "=6\0214>w\027Y<P\023\251=\002\fJ>w\027Y<P\023\251=6\0214>j\026\036<P\02
> 3\251=\002\fJ>j\026\036<P\023\251=6\0214>w\027Y", _norms = 0x18296c60 =
> "\200", _colors = 0x181d5640 =
> ">\356\356\357>\343\260~>\304\304\305\?\200", _tcoords = <null pointer>)
> ["gsdraw.C":4348]
> genDrawGSet(gset = 0x18398840, coords = 0x183131f0 =
> "=6\0214>w\027Y<P\023\251=\002\fJ>w\027Y<P\023\251=6\0214>j\026\036<P\02
> 3\251=\002\fJ>j\026\036<P\023\251=6\0214>w\027Y", norms = 0x18296c60 =
> "\200", colors = 0x181d5640 =
> ">\356\356\357>\343\260~>\304\304\305\?\200", tcoords = <null pointer>)
> ["gsdraw.C":4501]
> pfDispList::pr_caseDL_DRAW_GSET_GSTATE(data = 0x18978a6c)
> ["pfDispList.C":937]
> pfDispList::pr_drawFlat(this = 0x18978890) ["pfDispList.C":1546]
> pfDispList::draw(this = 0x18978890) ["pfDispList.C":400]
> pfChannel::pf_drawScene(this = 0x180d07c0) ["pfChannel.C":1747]
> pfChannel::pf_draw(this = 0x180d07c0) ["pfChannel.C":1739]
> pfDraw() ["pfProcess.C":3874]
> Draw(chan = 0x180e93e0, data = 0x0) ["Draw.C":133]
> pfChannel::pf_callDrawFunc(this = 0x180d07c0) ["pfChannel.C":1805]
> doDraw(drawChan = 0x180d07c0) ["pfProcess.C":3768]
> mpDraw() ["pfProcess.C":4079]
> pfConfig() ["pfProcess.C":1639]
> CApp::InitPerformer(this = 0x7fffae84, config = 0x10061148)
> ["CApp.C":909]
> CApp::CApp(this = 0x7fffae84, config = 0x10061148) ["CApp.C":184]
> main(argc = 2, argv = 0x7fffaf04) ["Main.C":98]
> __start() ["crt1text.s":133]
> -----------------------------------------------------------------------
> ----- ----------------------------------------
>
> Sometimes it will cause the graphics to dump. The message in the SYSLOG
> is a
> fifo overflow.
>
> I have run this on another machine (same config, but with 4 processors)
> and get the same
> result.
>
> Any help would be greatly appreciated.
>
> brett.
>
> ============================================
> Brett B. Kaylor
> Software Engineer
> GTE Government Systems
> 1805 West Drake Drive
> Tempe, AZ 85283
>
> brett.kaylor++at++mtv.gtegsc.com
>
> Tel: 602.777.1725
> Fax: 602.777.1717
> ============================================
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Kaylor Brett

-- 
________________________________________________________________
Rob Jenkins mailto:robj++at++csd.sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:09 PDT

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