ProcessModule addresses on Linux

[am11]

On Linux, we sum up the contiguous address range deltas when names of the consecutive modules match. This is a sound way of implementing a reliable ModuleMemorySize API.

However, we have a pre-condition on raw data for only collecting the rows that have both, executability and readability flags set. Consider the following live maps sample taken from system running Ubuntu 18.04:

55b3000d1000-55b30016e000 rw-p 00000000 00:00 0                          [heap]
7f05522d6000-7f05522e1000 r-xp 00000000 fe:01 2622733                    /lib/x86_64-linux-gnu/libnss_files-2.27.so
7f05522e1000-7f05524e0000 ---p 0000b000 fe:01 2622733                    /lib/x86_64-linux-gnu/libnss_files-2.27.so
7f05524e0000-7f05524e1000 r--p 0000a000 fe:01 2622733                    /lib/x86_64-linux-gnu/libnss_files-2.27.so
7f05524e1000-7f05524e2000 rw-p 0000b000 fe:01 2622733                    /lib/x86_64-linux-gnu/libnss_files-2.27.so
7f05524e2000-7f05524e8000 rw-p 00000000 00:00 0 
7f05524e8000-7f05524ff000 r-xp 00000000 fe:01 2622727                    /lib/x86_64-linux-gnu/libnsl-2.27.so
7f05524ff000-7f05526fe000 ---p 00017000 fe:01 2622727                    /lib/x86_64-linux-gnu/libnsl-2.27.so
7f05526fe000-7f05526ff000 r--p 00016000 fe:01 2622727                    /lib/x86_64-linux-gnu/libnsl-2.27.so
7f05526ff000-7f0552700000 rw-p 00017000 fe:01 2622727                    /lib/x86_64-linux-gnu/libnsl-2.27.so
7f0552700000-7f0552702000 rw-p 00000000 00:00 0 
7f0552702000-7f055270d000 r-xp 00000000 fe:01 2622737                    /lib/x86_64-linux-gnu/libnss_nis-2.27.so
7f055270d000-7f055290c000 ---p 0000b000 fe:01 2622737                    /lib/x86_64-linux-gnu/libnss_nis-2.27.so
7f055290c000-7f055290d000 r--p 0000a000 fe:01 2622737                    /lib/x86_64-linux-gnu/libnss_nis-2.27.so
7f055290d000-7f055290e000 rw-p 0000b000 fe:01 2622737                    /lib/x86_64-linux-gnu/libnss_nis-2.27.so
7f055290e000-7f0552916000 r-xp 00000000 fe:01 2622729                    /lib/x86_64-linux-gnu/libnss_compat-2.27.so
7f0552916000-7f0552b16000 ---p 00008000 fe:01 2622729                    /lib/x86_64-linux-gnu/libnss_compat-2.27.so
7f0552b16000-7f0552b17000 r--p 00008000 fe:01 2622729                    /lib/x86_64-linux-gnu/libnss_compat-2.27.so
7f0552b17000-7f0552b18000 rw-p 00009000 fe:01 2622729                    /lib/x86_64-linux-gnu/libnss_compat-2.27.so
7f0552b18000-7f0552cff000 r-xp 00000000 fe:01 2622691                    /lib/x86_64-linux-gnu/libc-2.27.so
7f0552cff000-7f0552eff000 ---p 001e7000 fe:01 2622691                    /lib/x86_64-linux-gnu/libc-2.27.so
7f0552eff000-7f0552f03000 r--p 001e7000 fe:01 2622691                    /lib/x86_64-linux-gnu/libc-2.27.so
7f0552f03000-7f0552f05000 rw-p 001eb000 fe:01 2622691                    /lib/x86_64-linux-gnu/libc-2.27.so

our per-condition and our summation logic do not agree with this dataset, it seems. The adjacent rows with contiguous ranges, belonging to the same named module, do not necessarily have both flags set.

Is this by design?

cc @stephentoub

I noticed this while working on illumos implementation of process modules (trying to share some code with Linux), where the corresponding summation code was never being executed; because of the holes in record from pre-condition / permission flag filter:
if ((itr->pr_mflags & MA_READ) && (itr->pr_mflags & MA_EXEC)) ...capture this row ...

(even if it is not by design, I think it not mission-critical; this property only represents a statistical piece of information. I am just double checking and can offer a fix in case)

Thanks.

[stephentoub]

Is this by design?

Seems like it could be improved further :)

[am11]

Fixed by #45401.