Bug #3683
pfiles shouldn't try to trace itself
Start date:
2013-04-03
Due date:
% Done:
100%
Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
Description
From the Joyent bug report:
[root@headnode (bh1-kvm11:0) ~]# bash -c 'pfiles $$' Segmentation Fault (core dumped)
In the bash -c case, we ended up actually running pfiles on ourselves. bash evaluated $$ to bash's pid, but then bash upon realizing it's the last command, simply calls exit. We really can't grab ourselves via libproc, and libproc sets the error to G_SELF. pfiles mistakingly thinks it has an implementation where it can have a NULL handle, this is just wrong. Instead we should just print an error and move on to the next pid. Here we'll leverage the libproc error message in a similar fashion to truss. The new result is:
rm-build ptools # bash -c './pfiles/amd64/pfiles $$' pfiles: attempt to grab self: 27796 rm-build ptools # bash -c './pfiles/amd64/pfiles $$ 6690' pfiles: attempt to grab self: 27797 6690: -bash Current rlimit: 65536 file descriptors 0: S_IFCHR mode:0620 dev:533,2 ino:2836074535 uid:0 gid:7 rdev:6,5 O_RDWR|O_NOCTTY|O_LARGEFILE /dev/pts/5 offset:246884 1: S_IFCHR mode:0620 dev:533,2 ino:2836074535 uid:0 gid:7 rdev:6,5 O_RDWR|O_NOCTTY|O_LARGEFILE /dev/pts/5 offset:246884 2: S_IFCHR mode:0620 dev:533,2 ino:2836074535 uid:0 gid:7 rdev:6,5 O_RDWR|O_NOCTTY|O_LARGEFILE /dev/pts/5 offset:246884 3: S_IFDOOR mode:0444 dev:542,0 ino:161 uid:0 gid:0 rdev:541,0 O_RDONLY|O_LARGEFILE FD_CLOEXEC door to nscd[14617] /var/run/name_service_door 255: S_IFCHR mode:0620 dev:533,2 ino:2836074535 uid:0 gid:7 rdev:6,5 O_RDWR|O_NOCTTY|O_LARGEFILE FD_CLOEXEC
Updated by Robert Mustacchi about 8 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
- Tags deleted (
needs-triage)
Resolved in dfc0fed81813380fb526f1a003d3be17ab26ce3b.