Re: POWER: Unexpected fault when writing to brk-allocated memory
From: Florian Weimer
Date: Tue Nov 07 2017 - 08:05:52 EST
On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote:
On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote:
On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote:
First of all, using addr and MAP_FIXED to develop our heuristic can
never really give unchanged ABI. It's an in-band signal. brk() is a
good example that steadily keeps incrementing address, so depending
on malloc usage and address space randomization, you will get a brk()
that ends exactly at 128T, then the next one will be >
DEFAULT_MAP_WINDOW, and it will switch you to 56 bit address space.
No, it won't. You will hit stack first.
That's not actually true on POWER in some cases. See the process maps I
posted here:
<https://marc.info/?l=linuxppc-embedded&m=150988538106263&w=2>
Hm? I see that in all three cases the [stack] is the last mapping.
Do I miss something?
Hah, I had not noticed. Occasionally, the order of heap and stack is
reversed. This happens in approximately 15% of the runs.
See the attached example.
Thanks,
Florian
7fffacc50000-7fffacc90000 rw-p 00000000 00:00 0
7fffacc90000-7fffaccf0000 r--p 00000000 fd:00 25167925 /usr/lib/locale/en_US.utf8/LC_CTYPE
7fffaccf0000-7fffacd00000 r--p 00000000 fd:00 25167928 /usr/lib/locale/en_US.utf8/LC_NUMERIC
7fffacd00000-7fffacd10000 r--p 00000000 fd:00 16798929 /usr/lib/locale/en_US.utf8/LC_TIME
7fffacd10000-7ffface40000 r--p 00000000 fd:00 25167924 /usr/lib/locale/en_US.utf8/LC_COLLATE
7ffface40000-7ffface50000 r--p 00000000 fd:00 16798927 /usr/lib/locale/en_US.utf8/LC_MONETARY
7ffface50000-7ffface60000 r--p 00000000 fd:00 2511 /usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES
7ffface60000-7ffface70000 r--p 00000000 fd:00 16798942 /usr/lib/locale/en_US.utf8/LC_PAPER
7ffface70000-7ffface80000 r--p 00000000 fd:00 25167927 /usr/lib/locale/en_US.utf8/LC_NAME
7ffface80000-7ffface90000 r--p 00000000 fd:00 16798924 /usr/lib/locale/en_US.utf8/LC_ADDRESS
7ffface90000-7fffacea0000 r--p 00000000 fd:00 16798928 /usr/lib/locale/en_US.utf8/LC_TELEPHONE
7fffacea0000-7fffaceb0000 r--p 00000000 fd:00 16798926 /usr/lib/locale/en_US.utf8/LC_MEASUREMENT
7fffaceb0000-7fffacec0000 r--s 00000000 fd:00 8390657 /usr/lib64/gconv/gconv-modules.cache
7fffacec0000-7fffad0d0000 r-xp 00000000 fd:00 8390335 /usr/lib64/libc-2.25.so
7fffad0d0000-7fffad0e0000 ---p 00210000 fd:00 8390335 /usr/lib64/libc-2.25.so
7fffad0e0000-7fffad0f0000 r--p 00210000 fd:00 8390335 /usr/lib64/libc-2.25.so
7fffad0f0000-7fffad100000 rw-p 00220000 fd:00 8390335 /usr/lib64/libc-2.25.so
7fffad100000-7fffad110000 r--p 00000000 fd:00 16798925 /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
7fffad110000-7fffad120000 r-xp 00000000 fd:00 63543 /usr/bin/cat
7fffad120000-7fffad130000 r--p 00000000 fd:00 63543 /usr/bin/cat
7fffad130000-7fffad140000 rw-p 00010000 fd:00 63543 /usr/bin/cat
7fffad140000-7fffad160000 r-xp 00000000 00:00 0 [vdso]
7fffad160000-7fffad1a0000 r-xp 00000000 fd:00 8390328 /usr/lib64/ld-2.25.so
7fffad1a0000-7fffad1b0000 r--p 00030000 fd:00 8390328 /usr/lib64/ld-2.25.so
7fffad1b0000-7fffad1c0000 rw-p 00040000 fd:00 8390328 /usr/lib64/ld-2.25.so
7fffc2cf0000-7fffc2d20000 rw-p 00000000 00:00 0 [stack]
7fffc8c10000-7fffc8c40000 rw-p 00000000 00:00 0 [heap]