Bug 1103735 - Classloader leak in JBossCachedAuthenticationManager
Summary: Classloader leak in JBossCachedAuthenticationManager
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Security
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: DR7
: EAP 6.4.0
Assignee: Emmanuel Hugonnet (ehsavoie)
QA Contact: Pavel Slavicek
URL:
Whiteboard: ShouldBeFixed
Depends On:
Blocks: 1139561
TreeView+ depends on / blocked
 
Reported: 2014-06-02 12:39 UTC by Josef Cacek
Modified: 2019-08-19 12:44 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
secured-webapp.war (6.27 KB, application/zip)
2014-09-22 13:59 UTC, Josef Cacek
no flags Details
Screenshot - Eclipse MAT (337.43 KB, image/png)
2014-09-22 14:00 UTC, Josef Cacek
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-3429 0 Critical Resolved Classloader leak in JBossCachedAuthenticationManager 2017-10-10 01:48:07 UTC

Description Josef Cacek 2014-06-02 12:39:23 UTC
When using a security domain with cache-type="default" then the ModuleClassLoader instances related to deployments leak through JBossCachedAuthenticationManager.

The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment).

One option to solve this issue could be to remove the cache entries which are related to the undeployed application.

Steps to reproduce:

1) Add a user to the ApplicationRealm (linked with "other" security domain)
./add-user.sh -a -u user1 -p password1! -r ApplicationRealm -g app-user

2) start the AS
./standalone.sh

2) deploy a web application with a secured servlet allowing access to role "app-user" (No security domain is referenced in the jboss-web.xml, so the default domain "other" is used.)
./jboss-cli -c "deploy /tmp/secured-webapp.war"

3) open the servlet URL in the browser and login as a "user1" with password "password1!"

4) redeploy the application
./jboss-cli -c "undeploy secured-webapp.war"
./jboss-cli -c "deploy /tmp/secured-webapp.war"

=> LEAK - the first deployment's ModuleClassLoader is not destroyed, because it's referenced through the LoginContext instance from the JBossCachedAuthenticationManager

Comment 1 Emmanuel Hugonnet (ehsavoie) 2014-06-16 06:49:39 UTC
https://github.com/ehsavoie/jboss-eap/tree/BZ-1103735 waiting for new picketbox release.

Comment 2 Josef Cacek 2014-09-22 13:45:16 UTC
Verification failed. I still see the ModuleClassLoader referenced from the DomainInfo.

Comment 3 Josef Cacek 2014-09-22 13:59:08 UTC
Created attachment 940023 [details]
secured-webapp.war

Use the attached reproducer.
After the 2nd deployment use Eclipse Memory Analyzer (MAT) to dump the heap and make following steps:

1) Open OQL view and run following query:
SELECT f FROM org.jboss.modules.ModuleClassLoader f WHERE (f.module.identifier.name.toString() = "deployment.secured-webapp.war")

2) Select each entry and use context menu (right click) to run command:
Merge Shortest Paths to GC Roots->Exclude all phantom/weak/soft etc. references

3) Check the references (look at the attached screenshot)

Comment 4 Josef Cacek 2014-09-22 14:00:00 UTC
Created attachment 940024 [details]
Screenshot - Eclipse MAT

Comment 6 Emmanuel Hugonnet (ehsavoie) 2014-10-17 12:51:08 UTC
I don't see the same results as you Josef. Could you help me with MAT ?
The old module loader is still here BUT there is no references attached to it

Comment 7 Emmanuel Hugonnet (ehsavoie) 2014-10-20 12:56:00 UTC
PR: https://github.com/jbossas/jboss-eap/pull/1822


Note You need to log in before you can comment on or make changes to this bug.