With this patch we've completed a progression toward a
standard approach to naming conventions which follows:
* Only functions will begin with that 'procps_' prefix
. ........................................... examples
. procps_vmstat_get ()
. procps_diskstats_select ()
- ----------------------------------------------------
* Exposed structures begin with the module/header name
. ........................................... examples
. struct pids_info
. struct stat_reaped
- ----------------------------------------------------
* Item enumerators begin like structs, but capitalized
. ........................................... examples
. VMSTAT_COMPACT_FAIL
. MEMINFO_DELTA_ACTIVE
[ slabinfo varies slightly due to some item variants ]
. SLABINFO_extra
. SLABS_SIZE_ACTIVE
. SLABNODE_OBJS_PER_SLAB
[ could cure with a prefix of SLABINFO, but too long ]
- ----------------------------------------------------
* Other enumerators work exactly like item enumerators
. ........................................... examples
. PIDS_SORT_ASCEND
. STAT_REAP_CPUS_AND_NODES
- ----------------------------------------------------
* Macros and constants begin just like the enumerators
. ........................................... examples
. #define SLABINFO_GET
. #define DISKSTATS_TYPE_DISK
- ----------------------------------------------------
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the change to struct pids_fetch, we'll just trade
some dot ('.') code for some pointer to ('->') syntax.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The patch referenced below silenced an 'uninitialized'
compiler warning but it also created a bug where zeros
appeared under the Address column with that -x option.
So this commit swats that bug and avoids any warnings.
[ while yours truly created that bug, in his defense ]
[ let's at least acknowledge the god awful loop code ]
[ which was the root of the problem & wrong solution ]
[ so the ugliness of this most recent solution is in ]
[ perfect harmony with the *really* ugly loop itself ]
Reference(s):
commit 0299bd15b0
Signed-off-by: Jim Warner <james.warner@comcast.net>
I've got nothing to add to the commit message but that
doesn't mean I won't produce perfectly justified text.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The segment may have been destroyed by the kernel automagically
after shmdt(addr)
How to reproduce:
sysctl -w kernel.shm_rmid_forced=1
./pmap 1
shared memory remove: Invalid argument
[..]
The includes used to define a lot of things a library include
should not. It was also a bit messy what was exposed in the library
and what was not.
get_pid_digits -> procps_pid_length and exported correctly
MALLOC attribute move into relevant .c files
NORETURN attribute moved to relevant .c, not used in library
PURE attribute removed, it wasn't used
KLONG/KLF/STRTOUKL were fixed for long, so now just use long
HIDDEN attribute removed. It was for 3 functions. The PROCPS_EXPORT
seems to do the same (opposite) thing.
likely/unlikely removed from most places, its highly debateable
this does anything useful as CPUs have gotten smarter about branches.
Re-arranged the includes, ALL external programs should just #include
<proc/procps.h> then proc/procps.h includes headers for files that
have exported functions. procps.h and the headers it includes should
not use items that are not exportable (e.g. hidden functions or
macros) they go in procps-private.h
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
This commit was prompted by that change from 'addr' to
'ul_int' in the <pids> interface. Along the way, KLONG
was removed as having long ago outlived its usefulness
as performance optimizations for weird configurations.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Reference(s):
pmap.c:618:20: warning: variable 'start' is uninitialized when used here [-Wuninitialized]
maxw1, start,
^~~~~
Signed-off-by: Jim Warner <james.warner@comcast.net>
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>
