On 9/21/07, Steve Loughran <[EMAIL PROTECTED]> wrote: > Peter Reilly wrote: > > 1) Some of the traces seem to imply a bug. > > > clearly :) > > > org.apache.tools.ant.taskdefs.Property$PropertyResolver.evaluate(Property.java:110) > > at > > org.apache.tools.ant.PropertyHelper.getProperty(PropertyHelper.java:787) > > - locked <0x00002aaab4013548> (a > > org.apache.tools.ant.PropertyHelper) > > at > > org.apache.tools.ant.PropertyHelper.parseNextProperty(PropertyHelper.java:541) > > at > > org.apache.tools.ant.PropertyHelper.parseProperties(PropertyHelper.java:502) > > at > > org.apache.tools.ant.RuntimeConfigurable.maybeConfigure(RuntimeConfigurable.java:390) > > The intent of Property.PropertyResolver is I think to remain in > > the Property task - the trace seems to imply that it has > > escaped from that task. > > I think it is looping. There is a per-thread stack to detect this, but > it isnt working. Otherwise the loop wouldnt happen. > > This could be some wierd race condition in the JVM itself, which may be > reordering operations in the single thread. Remember, unless your > variable is tagged as volatile, or the block is synchronized, Java can > swap the order of actions. It can even reorder volatile access in Java <1.5 I know, but 1) I do not know why a ThreadLocal (shudder) is needed here, this means that the code is more complicated than it needs to be. and 2) even with the above, the clone operation should have protected the rest of the system as the tasks deletete is only added to the cloned property helper which is local to the method.
In any case, I think that the code is too slow for a very common code path in ant. Peter > > -steve > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
