=?iso-8859-1?Q?J=F6rg?= Sommer writes: > > Package: coreutils > Version: 8.5-1 > Severity: normal > > Hi, > > I wanted to extract the vdso segment, but dd can't work in > /proc/self/mem.
The kernel restricts use of /proc/PID/mem to the process that is currently ptrace'ing (debugging) PID. dd can't do anything about that. > 2406 01:07:20.962414 _llseek(0, 1048576, [1048576], SEEK_CUR) = 0 <0.000024> > 2406 01:07:20.962581 fstat64(0, {st_dev=makedev(0, 3), st_ino=6138359, > st_mode=S_IFREG|0600, st_nlink=1, st_uid=1000, st_gid=100, st_blksize=1024, > st_blocks=0, st_size=0, st_atime=2011/06/19-01:01:32, > st_mtime=2011/06/19-01:01:32, st_ctime=2011/06/19-01:01:32}) = 0 <0.000028> The reason why dd is unhappy here is that mem, like a lot of other /proc files, advertises itself as a regular file (S_IFREG) but has st_size=0. It thinks it has seeked past EOF so it warns you that the amount you asked to skip was greater than the size of the file. > 2406 01:07:20.963085 write(2, "dd: ", 4) = 4 <0.000827> > 2406 01:07:20.964239 write(2, "`/proc/25302/mem': cannot skip t"..., 50) = > 50 <0.000718> > 2406 01:07:20.965186 write(2, "\n", 1) = 1 <0.002266> > 2406 01:07:20.967699 read(0, 0x1062e000, 4096) = -1 EPERM (Operation not > permitted) <0.000043> This one is the ptrace restriction, which applies to reads and writes but not seeks. > > I don't know, why dd thinks something went wrong. llseek() and fstat64() > didn't return an error. Accessing the file with Ruby yields the expected > result. I don't speak ruby, but that sounds unlikely. Would it do a ptrace behind your back? Or did you maybe think it succeeded when actually it just didn't report the errors it encountered? You should strace that too. -- Alan Curry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org