=?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

Reply via email to