United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8022584 : Memory leak in NetworkInterface methods ex. isUP(), isLoopback()

Details
Type:
Bug
Submit Date:
2013-06-03
Status:
Closed
Updated Date:
2014-01-07
Project Name:
JDK
Resolved Date:
2013-08-15
Component:
core-libs
OS:
linux
Sub-Component:
java.net
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u51,7,8
Fixed Versions:

Related Reports
Backport:
Backport:
Duplicate:
Duplicate:

Sub Tasks

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
URL:   http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/7d7d553a8c61
User:  lana
Date:  2013-08-26 18:32:19 +0000

                                     
2013-08-26
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
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
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
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d7d553a8c61
User:  chegar
Date:  2013-08-15 13:53:02 +0000

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



Hardware and Software, Engineered to Work Together