Tests pass on my system (linux x86_64).
Travis CI reports java.lang.NullPointerException where test calls Socket.getifaddrs, but no stacktrace for Java. Is there anything I can specify at the test level to get a complete stacktrace ?

[exec] test_getifaddrs: E
[exec] ===============================================================================
[exec] Error: test_getifaddrs(SocketTest)
[exec] : SocketError: getifaddrs: java.lang.NullPointerException
[exec] /home/travis/build/jruby/jruby/test/jruby/test_socket.rb:76:in `test_getifaddrs'
[exec] 73:
[exec] 74: def test_getifaddrs
[exec] 75: begin
[exec] => 76: list = Socket.getifaddrs
[exec] 77: rescue NotImplementedError
[exec] 78: return
[exec] 79: end
[exec] ===============================================================================

In the meantime, commit 7be572e adds Addrinfo and Ifaddr tests to jruby.index, maybe those test results will shed some light.

Nope, no luck there. Tests in Addrinfo and Ifaddr call Socket.getifaddrs to generate objects to test. It fails in the same way without a Java stacktrace.

All these tests pass locally for me under various combinations of network interface configurations. Is there any way to get at that trace to see what's different in Travis CI ?

@iqeo That NPE would be easy to investigate if we had access to travis. Thankfully, we can do that. If you email the Travis support email, they can set up an ssh-able instance for you for 24 hours. That should make it easy to reproduce.

Alternatively, you could set up a VM with the same releases of OS and JVM. Thanks for your help on this!

All set now. Access to the Travis VM was key to seeing .getHardwareAddress() returned null for their point-to-point interfaces. And a quirky difference with Ifaddr.ifindex between the VM and build job was failing a test in the build job.

Great homework on this one, thank you. I'll merge locally to confirm it and then push if it's good.