Re: /proc/*/smaps

From: Torsten Foertsch (torsten.foertsch_at_gmx.net)
Date: 11/01/05

  • Next message: Tejun Heo: "[PATCH] blk: fix dangling pointer access in __elv_add_request"
    To: linux-kernel@vger.kernel.org
    Date:	Tue, 1 Nov 2005 09:24:56 +0100
    
    

    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@vger.kernel.org
    > 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Tejun Heo: "[PATCH] blk: fix dangling pointer access in __elv_add_request"

    Relevant Pages

    • /proc/*/smaps
      ... Imagine that some ... major rework of the file format. ... 080dc000-080e2000 rw-p /bin/bash ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: MySQL Performance 6.0rc1
      ... One can, however, imagine a few possibilities: ... Ignore forward compatibility, but add a heuristic to identify old file ... the new file format could begin with a struct ... On the other hand, the existing header ...
      (freebsd-current)
    • Re: Which codec is required?
      ... had that much I could parse apart the file..... ... Since each file format is created by a different ... Depending on the type of media, you will probably have to find or write ... (I don't want them to download codec - I just want to use the codecs I ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: PCI Express support for 2.4 kernel
      ... t.o: file format elf32-i386 ... > zero causes space to be consumed in the resulting object file (not ... This is wasted space, because if ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] A new entry for /proc
      ... > The most important thing about a /proc file format is that it has ... > documentation, it is impossible to write a reliable parser. ... know any public kernel (I mean kernel version for tracking and ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)