Re: /proc/*/smaps

From: Torsten Foertsch
Date: Tue Nov 01 2005 - 03:25:56 EST


On Tuesday 01 November 2005 06:13, Albert Cahalan wrote:
> Take a look at those files, trying not to crack up laughing
> at the file format. Maybe you will cry. Imagine that some
> apps try to parse those... all of them, repeatedly, while
> being tolerant of unspecified future changes.

The Perl module Linux::Smaps already parses it.

r2@s93:~> cp /bin/bash 'b
a
:s:h'
r2@s93:~> ./'b
> a
> :s:h'
s93:~$ more /proc/$$/smaps
08048000-080ba000 r-xp 00000000 08:02 152476 /home/r2/b\012a\012:s:h
Size: 456 kB
Rss: 368 kB
Shared_Clean: 368 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
080ba000-080bd000 rwxp 00072000 08:02 152476 /home/r2/b\012a\012:s:h
Size: 12 kB
Rss: 12 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 12 kB
080bd000-08126000 rwxp 080bd000 00:00 0 [heap]
Size: 420 kB
Rss: 312 kB
...

s93:~$ perl -MLinux::Smaps -e 'foreach (Linux::Smaps->new('$$')->names) {print
"$_\n"}'
...
/lib/libdl.so.2
/home/r2/b\012a\012:s:h
/usr/lib/locale/en_US.utf8/LC_NUMERIC

Where is your problem? You see, the vma names are properly parsed.

Here is my parser:
if( $l=~/([\da-f]+)-([\da-f]+)\s # range
([r\-])([w\-])([x\-])([sp])\s # access mode
([\da-f]+)\s # page offset in file
([\da-f]+):([\da-f]+)\s # device
(\d+)\s* # inode
(.*) # file name
/xi ) {
push @{$I->_elem}, $current=Linux::Smaps::VMA->new;
$current->vma_start=hex $1;
$current->vma_end=hex $2;
$current->r=($3 eq 'r');
$current->w=($4 eq 'w');
$current->x=($5 eq 'x');
$current->mayshare=($6 eq 's');
$current->file_off=hex $7;
$current->dev_major=hex $8;
$current->dev_minor=hex $9;
$current->inode=$10;
$current->file_name=$11;
} elsif( $l=~/^(\w+):\s*(\d+) kB$/ ) {
my $m=lc $1;
$current->$m=$2;
} else {
die __PACKAGE__.":: not parsed: $l\n";
}

Torsten

> (remember that a filename may have a colon, new fields
> may be added, new lines may differ in unknown ways, etc.)
>
> Could we fix this ASAP? How about just commenting it
> out right now, so nothing important starts to rely on it.
> CONFIG_EXPERIMENTAL would do I guess.
>
> I'll gladly do something sane, but not tonight. I'm sorry I
> did not catch this earlier; I've been rather sick and I never
> imagined that this thing would get accepted without a
> major rework of the file format.
>
> -------- unbelievable example follows --------
>
> 08048000-080dc000 r-xp /bin/bash
> Size: 592 KB
> Rss: 500 KB
> Shared_Clean: 500 KB
> Shared_Dirty: 0 KB
> Private_Clean: 0 KB
> Private_Dirty: 0 KB
> 080dc000-080e2000 rw-p /bin/bash
> Size: 24 KB
> Rss: 24 KB
> Shared_Clean: 0 KB
> Shared_Dirty: 0 KB
> Private_Clean: 0 KB
> Private_Dirty: 24 KB
> 080e2000-08116000 rw-p
> Size: 208 KB
> Rss: 208 KB
> Shared_Clean: 0 KB
> Shared_Dirty: 0 KB
> Private_Clean: 0 KB
> Private_Dirty: 208 KB
> b7e2b000-b7e34000 r-xp /lib/tls/libnss_files-2.3.2.so
> Size: 36 KB
> Rss: 12 KB
> Shared_Clean: 12 KB
> Shared_Dirty: 0 KB
> Private_Clean: 0 KB
> Private_Dirty: 0 KB
> ...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/