Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <793477543.1221205424213.JavaMail.jira@brutus>
Date: Fri, 12 Sep 2008 00:43:44 -0700 (PDT)
From: "Stuart McCulloch (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Commented: (FELIX-721) NPE in FilterImpl.toString()
In-Reply-To: <807259163.1221188624358.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/FELIX-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630506#action_12630506 ] 

Stuart McCulloch commented on FELIX-721:
----------------------------------------

Actually I think I've figured out the bug...

org.apache.felix.framework.util.ldap.Operator has a public member field:

    // Place to store the reconstructed parsetree
    // Vector -> ArrayList is using jdk1.2 or later
    public Operator[] children = null;

and this member field gets re-assigned when the parsetree is rebuilt
(see the buildTree method in various Operator sub-classes in Parser)

ok, now if you look at the toStringInfix method of the Evaluator class, it
goes through the operators in the current program and calls each one
to rebuild the complete parsetree.

the toStringInfix method is in turn called from FilterImpl's toString:

    public String toString()
    {
        if (m_toString == null)
        {
            m_toString = new Evaluator(m_program).toStringInfix();
        }
        return m_toString;
    }

where m_toString is a volatile field - the idea I think is to cache the
result. However, because there's no synchronization on this field
it's possible that two or more threads could be calling toStringInfix
at the same time.

now each thread has its own Evaluator - but they are sharing the
same program, which means that the "children" member that has
the reconstructed parsetree could get reset by one thread while
it's being used by another thread - hence the NPE (null element)

phew... hope that makes some sense

> NPE in FilterImpl.toString()
> ----------------------------
>
>                 Key: FELIX-721
>                 URL: https://issues.apache.org/jira/browse/FELIX-721
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: felix-1.0.4
>            Reporter: Don Brown
>
> We see this NPE occasionally, probably 10% of the time on application startup:
>      [java] java.lang.NullPointerException
>      [java]     at org.apache.felix.framework.util.ldap.Parser$AndOperator.toStringInfix(Parser.java:601)
>      [java]     at org.apache.felix.framework.util.ldap.Evaluator.toStringInfix(Evaluator.java:184)
>      [java]     at org.apache.felix.framework.FilterImpl.toString(FilterImpl.java:242)
>      [java]     at java.lang.String.valueOf(String.java:2615)
>      [java]     at java.lang.StringBuffer.append(StringBuffer.java:220)
>      [java]     at org.springframework.osgi.service.importer.DefaultOsgiServiceDependency.<init>(DefaultOsgiServiceDependency.java:52)
>      [java]     at org.springframework.osgi.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:69)
>      [java]     at org.springframework.osgi.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:233)
>      [java]     at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:248)
>      [java]     at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:172)
>      [java]     at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:136)
>      [java]     at org.springframework.osgi.extender.internal.activator.ContextLoaderListener$2.run(ContextLoaderListener.java:746)
>      [java]     at java.lang.Thread.run(Thread.java:613)
> My first guess would be we are constructing a filter improperly in our Spring config, but the fact that it only happens some of the time is strange.  If nothing else, it would be nice if this bit of code was a bit more defensive.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.