Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Wed, 6 Dec 2017 18:28:00 +0000 (UTC)
From: "Ali Kamali (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.13123265.1512584859000.401027.1512584880128@Atlassian.JIRA>
In-Reply-To: <JIRA.13123265.1512584859000@Atlassian.JIRA>
References: <JIRA.13123265.1512584859000@Atlassian.JIRA> <JIRA.13123265.1512584859079@jira-lw-us.apache.org>
Subject: [jira] [Created] (FELIX-5759) StackOverflowError thrown during URL
 construction
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 06 Dec 2017 18:28:06 -0000

Ali Kamali created FELIX-5759:
---------------------------------

             Summary: StackOverflowError thrown during URL construction
                 Key: FELIX-5759
                 URL: https://issues.apache.org/jira/browse/FELIX-5759
             Project: Felix
          Issue Type: Bug
            Reporter: Ali Kamali
            Priority: Critical


I get the following callstack resulting in a stack overflow error when building a URL object:
{code}
[info]   at org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:401)
[info]   at java.net.URL.<init>(URL.java:622)
[info]   at java.net.URL.<init>(URL.java:490)
[info]   at org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:401)
[info]   at java.net.URL.<init>(URL.java:622)
[info]   at java.net.URL.<init>(URL.java:490)
[info]   at org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:401)
[info]   at java.net.URL.<init>(URL.java:622)
[info]   at java.net.URL.<init>(URL.java:490)
[info]   at org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:401)
[info]   at java.net.URL.<init>(URL.java:622)
[info]   at java.net.URL.<init>(URL.java:490)
[info]   at org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:401)
[info]   at java.net.URL.<init>(URL.java:622)
[info]   at java.net.URL.<init>(URL.java:490)
[info]   at org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:401)
[info]   at java.net.URL.<init>(URL.java:622)
[info]   at java.net.URL.<init>(URL.java:490)
[info]   at org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:401)
{code}

Using org.apache.felix.framework 4.4.1 and Java 1.8.0_111 running on Ubuntu.

We started getting this exception after upgrading to Spark 2.2.0, after some investigation we realized Spark 2.2.0 registers its own {{URLStreamHandlerFactory}}:
{code}
package org.apache.spark.sql.internal

object SharedState extends Logging {
  try {
    URL.setURLStreamHandlerFactory(new FsUrlStreamHandlerFactory())
  } catch {
    case e: Error =>
      logWarning("URL.setURLStreamHandlerFactory failed to set FsUrlStreamHandlerFactory")
  }
...
{code}

Looks like the bug is related to line 128 in {{URLHandlers.java}}:
{code}
            URLStreamHandler handler = getBuiltInStreamHandler(protocol, factory);
            if (handler != null)
            {
                URL url = new URL(protocol, null, -1, "", handler);
                m_handlerToURL.put(handler, url);
            }
{code}
This code assumes there is a unique mapping from handlers to protocols, which doesn't seem to be a valid assumption, at least not with Spark. Spark URL handler factory is returning the same handler instance for both {{file}} and {{ftp}} protocols. When {{URLHandlers}} is initializing it first tries to register a handler for {{file}} and then for {{ftp}}, but because the factory returns the same handler we end up replacing the URL object we have for {{file}} with {{ftp}} in {{m_handlerToURL}}.

Later when a URL is being constructed it calls {{createURLStreamHandler}} from URLHandlers, at the end of this method:
{code}
        // If built-in content handler, then create a proxy handler.
        return addToStreamCache(protocol,
            new URLHandlersStreamHandlerProxy(protocol, m_secureAction,
                handler, (URL) m_handlerToURL.get(handler)));
{code}

Note that it's trying to use {{m_handlerToURL}} to look up the protocol for the handler, and in case of {{file}} instead of returning a URL with protocol set to {{file}} it returns a URL with protocol set to {{ftp}}, so {{URLHandlersStreamHandlerProxy}} gets constructed with {{m_builtInURL}} set to {{ftp}}.

Later in URL.java we have this code:
{code}
            if ((context != null) && ((newProtocol == null) ||
                            newProtocol.equalsIgnoreCase(context.protocol))) {
                // inherit the protocol handler from the context
                // if not specified to the constructor
                if (handler == null) {
                    handler = context.handler;
                }
{code}
This code only uses the handler if protocols match, but in this case protocols don't match because it's expected to be {{file}} but we receive {{ftp}} that comes from {{m_builtInURL}}, and the code falls back to asking the factory to create a new handler:
{code}
            if (handler == null &&
                (handler = getURLStreamHandler(protocol)) == null) {
                throw new MalformedURLException("unknown protocol: "+protocol);
            }
{code}

The factory returns a handler with protocol set to {{ftp}} again and we get stuck in a loop.

Looking at the newest Felix code looks like the assumption of having a unique handler per protocol is still there, so I believe this bug still exists in the newest Felix as well.

To reproduce this bug before starting a bundle you only need to register a factory that returns the same handler instance for {{file}} and {{ftp}}.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)