pfiles shows incorrect socket information on some getsockname calls
From the Joyent bug report:
In development we have a case where getsockname() returns a sock of length zero for a UDS. However, pfiles just drives on and assumes it is a filled in sockname. Because this is a buffer on the stack, it's highly likely that we get the same information as we do for the previous socket we looked at and thus it will print the wrong information entirely. eg.
10: S_IFSOCK mode:0666 dev:540,0 ino:50810 uid:0 gid:0 rdev:0,0 O_RDWR|O_NONBLOCK FD_CLOEXEC SOCK_STREAM SO_REUSEADDR,SO_SNDBUF(49152),SO_RCVBUF(128000) sockname: AF_INET 0.0.0.0 port: 8080 12: S_IFSOCK mode:0666 dev:540,0 ino:24213 uid:0 gid:0 rdev:0,0 O_RDWR|O_NONBLOCK FD_CLOEXEC SOCK_STREAM SO_SNDBUF(16384),SO_RCVBUF(5120) sockname: AF_INET 0.0.0.0 port: 8080 peer: pid 9275 zone: eee94dec-5abc-4430-913b-9524f902a438
If you correlate this with mdb:
10 SOCK ffffff438e057800 socket: AF_INET 0.0.0.0 8080 12 SOCK ffffff4341309040
pfiles calls getsockname on most socket endpoints. While it checks the return value, it does not check the size result to getsockname. In this case, it always assumes that if getsockname returns zero, it has valid data. This will cause it to find the results of the previous socket if we're lucky or garbage data if we're rather unlucky. The solution here is that when we find the socket has a size of zero from getsockname, we do not print any of the sockname or peer information.