Bug 1696615
| Summary: | liblsan fails on powerpc | ||
|---|---|---|---|
| Product: | Red Hat Developer Toolset | Reporter: | Michael Petlan <mpetlan> |
| Component: | gcc | Assignee: | Marek Polacek <mpolacek> |
| Status: | CLOSED WONTFIX | QA Contact: | Martin Cermak <mcermak> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | DTS 8.1 RHEL 7 | CC: | bugproxy, hannsj_uhl, jakub, law, mcermak, mnewsome, mpolacek, ohudlick, tborcin |
| Target Milestone: | alpha | ||
| Target Release: | 8.1 | ||
| Hardware: | ppc64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-07-09 21:13:38 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1667885 | ||
| Bug Blocks: | 1598750 | ||
------- Comment From seurer.com 2019-04-10 11:30 EDT------- I can duplicate this behavior on RHEL 7.x systems (both LE and BE) using gcc 8. On a RHEL 8 beta system (and other non-RHEL systems) it works just fine. Digging into the failure a bit... CHECK_EQ(kSpaceBeg, reinterpret_cast<uptr>( MmapFixedNoAccess(kSpaceBeg, TotalSpaceSize))); This is where it fails. kSpaceBeg is 0 and MmapFixedNoAccess is returning -1 so CHECK_EQ throws an error. MmapFixedNoAccess under the covers just calls mmap via syscall and mmap is failing so it returns -1. Looking at errno I see: ENOMEM 12 Cannot allocate memory Everything is exactly the same on systems where it works so I do not understand why it fails only on RHEL 7.x. ------- Comment From wschmidt.com 2019-04-10 11:58 EDT------- What about kernel levels, are they identical? ------- Comment From bergner.com 2019-04-10 12:17 EDT------- How about any ulimit differences? ------- Comment From seurer.com 2019-04-10 12:12 EDT------- The 7.x system is running an older kernel but the latest one available for it (I just updated the system yesterday) 7.x: 3.10.0-957.10.1.el7.ppc64le 8.x: 4.18.0-67.el8.ppc64le ------- Comment From seurer.com 2019-04-10 13:39 EDT------- I looked at the ulimits: seurer@tulibee:~$ diff rhel7 rhel8 5,6c5,6 < pending signals (-i) 1722680 < max locked memory (kbytes, -l) 64 --- > pending signals (-i) 511025 > max locked memory (kbytes, -l) 16384 14c14 < max user processes (-u) 4096 --- > max user processes (-u) 511025 Maybe max locked memory? Alas, you can't set set that. seurer@tulibee:~$ ulimit -l 16384 -bash: ulimit: max locked memory: cannot modify limit: Operation not permitted ------- Comment From bergner.com 2019-04-10 19:43 EDT------- In reply to comment #11 > Maybe max locked memory? Alas, you can't set set that. > > seurer@tulibee:~$ ulimit -l 16384 > -bash: ulimit: max locked memory: cannot modify limit: Operation not > permitted Even as root (just as a check to see whether it works)? ------- Comment From seurer.com 2019-04-10 23:53 EDT------- Yes, it works as root. Not sure I want to test that way though. ------- Comment From bergner.com 2019-04-11 10:49 EDT------- (In reply to comment #13) > Yes, it works as root. Not sure I want to test that way though. Not saying we should. But does setting the max locked memory to the same value as the RHEL8 system allow the lsan test case to run correctly? If so, I think we can close this as NOTABUG ...in the compiler. ...and then change the max locked memory back to it's old value. :-) ------- Comment From seurer.com 2019-04-11 15:13 EDT------- No, it still fails. So looking at this on RHEL7.x with strace I see... mmap(0x600000000000, 4398046576640, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = -1 ENOMEM (Cannot allocate memory) On RHEL8 mmap(0x600000000000, 4398046576640, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x600000000000 For mmap the second parm is the size which is pretty large here. Maybe it really can't allocate that much? Note that on both systems the memory settings via ulimit were unlimited. The failing system actually has more real memory than the working system. ------- Comment From bergner.com 2019-04-11 16:01 EDT------- Can you run both the RHEL7 and RHEL8 tests in gdb and set a breakpoint at that mmap and then have a look at /proc/<pid>/maps? Maybe RHEL7 is just being sloppy with it's virtual address space and yeah, there isn't a continuous memory block available, which would mean NOTABUG. ------- Comment From seurer.com 2019-04-12 14:29 EDT------- So the immediate cause of this problem is that the lsan memory allocator in gcc 8 uses a fixed address of 0x600000000000ULL for starting its memory maps. This is beyond the end of virtual memory for some older kernels (which end at 0x400000000000ULL) but within range for newer ones. Thus why it fails on RHEL 7 and works on RHEL 8. In gcc trunk (future gcc 9) they change the fixed address to 0x0a0000000000ULL which is within the valid range for both new and old kernels but can run into trouble if ASLR is active. Note that lsan is a limited piece of asan (Address Sanitizer) and the full asan allows for dynamically choosing the starting address at run time. lsan is not set up to do this. asan works fine with gcc 8. ------- Comment From wschmidt.com 2019-04-12 16:36 EDT------- This is looking more and more like a WONTFIX to me. The gcc implementation of lsan does not include any test cases, whereas LLVM's implementation has quite a few. Without test cases, lsan on POWER is literally untested, and it is unsurprising that it doesn't work. I'm tending to think this should just be considered unsupported. ------- Comment From bergner.com 2019-04-18 13:06 EDT------- (In reply to comment #18) > This is looking more and more like a WONTFIX to me. > > The gcc implementation of lsan does not include any test cases, whereas > LLVM's implementation has quite a few. Without test cases, lsan on POWER is > literally untested, and it is unsurprising that it doesn't work. > > I'm tending to think this should just be considered unsupported. Agreed. Talking with Bill (Seurer) offline and the testing he has done, it looks like LSAN just doesn't work in GCC 8 and that to backport the upstream code to make it work is just too invasive. Given that, I am marking this as WONTFIX. Marking as WONTFIX too, as per Comment 12. |
Description of problem: A program built with -fsanitize=leak does not run on powerpc (both BE and LE). Version-Release number of selected component (if applicable): devtoolset-8-liblsan-devel-8.3.1-3.el7.ppc64 How reproducible: 100% on ppc64 or ppc64le Steps to Reproduce: 1. cat > dummy.cpp <<EOF #include <iostream> int main(void) { std::cout << "Hello, I am dummy." << std::endl; return 0; } EOF 2. scl enable devtoolset-8 -- c++ -fsanitize=leak -fno-omit-frame-pointer -o dummy dummy.cpp 3. ./dummy Actual results: ==6682==Sanitizer CHECK failed: ../../../../libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:74 ((kSpaceBeg)) == ((reinterpret_cast<uptr>( MmapFixedNoAccess(kSpaceBeg, TotalSpaceSize)))) (105553116266496, -1) Expected results: Hello, I am dummy.