Re: Reg. bug# 2195 Xerces2: XMLAttributesImpl::removeElementAt corrupts the list

[Pavani Mukthipudi <Pa...@Sun.COM>]

Thanks for the explanation Glenn !

The fact that they are "fill-in" objects somehow slipped off my mind.
Agreed.

Regards,
Pavani



> Subject: Re: Reg. bug# 2195 Xerces2: XMLAttributesImpl::removeElementAt 
corrupts the list
> To: Pavani Mukthipudi <Pa...@sun.com>
> From: "Glenn Marcy" <gm...@us.ibm.com>
> Date: Mon, 3 Sep 2001 08:53:53 -0400
> X-MIMETrack: Serialize by Router on d27ml602/27/M/IBM(Release 5.0.8 |June 18, 
2001) at 09/03/2001 07:51:05 AM
> 
> 
> 
> > I guess you were talking about XMLAttributesImpl::removeAttributeAt()
> > 'cause there's no removeElementAt() in XMLAttributeImpl.
> 
> Thanks for the catch...  I guess I was thinking about the similar method
> used in typical collection classes and got them mixed up.  I have updated
> the bug report.
> 
> > Can you please give me a scenario wherein the list gets corrupted ??
> > I don't think that'll happen at any point 'cause fLength is
> > incremented only when a new  attribute is added to the list.
> 
> As to the defect itself, you must keep in mind that the instance is reused
> across many calls to startElement(...) by the parser.  The fAttributes
> array
> contains "fill-in" objects for this purpose.  When you start you have:
> 
>     fLength = 0;
>     fAttributes[0] = <obj1>; fAttributes[1] = <obj2>;
>     fAttributes[2] = <obj3>; fAttributes[3] = <obj4>;
> 
> Now say the first call "adds" two attributes.  That just causes the first
> two
> entries in the array to be filled in.  If the first is a namespace
> declaration
> and we are removing such declarations from the list before calling the
> handler,
> there will be a call to removeAttributeAt(0) when fLength is two.
> 
> The current code is:
> 
>     if (attrIndex < fLength - 1) {
>         System.arraycopy(fAttributes, attrIndex + 1, fAttributes,
> attrIndex,
>                          fLength - attrIndex - 1);
>     }
>     fLength--;
> 
> Now after the call the array will look like this:
> 
>     fLength = 1;
>     fAttributes[0] = <obj2>; fAttributes[1] = <obj2>;
>     fAttributes[2] = <obj3>; fAttributes[3] = <obj4>;
> 
> Note that obj1 has been "lost" to the garbage collector and that during the
> next
> call that adds two attributes we will fill in <obj2> once for the first
> specified
> attribute, and then overwrite that object with the values of the second
> attr on
> the second addAttribute(...) call.  The new code I supply in the defect
> report
> addresses these problems.
> 
> Regards,
> Glenn
> 
> Glenn Marcy
> Chief Architect
> High Performance XML Processing
> IBM
> 
> 


-- 

Pavani Mukthipudi
Sun Microsystems Inc.

Phone: 080 - 2298989   Extn: 87390


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org