There are some virtual memory segments will not be dumped when "dump_fat_core" is true

[sehdshskj]

Hello, when i allocate a virtual memory space using mmap( ) only with PORT_WRITE, whose size is 8000000 in bytes . The information about this segment in program header as following text shows, whose flag is 'W'.
LOAD 0x0000000000330000 0x000000114a050000 0x0000000000000000
0x0000000000000000 0x0000000002000000 RW 0x10000
LOAD 0x0000000000330000 0x000000114c050000 0x0000000000000000
0x0000000000000000 0x0000000000010000 RW 0x10000
LOAD 0x0000000000330000 0x0000ffffa46e0000 0x0000000000000000
0x0000000008000000 0x0000000008000000 W 0x10000
LOAD 0x0000000008330000 0x0000ffffac6e0000 0x0000000000000000
0x0000000000000000 0x0000000000010000 0x10000
LOAD 0x0000000008330000 0x0000ffffac6f0000 0x0000000000000000
0x0000000000800000 0x0000000000800000 RW 0x10000

But mincoredumper save vma's information with a PF_R flag, so this segment will not be dumped when "dump_fat_core" is true.
start: 0xffffad710000 end: 0xffffadf10000 len: 0x800000 core offset: 0x9330000
start: 0xffffacf00000 end: 0xffffad700000 len: 0x800000 core offset: 0x8b30000
start: 0xffffac6f0000 end: 0xffffacef0000 len: 0x800000 core offset: 0x8330000
start: 0x114c050000 end: 0x114c050000 len: 0x0 core offset: 0x330000
start: 0x114a050000 end: 0x114a050000 len: 0x0 core offset: 0x330000

I propose the following changes:
type.p_flags = PF_R ;
if ((phdr->p_flags & type->p_flags) != type->p_flags)

to
type.p_flags = PF_R | PF_W ;
if ((phdr->p_flags & type->p_flags) == 0)

[jogness]

Are you using the latest release version of minicoredumper (2.0.4)? For me write-only mmaps are getting dumped in the fatcore.

[sehdshskj]

The version of minicoredumper I am using is 2.0.2。 I use mmap(NULL, 8000000, PORT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0) allocate a virtual memory space on an aarch64 machine。And this anonymous region will not be dumped.

[jogness]

In 2.0.3 there were important fixes relating to correctly dumping area. Please try with the latest bugfix release: 2.0.4.

[sehdshskj]

Hello, when i try with the latest bugfix release: 2.0.4, i find that the problem be still existing。The following texts come from the result of 'readelf -l fatcore'.
LOAD 0x0000000000360000 0x000000114c050000 0x0000000000000000
0x0000000000000000 0x0000000000010000 RW 0x10000
LOAD 0x0000000000360000 0x0000ffff85ad0000 0x0000000000000000
0x0000000000000000 0x0000000008000000 W 0x10000
LOAD 0x0000000000360000 0x0000ffff8dad0000 0x0000000000000000
0x0000000000000000 0x0000000000010000 0x10000
LOAD 0x0000000000360000 0x0000ffff8dae0000 0x0000000000000000
0x0000000000800000 0x0000000000800000 RW 0x10000
LOAD 0x0000000000b60000 0x0000ffff8e2e0000 0x0000000000000000
0x0000000000000000 0x0000000000010000 0x10000

• The virtual memory segments allocated by mmap(NULL, 0x8000000, PORT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0) only has the flag 'w'. But the vma info in debug.txt don't record it. And the core offset seems to be incorrect.

start: 0xffff8fb20000 end: 0xffff90320000 len: 0x800000 core offset: 0x2360000
start: 0xffff8f310000 end: 0xffff8fb10000 len: 0x800000 core offset: 0x1b60000
start: 0xffff8eb00000 end: 0xffff8f300000 len: 0x800000 core offset: 0x1360000
start: 0xffff8e2f0000 end: 0xffff8eaf0000 len: 0x800000 core offset: 0xb60000
start: 0xffff8dae0000 end: 0xffff8e2e0000 len: 0x800000 core offset: 0x360000
start: 0x114c050000 end: 0x114c050000 len: 0x0 core offset: 0x360000

[jogness]

Thank you for pointing out and suggesting the correct fix for this issue. I have released version 2.0.5 with your suggested changes.