Nicholas Piggin <npiggin@xxxxxxxxx> writes: > On Fri, 3 Nov 2017 18:05:20 +0100 > Florian Weimer <fweimer@xxxxxxxxxx> wrote: > >> We are seeing an issue on ppc64le and ppc64 (and perhaps on some arm >> variant, but I have not seen it on our own builders) where running >> localedef as part of the glibc build crashes with a segmentation fault. >> >> Kernel version is 4.13.9 (Fedora 26 variant). >> >> I have only seen this with an explicit loader invocation, like this: >> >> while I18NPATH=. /lib64/ld64.so.1 /usr/bin/localedef >> --alias-file=../intl/locale.alias --no-archive -i locales/nl_AW -c -f >> charmaps/UTF-8 >> --prefix=/builddir/build/BUILDROOT/glibc-2.26-16.fc27.ppc64 nl_AW ; do : >> ; done >> >> To be run in the localedata subdirectory of a glibc *source* tree, after >> a build. You may have to create the >> /builddir/build/BUILDROOT/glibc-2.26-16.fc27.ppc64/usr/lib/locale >> directory. I have only reproduced this inside a Fedora 27 chroot on a >> Fedora 26 host, but there it does not matter if you run the old (chroot) >> or newly built binary. >> >> I filed this as a glibc bug for tracking: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=22390 >> >> There's an strace log and a coredump from the crash. >> >> I think the data shows that the address in question should be writable. >> >> The crossed 0x0000800000000000 binary is very suggestive. I think that >> based on the operation of glibc's malloc, this write would be the first >> time this happens during the lifetime of the process. >> >> Does that ring any bells? Is there anything I can do to provide more >> data? The host is an LPAR with a stock Fedora 26 kernel, so I can use >> any diagnostics tool which is provided by Fedora. > > There was a recent change to move to 128TB address space by default, > and option for 512TB addresses if explicitly requested. > > Your brk request asked for > 128TB which the kernel gave it, but the > address limit in the paca that the SLB miss tests against was not > updated to reflect the switch to 512TB address space. We should not return that address, unless we requested with a hint value of > 128TB. IIRC we discussed this early during the mmap interface change and said, we will return an address > 128T only if the hint address is above 128TB (not hint addr + length). I am not sure why we are finding us returning and address > 128TB with paca limit set to 128TB? > > Why is your brk starting so high? Are you trying to test the > 128TB > case, or maybe something is confused by the 64->128TB change? What's > the strace look like if you run on a distro or <= 4.10 kernel? > > Something like the following patch may help if you could test. > > Thanks, > Nick > -aneesh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
