Project

General

Profile

Bug #3683

pfiles shouldn't try to trace itself

Added by Robert Mustacchi over 7 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Category:
cmd - userland programs
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
#1

Updated by Robert Mustacchi over 7 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100
  • Tags deleted (needs-triage)

Resolved in dfc0fed81813380fb526f1a003d3be17ab26ce3b.

Also available in: Atom PDF