Summary: | File descriptor leak at web.xml loading | ||
---|---|---|---|
Product: | Tomcat 7 | Reporter: | Jean-Marie LAMARE <jeanmarie.lamare> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 7.0.33 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All |
Description
Jean-Marie LAMARE
2013-03-15 08:53:36 UTC
Hi, Did you observe that in some real situation? Basically the following is specified for org.xml.sax.InputSource [1] "However, standard processing of both byte and character streams is to close them on as part of end-of-parse cleanup, so applications should not attempt to re-use such streams after they have been handed to a parser." Regards Violeta [1] http://docs.oracle.com/javase/6/docs/api/ Hello The following file are opened after a WAR deployment on my computer (I've used the command handle written by the sys internal team). java.exe pid: 3984 CASTCORP\JML C: File (RW-) C:\java\apache-tomcat-7.0.33\bin 54: File (R-D) C:\TEMP\hsperfdata_jml\3984 5C: Section \Sessions\1\BaseNamedObjects\hsperfdata_JML_3984 E0: File (RW-) C:\java\jdk1.6.0_35_x64\jre\lib\rt.jar 1E8: File (RW-) C:\java\apache-tomcat-7.0.33\bin\bootstrap.jar 1EC: File (RW-) C:\java\apache-tomcat-7.0.33\bin\commons-daemon.jar 1F0: File (RW-) C:\java\apache-tomcat-7.0.33\bin\tomcat-juli.jar 1F4: File (RW-) C:\java\apache-tomcat-7.0.33\logs\catalina.2013-03-15.log 1F8: File (RW-) C:\java\apache-tomcat-7.0.33\logs\localhost.2013-03-15.log 1FC: File (RW-) C:\java\apache-tomcat-7.0.33\logs\manager.2013-03-15.log 200: File (RW-) C:\java\apache-tomcat-7.0.33\logs\host-manager.2013-03-15.log 204: File (RW-) C:\java\jdk1.6.0_35_x64\jre\lib\jsse.jar 208: File (RW-) C:\java\jdk1.6.0_35_x64\jre\lib\ext\dnsns.jar 20C: File (RW-) C:\java\apache-tomcat-7.0.33\lib\annotations-api.jar 210: File (RW-) C:\java\apache-tomcat-7.0.33\lib\catalina-ant.jar 214: File (RW-) C:\java\apache-tomcat-7.0.33\lib\catalina-ha.jar 218: File (RW-) C:\java\apache-tomcat-7.0.33\lib\catalina-tribes.jar 21C: File (RW-) C:\java\apache-tomcat-7.0.33\lib\catalina.jar 220: File (RW-) C:\java\apache-tomcat-7.0.33\lib\ecj-3.7.2.jar 224: File (RW-) C:\java\apache-tomcat-7.0.33\lib\el-api.jar 228: File (RW-) C:\java\apache-tomcat-7.0.33\lib\jasper-el.jar 22C: File (RW-) C:\java\apache-tomcat-7.0.33\lib\jasper.jar 230: File (RW-) C:\java\apache-tomcat-7.0.33\lib\jsp-api.jar 234: File (RW-) C:\java\apache-tomcat-7.0.33\lib\servlet-api.jar 238: File (RW-) C:\java\apache-tomcat-7.0.33\lib\tomcat-api.jar 23C: File (RW-) C:\java\apache-tomcat-7.0.33\lib\tomcat-coyote.jar 240: File (RW-) C:\java\apache-tomcat-7.0.33\lib\tomcat-dbcp.jar 244: File (RW-) C:\java\apache-tomcat-7.0.33\lib\tomcat-i18n-es.jar 248: File (RW-) C:\java\apache-tomcat-7.0.33\lib\tomcat-i18n-fr.jar 24C: File (RW-) C:\java\apache-tomcat-7.0.33\lib\tomcat-i18n-ja.jar 250: File (RW-) C:\java\apache-tomcat-7.0.33\lib\tomcat-jdbc.jar 254: File (RW-) C:\java\apache-tomcat-7.0.33\lib\tomcat-util.jar 27C: File (RW-) C:\java\jdk1.6.0_35_x64\jre\lib\ext\localedata.jar 288: File (RW-) C:\java\jdk1.6.0_35_x64\jre\lib\resources.jar 304: File (RW-) C:\java\jdk1.6.0_35_x64\jre\lib\jce.jar 308: File (RW-) C:\java\jdk1.6.0_35_x64\jre\lib\ext\sunjce_provider.jar 31C: File (R-D) C:\Windows\System32\en-US\KernelBase.dll.mui 338: File (RW-) C:\java\jdk1.6.0_35_x64\jre\lib\charsets.jar 33C: File (RW-) C:\java\apache-tomcat-7.0.33\logs\localhost_access_log.2013-03-15.txt 354: File (RW-) C:\java\jdk1.6.0_35_x64\jre\lib\charsets.jar 440: File (RW-) C:\java\apache-tomcat-7.0.33\conf\web.xml 454: File (RW-) C:\java\apache-tomcat-7.0.33\conf\web.xml 964: File (RW-) C:\java\apache-tomcat-7.0.33\temp\system4547162881526958771.jar 990: File (RW-) C:\java\apache-tomcat-7.0.33\temp\bootstrap5643731443438317122.jar 9A8: File (RW-) C:\workspaces\pmc_Contrex\jvmagent\jvmagent.jar So the sys internal utility observes it in a real situation. I've discoverer this bug thanks a JVM agent which rewrites FileInputStream and FileOutputStream bytecodes. This one ensures that FileInputStream.close is called after the constructor invocation. Is the bugs due to a missing close call there ? 1312 if (entry != null && entry.getGlobalTimeStamp() == globalTimeStamp && 1313 entry.getHostTimeStamp() == hostTimeStamp) { 1314 return entry.getWebXml(); 1315 } ... 1321 entry = hostWebXmlCache.get(host); 1322 if (entry != null && entry.getGlobalTimeStamp() == globalTimeStamp && 1323 entry.getHostTimeStamp() == hostTimeStamp) { 1324 return entry.getWebXml(); 1325 } Sometimes, the web.xml file is not parsed and the stream is not closed Thanks for the report. Fixed in trunk and 7.0.x and will be included in 7.0.39 onwards. |