If the mapping descriptor is longer than 128 chars, the last parsed
character won't be a newline even if the current buffer contains it a
bit further than that. The current code always interprets it as a short
fgets() read instead, and thus keeps calling fgets() until it gets a
newline, dropping valid lines and failing with the following error:
pmap: ERROR: inconsistent detail field in smaps file, line:
Rss: 212 kB
pmap would previously print the process name if
/proc/PID/smaps could be opened, even if subsequent
reads failed. This actually occurs with other users
PIDs.
Kernel 3.18rc1 introduced a change where the file could
not been opened, meaning pmap -X 1 previously showed
the process name and nothing else but NOW shows nothing
make check failed because of this.
This change prints the process name even before trying to open
the file, returning it to previous behaviour.
Thanks to Vincent Bernat for some analysis.
References:
https://bugs.debian.org/775624https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=29a40ace841cba9b661711f042d1821cdc4ad47c
Signed-off-by: Craig Small <csmall@enc.com.au>
It's possible for the first entry that this reads from /proc/*/smaps to
start with a map_desc-less line like this:
7fa71b77d000-7fa71c288000 rw-p 00000000 00:00 0
in which case sscanf will only read up to inode, and it won't set c; the
code below would then incorrectly discard the next ("Size:") line.
(With GCC 4.9.0, this bug causes the "pmap extra extended output" test
to fail for me.)
Benno Schulenberg suggested some changes to the help messages
to provide some consistency and clarity for both the users and
translators of procps.
The test needed to be updated as the pmap output changed too.
Signed-off-by: Craig Small <csmall@enc.com.au>
To assist translators, the help lines are split so that each translation
chunk has one option. This gives bonus of if we add or change an option,
only that option remains untranslated rather than the entire help block.
Reference:
http://www.freelists.org/post/procps/procpsng-for-Translation-Project,1
Signed-off-by: Craig Small <csmall@enc.com.au>
When procps is built with gcc 4.8 address sanitizer
static int one_proc(proc_t * p)..
..
char smap_key[20];
...
(sscanf(mapbuf, "%20[^:]: %llu", smap_key..
rightfully results in an overflow and the program aborts.
pmap.c: In function 'one_proc':
pmap.c:529: warning: 'maxw1' may be used uninitialized in this function
pmap.c:529: warning: 'maxw2' may be used uninitialized in this function
pmap.c:529: warning: 'maxw3' may be used uninitialized in this function
pmap.c:529: warning: 'maxw4' may be used uninitialized in this function
pmap.c:529: warning: 'maxw5' may be used uninitialized in this function
Without -d and -x option, that should be doable to trigger the issue but I haven't found how
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
pmap.c: In function 'print_extended_maps':
pmap.c:310: warning: unused variable 'value'
pmap.c: In function 'config_read':
pmap.c:792: warning: unused variable 'section'
pmap.c: In function 'get_default_rc_filename':
pmap.c:969: warning: unused variable 'ret'
pmap.c: In function 'main':
pmap.c:999: warning: unused variable 'default_rc_filename'
Signed-off-by: Gilles Espinasse <g.esp@free.fr>
For portabiliy, check for program_invocation_name during configure and
define HAVE_PROGRAM_INVOCATION_NAME accordingly. Use of this symbol is
now enclosed with the appropriate #ifdef block.
The symbol program_invocation_name is only used for error message
handling using error(), so it's safe to omit this if it is not
available.
This commit fixes the width measurement of the extended pmap
function to work correctly with the -q switch. With no header
and no footer only widths of the particular values matter.
For some reason when the new -X/-XX options were added
what was always displayed as 'Mode' became 'Flags'. So
now a precious horizontal space is wasted because that
field's data has only 4 bytes whereas the header is 5.
Moreover, this created a conflict with the top program
which used that name in a column header already. Plus,
top emitted a 'Translation Hint' that suggests the max
chars should be 8 which is a limit pmap needn't share!
The xgettext program provides no way to keep identical
strings separate. This meant both top and pmap will be
sharing not only the msgid but a Translation Hint too.
So, the solution will now be two distinct field names.
Besides the kernel folks document it as 'perm' anyway!
Reference(s):
new options for pmap
commit faec340719
Signed-off-by: Jim Warner <james.warner@comcast.net>
The existing gettext nls support in pmap exposed users
to some potentially ugly misalignments should the text
that's used in headers someday actually be translated.
The length issue had been addressed already for -X/-XX
modes, but the column headers weren't nls translatable
as yet. This commit makes any header (not literally in
/proc/#/smaps) nls aware. It provides translated width
protection to all modes except one that's header-less!
As part of this effort, the occasional two spaces that
preceeded the Mapping column have been reduced to one.
Reference(s):
new usage & fix coding style
commit d50884788d
improve translations
commit 0022b6ec5d
add gettext support
commit d59cf08c9d
Signed-off-by: Jim Warner <james.warner@comcast.net>
When the new -X/-XX options were introduced, the width
and justification requirements were satisfied with a 2
step approach. First, format strings would dynamically
be built and then employed in the subsequent printf().
This was a total waste of time and resources since the
printf family of functions provide for the '*' width &
precision conventions to meet this need via arguments.
But even more importantly that foolish endeavor always
hides the potential warnings like the one shown below.
Henceforth this pmap will printf in the proper manner!
Reference(s):
new options for pmap
commit faec340719
pmap.c:459:4: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Wformat]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just adjusts miscellaneous indentation etc.
so we can begin the odious task of addressing the pmap
nls needs with at least a consistently formatted base.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Ever since pmap was refactored via the reference below
(and sprinkled with those damn tabs), the response for
the absence of any argument has been an error message.
This patch restores the proper behavior ('usage' text)
and updates the dejagnu 'no arguments' expect pattern.
Reference(s):
commit d50884788d
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit introduces 4 new switches for the RC support
and 1 more switch for toggling the path printing
in the mapping field. the configuration file can be used
for a selection of columns to be displayed and for toggling
the path printing in the mapping field.
This commit fixes allocation of the pid list so that it
is sufficient for storing the list terminator.
Additionally the vmflags printing in the -X mode is disabled
because it's too long. From now the vmflags are displayed
in the -XX mode only.
This commit changes the width measurement principle in the -X/-XX
modes so that a width of totals is measured instead of the width
of summands. The value of totals is always higher than the value
of summands. That additionally prevents the totals from having
a wrong indentation.
This commit also removes the minimum column width constraints
hardcoded to 7 characters.
This commit changes the processing principle of the -X/-XX modes
from 1-pass to 2-pass. A separate width measurement stage has been
added, so that the real maximum widths can be measured and used
for correct indentation.
The firstmapping variable now has a new value (2) used for the
width measurement stage (1st pass). The printing is disabled
in this stage. The file position is reset to the beginning
of the file once the end of file is reached and the printing stage
(2nd pass) begins.
It's questionable if this approach is sensitive to Read-after-Write
race conditions. Anyway, this feature is a good candidate for
a complete redesign in the future.
Additionally this commit introduces a final cleaning of the list
used for the evaluation of totals in the -X/-XX modes.
Previously the pidlist variable was defined as unsigned long *
whilst the openproc function accepts pid_t *.
Both target types differ in size (8 != 4) and therefore the issue
mainly affects big endian architectures.
This commit changes the pidlist type to pid_t * so that it's
compatible with openproc.
Some new kernel version added a line in /proc/pid/smaps listing a processes vmflags. This broke pmap such that pmap -X and pmap -XX would always fail.
This patch adds support for the vmflags field so that -X and -XX work again AND they display the flags.
Merge commit 'refs/merge-requests/8' of git://gitorious.org/procps/procps into merge-requests/8
This is largely Andrey's patch based upon merge request #7
If KLONG != 8 the summary didn't print for RRS and Dirty, this commit
restores this behavour for both sizes.
Ref: https://gitorious.org/procps/procps/merge_requests/7
Signed-off-by: Craig Small <csmall@enc.com.au>
While permissions suggests that /proc/#/smaps contents
are world-readable, in practice this file might not be
available to a non-root process. Whether this is a bug
in the kernel or an intentional design decision really
makes no difference. This commit will protect pmap -X.
(everything is perfectly justified plus right margins)
(are completely filled, but of course it must be luck)
Reference(s):
commit faec340719
Author: Dimitrios Apostolou <jimis@gmx.net>
Date: Thu Sep 27 22:08:04 2012 +1000
Signed-off-by: Jim Warner <james.warner@comcast.net>
pmap.c:80:7: warning: declaration of 'mapbuf' shadows a global declaration [-Wshadow]
pmap.c:63:13: warning: shadowed declaration is here [-Wshadow]
pmap.c:137:37: warning: declaration of 'mapbuf' shadows a global declaration [-Wshadow]
pmap.c:63:13: warning: shadowed declaration is here [-Wshadow]
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Fixes error which did not happen always. Changes of being affected by
the bug where greater the more there where pids defined as pmap argument.
The debian bug referral can almost certainly reproduce the problem,
especially when tried multiple times in row.
pmap: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
(((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >=
(unsigned long)((((__builtin_offsetof (struct malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) -
1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) ==
0)' failed.
Reported-by: lee <lee@yun.yagibdah.de>
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688180
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Both options provide more information about a process using -X and -XX
flags. The data comes from /proc/PID/smaps so it may vary.
Signed-off-by: Craig Small <csmall@enc.com.au>
If stream status is not checked at the end of execution below problem
would not report error, or non-zero exit code. The uptime is just an
example same was true with all commands of the project.
$ uptime >&- ; echo $?
uptime: write error: Bad file descriptor
1
$ uptime >/dev/full ; echo $?
uptime: write error: No space left on device
1
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Fix to an edge case. When user defined begining of address range to
be at between two allocations the previous allocation which ended to
that address was included to printout. After this commit one will
see only allocations that are within range definition.
$ pmap -A00007f4e0df08000,00007f4e0df08000 895
895: bash
00007f4e0dd08000 2048K ----- /lib/libreadline.so.6.2
00007f4e0df08000 8K r---- /lib/libreadline.so.6.2
total 2056K
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
pmap.c: In function 'discover_shm_minor':
pmap.c:87:10: warning: ISO C does not support the '%Lx' gnu_scanf format [-Wformat]
pmap.c:87:10: warning: ISO C does not support the '%Lu' gnu_scanf format [-Wformat]
pmap.c: In function 'mapping_name':
pmap.c:128:3: warning: ISO C does not support the '%Lx' gnu_printf format [-Wformat]
pmap.c:128:3: warning: ISO C does not support the '%Lx' gnu_printf format [-Wformat]
pmap.c: In function 'one_proc':
pmap.c:265:10: warning: ISO C does not support the '%Lx' gnu_scanf format [-Wformat]
pmap.c:265:10: warning: ISO C does not support the '%Lu' gnu_scanf format [-Wformat]
pmap.c:315:11: warning: ISO C does not support the '%Lx' gnu_printf format [-Wformat]
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
pmap.c:436 main(59) error: we previously assumed 'arg1' could be null (see line 427)
pmap.c:136:3: warning: return discards 'const' qualifier from pointer target type [enabled by default]
pmap.c:142:4: warning: return discards 'const' qualifier from pointer target type [enabled by default]
pmap.c:150:2: warning: return discards 'const' qualifier from pointer target type [enabled by default]
pmap.c:300:8: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
pmap.c:300:8: warning: assignment discards 'const' qualifier
from pointer target type [enabled by default]
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
err and warn are BSD format but they are not recommended by library
developers. However their consiseness is useful!
The solution is to use some macros that create xerr etc which then
just map to the error() function. The next problem is error() uses
program_invocation_name so we set this to program_invovation_short_name
This is a global set but seems to be the convention (or at least errors
are on the short name only) used everywhere else.
The Kbytes column when using the pmap -x flag would always be zero. This
was because the diff variable was reset before it could be printed.
pmap with no -x was not impacted by this bug or fix.
Add the following three functions to most of the commands.
setlocale (LC_ALL, "");
bindtextdomain(PACKAGE, LOCALEDIR);
textdomain(PACKAGE);
Reference: http://www.freelists.org/post/procps/backporting,1
Reported-by: Jim Warner <james.warner@comcast.net>
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
