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

Hartmut Lang commented on FELIX-4663:
-------------------------------------

The critical code parts in 1.3.2 are:
{code:title=AsyncDeliverTask.java}
final Thread currentThread = Thread.currentThread();
            TaskExecuter executer = null;
            synchronized (m_running_threads )
            {
                final TaskExecuter runningExecutor = 
(TaskExecuter)m_running_threads.get(currentThread);
                if ( runningExecutor != null )
                {
                    runningExecutor.add(tasks, event);
                }
                else
                {
                    executer = new TaskExecuter( tasks, event, currentThread );
                    m_running_threads.put(currentThread, executer);
                }
            }
            if ( executer != null )
            {
                m_pool.executeTask(executer);
            }
{code}

and

{code:title=DefaultThreadPool.java}
    public void executeTask(final Runnable task)
    {
        try
        {
            super.execute(task);
        }
        catch (final Throwable t)
        {
            LogWrapper.getLogger().log(
                    LogWrapper.LOG_WARNING,
                    "Exception: " + t, t);
            // ignore this
        }
    }
{code}

> Potential memory leak in AsyncDeliveryTask
> ------------------------------------------
>
>                 Key: FELIX-4663
>                 URL: https://issues.apache.org/jira/browse/FELIX-4663
>             Project: Felix
>          Issue Type: Bug
>          Components: Event Admin
>    Affects Versions: eventadmin-1.3.2
>            Reporter: Hartmut Lang
>
> EventAdmin 1.3.2 can create an OutOfMemory condition caused by not delivered 
> async events.
> The problem can occur if an interrupted thread issues an async event (e.g. 
> log-event).
> In EventAdmin 1.3.2 the async-delivery uses DefaultThreadPool based on 
> PooledExecutor. 
> If the already interrupted thread enters the execute-method in PooledExecutor 
> an InterruptedException is thrown before the TaskExecutor was added to the 
> Thread-Pool.
> This Exception is catched(not handled, only logged) in the DefaultThreadPool.
> As a result the TaskExecuter was not scheduled in the ThreadPool but is still 
> part of the m_running_threads.
> All new events are added to the pool of the TaskExecuter, adding in a 
> increasing LinkedList. The TaskExecutor is never started again. Memory is 
> leaking.
> Seems that 1.4.x is not vulnerable related to interrupted threads. But the 
> same catch-and-not-handle block is used in 1.4.x. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to