You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2014/08/25 19:21:01 UTC
[jira] [Commented] (DERBY-3745) Derby can leak classloaders in an
app server environment
[ https://issues.apache.org/jira/browse/DERBY-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109332#comment-14109332 ]
ASF subversion and git services commented on DERBY-3745:
--------------------------------------------------------
Commit 1620379 from [~dagw] in branch 'code/trunk'
[ https://svn.apache.org/r1620379 ]
DERBY-6619 After silently swallowing SecurityExceptions, Derby can leak class loaders
Patch derby-6619-2.
The fix introduced in DERBY-3745 correctly is there in order to
protect against the case where the thread that starts Derby, has a
context class loader that is different from the system class
loader. In such cases, if the timer thread inherits the context class
loader, the context class loader will stay in memory until the Derby
engine is shut down, even if all other references to the class loader
are gone.
If the context class loader is the same as the system class loader, on
the other hand, such a "leak" would not be a problem, since the system
class loader will stay in memory until the JVM is shut down anyway.
We take advantage of this and only attempt to change the context class
loader if it is different from the system class loader. With this
patch, no warning is printed to derby.log when starting the server
from the command line, and there's no warning when starting the server
using the API with a security manager installed when the context class
loader hasn't been changed from the default. However, if the server is
started using the API with a non-default context class loader, we do
see warnings in derby.log if a security manager is installed and the
permission to set the class loader is missing.
Added tests for this behavior. Moved utility methods from
UpgradeClassLoader to ClassLoaderTestSetup, a new decorator. It seemed
more logical to put them there to allow reuse.
> Derby can leak classloaders in an app server environment
> --------------------------------------------------------
>
> Key: DERBY-3745
> URL: https://issues.apache.org/jira/browse/DERBY-3745
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.1.1
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Fix For: 10.3.3.1, 10.4.2.0, 10.5.1.1
>
> Attachments: cdevbabejgjd.html, derby-3745_10.3_diff.txt, derby-3745_10.3_diff2.txt, derby-3745_BaseMonitor_cleanup_diff.txt, derby-3745_doc_diff.txt, derby-3745_fix_build_warning_diff.txt, derby-3745_policy_files_diff.txt, derby-3745_removePrivThreadOps_diff.txt, derby-3745_trunk_diff.txt, derby.log, derby3745_backport_to_104_diff_v1.txt, derby3745_backport_to_104_stat_v1.txt
>
>
> A user reported potential class loader leaks in Derby
> ...The first one looks like Derby created a long-running
> thread and copying the context class loader. To fix, the
> context class loader should be saved/set/restored around the
> creation of the new thread so that it copies some benign class
> loader instead (e.g., null or getClass().getClassLoader()):
> 0x42278e58 java/lang/Thread@302e302e
> [truncating at running thread LEAK]
> Object: 0x42278e58 java/lang/Thread@302e302e
> Children:
> 0x42278ee0 java/lang/String@303f303f
> 0x4226e558 java/lang/ThreadGroup@6f2e6f2e
> 0x42278e40
> org/apache/derby/impl/services/monitor/AntiGC@603a603a
> 0x419cfac0
> The second is another long running thread. The same applies:
> 0x426fe7a0 java/lang/Thread@19901990
> [truncating at running thread LEAK]
> Object: 0x426fe7a0 java/lang/Thread@19901990
> Parents:
> 0x4226e5a8 [Ljava/lang/Thread;@6f386f38
> 0x426fe548
> org/apache/derby/iapi/services/context/ContextManager@19421942
> Children:
> 0x426fe838 java/lang/String@19a319a3
> 0x4226e558 java/lang/ThreadGroup@6f2e6f2e
> 0x426fe4f8
> org/apache/derby/impl/services/daemon/BasicDaemon@19381938
> 0x419cfac0
> The third is a TimerThread owneed , which is created when a
> Timer is created. The same applies:
> 0x425ac538 java/util/Timer$TimerImpl@6b8a6b8a
> [truncating at running thread LEAK]
> Object: 0x425ac538 java/util/Timer$TimerImpl@6b8a6b8a
> Parents:
> 0x41faaf58 [Ljava/lang/Thread;@3c583c58
> Object: 0x425ac510 java/util/Timer@6b856b85
> Parents:
> 0x425ac500
> org/apache/derby/impl/services/timer/SingletonTimerFactory@56e25
> 6e2
> For more info, see thread at:
> http://www.nabble.com/ClassLoader-leaks--td18121374.html
--
This message was sent by Atlassian JIRA
(v6.2#6252)