Re: performer memory management

New Message Reply Date view Thread view Subject view Author view

Steve Baker (sbaker++at++link.com)
Thu, 8 Oct 1998 08:53:12 -0500 (CDT)


On Thu, 8 Oct 1998, jason allen bryan wrote:

> i have a stumper for all the pfGuru's out there:
> while writing a small simulation in performer, i ran
> into some problems debugging pfVec3 and pfMatrix intensive
> code, specifically that code related to object placement
> and manipulation in a scene. it seems even the most basic
> operations on these class instances failed to function as
> expected. a pfVec3 would be initialized and work fine for
> one or two iterations, and then all of a sudden acquire
> illegal values for floating point numbers. normally i would
> assume a problem with my code. in this case, i was able to
> fix the problem by allocating a few more dummy pfVec3's
> before allocating those pfVec3's needed by the simulation.

I'd say it was pretty certain that something in your code
is writing off the end of an array - or continuing to write
to a structure that has been deleted or something like that.

Adding those extra dummy variables just changed which memory
location is being corrupted so that your program now *appears*
to work.

You might stand a chance of finding the problem with something
like Purify - or alternatively, you could initialise 'dummy' to
something distinctive and write code to check that it still
contains that distinctive value. Sprinkle calls to that checking
code around your program and you can sometimes home in on the
code that's misbehaving. On other occasions, introducing
the checking code simply moves the problem somewhere else!

You might also find the bug 'by inspection' by looking at which
variable was declared just before 'dummy' and looking everywhere
it was accessed.

However, there are no sure-fire ways to debug these kinds of
problems.

> i know performer has a great deal of run-time library support
> and that dynamic allocation of some performer classes is tricky,
> if not impossible. it seems to me the problem lies in performer's
> management of its shared memory arena.

I'd be *very* suprised if this was Performer's fault.

Steve Baker (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-2466 (Fax)
Work: SBaker++at++link.com http://www.hti.com
Home: SJBaker1++at++airmail.net http://web2.airmail.net/sjbaker1


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Thu Oct 08 1998 - 06:53:38 PDT

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