Quantcast

RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses

Mark Sheppard
Hi,
    please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8175325/webrev/

for the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8175325

the scenario is that a MulticastSocket, bound to a wildcard address,
which has yet to have its NetworkInterface
set, will return a synthesized NetworkInterface for a
getNetworkInterface method call. The newly constructed
has no InterfaceAddress bindings instantiated, resulting in a NPE when
getInterfaceAddresses is invoked.
The fix initializes the bindings member variable with an empty array, as
per suggestion in the bug, and also,
for completeness, places a null check in the getInterfaceAddresses method.

There is a side issue here, relating to the synthesis of a
NetworkInterface for a MulticastSocket
bound to a wildcard address. This is somewhat dubious semantics, and
would seem to be worthy of review
at some stage in the future.

regards
Mark
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses

Martin Buchholz-3
It would not have both the never-null property and the check for null.

I would probably just leave bindings null in the constructor and check for null whenever reading bindings.

On Mon, Mar 6, 2017 at 2:00 PM, Mark Sheppard <[hidden email]> wrote:
Hi,
   please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8175325/webrev/

for the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8175325

the scenario is that a MulticastSocket, bound to a wildcard address, which has yet to have its NetworkInterface
set, will return a synthesized NetworkInterface for a getNetworkInterface method call. The newly constructed
has no InterfaceAddress bindings instantiated, resulting in a NPE when getInterfaceAddresses is invoked.
The fix initializes the bindings member variable with an empty array, as per suggestion in the bug, and also,
for completeness, places a null check in the getInterfaceAddresses method.

There is a side issue here, relating to the synthesis of a NetworkInterface for a MulticastSocket
bound to a wildcard address. This is somewhat dubious semantics, and would seem to be worthy of review
at some stage in the future.

regards
Mark

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses

Mark Sheppard
tha's true from the Java side. I didn't exhaustively check if is possible that the bindings could
be returned uninitialized or null from native code - I don't think it is possible, but I added the
null check, just in case.

regards
Mark

On 06/03/2017 22:16, Martin Buchholz wrote:
It would not have both the never-null property and the check for null.

I would probably just leave bindings null in the constructor and check for null whenever reading bindings.

On Mon, Mar 6, 2017 at 2:00 PM, Mark Sheppard <[hidden email]> wrote:
Hi,
   please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8175325/webrev/

for the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8175325

the scenario is that a MulticastSocket, bound to a wildcard address, which has yet to have its NetworkInterface
set, will return a synthesized NetworkInterface for a getNetworkInterface method call. The newly constructed
has no InterfaceAddress bindings instantiated, resulting in a NPE when getInterfaceAddresses is invoked.
The fix initializes the bindings member variable with an empty array, as per suggestion in the bug, and also,
for completeness, places a null check in the getInterfaceAddresses method.

There is a side issue here, relating to the synthesis of a NetworkInterface for a MulticastSocket
bound to a wildcard address. This is somewhat dubious semantics, and would seem to be worthy of review
at some stage in the future.

regards
Mark


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses

Chris Hegarty
Mark,

> On 6 Mar 2017, at 23:21, Mark Sheppard <[hidden email]> wrote:
>
> tha's true from the Java side. I didn't exhaustively check if is possible that the bindings could
> be returned uninitialized or null from native code - I don't think it is possible, but I added the
> null check, just in case.

I agree with Martin’s comment. The null check should be sufficient.


>> There is a side issue here, relating to the synthesis of a NetworkInterface for a MulticastSocket
>> bound to a wildcard address. This is somewhat dubious semantics, and would seem to be worthy of review
>> at some stage in the future.

Yes, this should be looked at in some more detail in the future.

-Chris.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR: JDK-8175325 - NetworkInterface.getInterfaceAddresses throws NPE when no addresses

Mark Sheppard
Chris, Martin,
    thanks for the feedback .... I'll remove the initialization from the
constructor

regards
Mark

On 07/03/2017 15:17, Chris Hegarty wrote:

> Mark,
>
>> On 6 Mar 2017, at 23:21, Mark Sheppard <[hidden email]> wrote:
>>
>> tha's true from the Java side. I didn't exhaustively check if is possible that the bindings could
>> be returned uninitialized or null from native code - I don't think it is possible, but I added the
>> null check, just in case.
> I agree with Martin’s comment. The null check should be sufficient.
> …
>
>>> There is a side issue here, relating to the synthesis of a NetworkInterface for a MulticastSocket
>>> bound to a wildcard address. This is somewhat dubious semantics, and would seem to be worthy of review
>>> at some stage in the future.
> Yes, this should be looked at in some more detail in the future.
>
> -Chris.

Loading...