JDK-8022584 : Memory leak in NetworkInterface methods ex. isUP(), isLoopback()
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6u51,7,8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2013-06-03
  • Updated: 2014-02-12
  • Resolved: 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 Availability 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=
07-01-2014

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.
19-08-2013

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.
19-08-2013

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..
16-08-2013

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?
16-08-2013

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.
08-08-2013

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

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)
08-08-2013

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 -----------
08-08-2013

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

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