JDK-8022584 : Memory leak in NetworkInterface methods ex. isUP(), isLoopback()
  • Type: Bug
  • Status: Closed
  • Resolution: Fixed
  • Component: core-libs
  • Sub-Component: java.net
  • Priority: P3
  • Affected Version: 6u51,7,8
  • OS: linux
  • Submit Date: 2013-06-03
  • Updated Date: 2014-02-12
  • Resolved Date: 2013-08-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u60Fixed 8 b105Fixed
Related Reports
Duplicate :  
Duplicate :  
Description
FULL PRODUCT VERSION :
java version  " 1.7.0 " 
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux ubuntu 2.6.38-10-generic,
ARM linux  kernel 2.6

A DESCRIPTION OF THE PROBLEM :
Running some methods on NetworkInterface object causes memory leaks. This methods are at least isUp() and isLoopback(). I've observed it in both standard and embeded JRE. I've checked it also in OpenJDK, but no memory leaks were found there. I guess the problem is somewhere in libnet.so.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
ArrayList<NetworkInterface> tmpInterfaces =   Collections.list(NetworkInterface.getNetworkInterfaces());
for (NetworkInterface iface : tmpInterfaces) {
       iface.isLoopback();
       iface.isUp();
}

//memory leak is easy to observe if you run this in a loop
---------- END SOURCE ----------
Comments
Verified test: java/net/NetworkInterface/MemLeakTest.java http://aurora.ru.oracle.com/functional/faces/ChessBoard.xhtml?reportName=J2SEFailures&parameters=%5BtestNameFilterRegExp%5Djava%2Fnet%2FNetworkInterface%2FMemLeakTest.java%5Bjdkproduct%5DJava%28TM%29%25%5Brelease%5D1.8.0%5Bbuild%5D%25%5Bvmproduct%5DJava%25VM%25%5Bvmrelease%5D%25%5Bvmbuild%5D%25%5Bcomponent%5D%25%5Btags%5D%25%5BstartDate%5DSep+10%2C+2009+1%3A00%3A00+AM+MSD%5BendDate%5DSep+10%2C+2020+1%3A00%3A00+AM+MSK%5BrunNames%5D%27%27%5BbatchNames%5D%27%27%5BbatchNameFilterRegExp%5D%25%5BrunNameFilterRegExp%5D%25%5BtestsuiteNameFilterRegExp%5D%25%5Bstatuses%5D%281%3D1%29%5Bmatches%5D%281%3D1%29%5Bbundles%5Dnone&splitting=%5BY+axis%5Dfailure%2C+reason%2C+productConfiguration%2C+release%2C+build%2C+date%2C+buildType%5BZ+axis%5D%5BX+axis%5Dos%2C+bitness%5BComplement%5Dvmrelease%2C+vmbuild%2C+VMVersionString%2C+JDKVersionString%2C+tags%2C+groups%2C+platform%2C+truncatedProductConfiguration%2C+VMMode%2C+JDKProfile%2C+VMFlavor%2C+hostname%2C+osFlavor%2C+osVersion%2C+buildDate%2C+msDate%2C+baseline%2C+emb_arch%2C+batch%2C+runName%2C+harness%2C+testbaseVersion%2C+testbase%2C+fullTestsuite%2C+testsuite%2C+component%2C+baselineName%2C+crs%2C+bugType%2C+duration&reference=%5BOthers%5Drelease%2C+build%2C+vmrelease%2C+vmbuild%2C+VMVersionString%2C+JDKVersionString%2C+tags%2C+groups%2C+platform%2C+truncatedProductConfiguration%2C+buildType%2C+bitness%2C+productConfiguration%2C+VMMode%2C+JDKProfile%2C+VMFlavor%2C+hostname%2C+os%2C+osFlavor%2C+osVersion%2C+date%2C+buildDate%2C+msDate%2C+baseline%2C+emb_arch%2C+batch%2C+runName%2C+harness%2C+testbaseVersion%2C+testbase%2C+fullTestsuite%2C+testsuite%2C+component%2C+baselineName%2C+failure%2C+reason%2C+crs%2C+bugType%2C+duration%5BReference+Set%5D&mixReference=false&flags=&significance=empty&hideDataConfiguration=true&calculateSummary=false&showSummaryExpanded=false&showSummaryContents=true&showComplementAttributes=false&compactTables=true&viewStyle=chessboard&filter_override=
2014-01-07

Here's failure: Exception in thread "main" java.lang.Exception: FAIL: Virtual memory usage increased by 65536Kb (greater than 32768Kb) at MemLeakTest.main(MemLeakTest.java:65) Could you tell me about the timeout setup? Maybe it was because I ran the test in an incorrect way.
2013-08-19

Well, it's not a timeout issue. (timeout is set in jtreg tag string: @run main/othervm/timeout=700 MemLeakTest.) The failure makes it look like the leak is still there. I see two possibilities: 1) There is another leak that shows itself on those two systems. 2) This 64Mb increase in memory usage is benign. Thus, the test isn't reliable and should be removed, which is sad. Could you please give me details about the system running on those two machines. I'll try to reproduce the failure.
2013-08-19

Sure! Didn't it failed due to timeout? I increased the timeout to 700 second, but on a busy/slow machine it may be not enough..
2013-08-16

It is possible that the test is a little fragile on some systems. Charlie, can you please include details of the failure? Ivan, can you look into this?
2013-08-16

The fix is still at the review stage for jdk8, so I assume it's too late already to try to include it into 7u40. The customer only dropped a message asking whether we're going to include this fix or not. The leak isn't that significant and as you mentioned it's not a regression, so I think it's good as it is now.
2013-08-08

Thanks, Sean. Some customer asked at the open list for this to be included into 7u40, so I hoped it's not too late.
2013-08-08

Ivan - No need for critical request to 7u40 here. 7u40 is ready to ship (almost) - I'm going to remove the labels. You should target this for 7u60 (push to jdk7u-dev.. the always open forest)
2013-08-08

I've checked sources and the allocation is there in 6, 7 and 8. That's the code that most likely caused the leak: ---------------- name_utf = (*env)->GetStringUTFChars(env, name, &isCopy); if ((sock = openSocketWithFallback(env, name_utf)) < 0) { (*env)->ReleaseStringUTFChars(env, name, name_utf); return -1; } name_utf = (*env)->GetStringUTFChars(env, name, &isCopy); // <---- second allocation of the string -----------
2013-08-08

The leak is probably caused by unnecessary allocation in the getFlags0() function in the native code.
2013-08-08

Bug report was against JDK 7 GA, need to check if this issue is still applicable to 8.
2013-08-08