FULL PRODUCT VERSION :
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows i586 - all versions

A DESCRIPTION OF THE PROBLEM :
The JRE methods NetworkInterface.isUp(), isLoopback(), and others are implemented as native methods in NetworkInterface.c that internally call the C method getFlags0().  getFlags0() contains a small memory leak:

static int getFlags0(JNIEnv *env, jstring name) {
    jboolean isCopy;
    int ret, sock;
    const char* name_utf;

    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);

    ret = getFlags(env, sock, name_utf);

    close(sock);
    (*env)->ReleaseStringUTFChars(env, name, name_utf);

    if (ret < 0) {
        NET_ThrowByNameWithLastError(env, JNU_JAVANETPKG "SocketException", "IOCTL  SIOCGLIFFLAGS failed");
        return -1;
    }

    return ret;
}

As you can see, in the normal case GetStringUTFChars() is called twice.  The return value of the first call is never released.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Call NetworkInterface.isUp() repeatedly and watch the OS process size grow.  Run on 32-bit Windows with 1GB java heap size.  When the address space is eventually exhausted the app throws an out-of-swap-space exception.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Calling NetworkInterface.isUp() repeatedly should not continually grow the process size.
ACTUAL -
Calling NetworkInterface.isUp() repeatedly continually increases the process size.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Eventually, an OutOfMemoryException with the message "could not allocate memory - out of swap space?".

REPRODUCIBILITY :
This bug can be reproduced always.