| Summary: | Classloader leak in DirContextURLStreamHandler | ||
|---|---|---|---|
| Product: | Tomcat 6 | Reporter: | Nikita Salnikov-Tarnovski <nikita> |
| Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | default | ||
| Hardware: | All | ||
| OS: | Mac OS X 10.4 | ||
|
Description
Nikita Salnikov-Tarnovski
2014-03-17 09:14:26 UTC
Hmm. For this to happen an exception would have to be thrown during web application stop that prevented the code that de-registers the associated class loader from being called. 8.0.x is immune to this issue because the registration and deregistration code has been removed as part of the refactoring of resource handling. I've been through the 7.0.x code and I can't see any obvious way to trigger this. All the obvious exceptions that could trigger the problem are caught, logged and not re-thrown. The only exceptions excluded from the process are fatal to the JVM anyway. I do see a possible way to trigger this memory leak in 6.0.x but I need to do some testing to confirm it. Confirmed. A filter that throws an unchecked exception on destroy can trigger this. This issue has been fixed in 7.0.x. I'll look at putting together a proposal to back-port the changes to 6.0.x I've back-ported the fix and tested that it works. The fix has been proposed for 6.0.x. This has been fixed in 6.0.x and will be included in 6.0.40 onwards. |