Bug #3686
pfiles shows incorrect socket information on some getsockname calls
100%
Description
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[147]
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.
Updated by Robert Mustacchi about 8 years ago
- Status changed from New to Resolved
- % Done changed from 90 to 100
Resolved in dfc0fed81813380fb526f1a003d3be17ab26ce3b.