Note that on line 101 of, we have:

	for(int t= globalTG.numChildren()-1; t>=0; t--)

... that is, we're going backwards through the array of children.  We  
do this because of how I understood children were stored: in a  
packed, ordered fashion.  So if you deleted a child, all the children  
to its right would be slid down one index in the array.  Since we  
were deleting as we went (sometimes), going backwards would allow us  
to do all the children in order despite deleting some of them.  This  
*shouldn't* cause the array to get too small that the index (t) would  
be out of bounds in this line (110):

	            BranchGroup localBG = (BranchGroup)globalTG.getChild(t);

... but it appears to be doing so and I'm not sure why.  My first  
guess is that the line

                     globalTG.setChild(newlocalBG, t);

is mucking up the array in a way I hadn't anticipated.  So I'd start  
looking there.


On Oct 12, 2007, at 6:43 PM, Glen E. P. Ropella wrote:

> Hash: SHA1
> Sean Luke wrote:
>> This has got to be a bug in SparseFieldProtrayal3D's updateModel
>> method.  I can see all sorts of evil places where there's likely a  
>> bug
>> there -- the number one possibility is that globalTG.removeChild 
>> (t) may
>> be operating in the middle of the for-loop over  
>> globalTG.numChildren(),
>> which is probably not wise.  :-)
>> Unfortunately, I do not have enough time to look at this code and  
>> debug
>> it for a week or more (grant proposal deadline).  Gabriel might have
>> time possibly.
> OK.  I'll spend some time trying to track it down.  If I find  
> anything,
> I'll post it.  Thanks!
> - --
> glen e. p. ropella, 971-219-3846,
> If a man can't piss in his own front yard, he's living too close to
> town. -- Tom Russell
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> iD8DBQFHD/iRZeB+vOTnLkoRAiHWAJ9Kyye36NFGIklnocSjTuHrDY8LfgCg16pC
> Yya92t5CGO/5N3UCU4RX/+M=
> =1y9Y