The mmap.cc test is failing for me on aarch64 SuSE 12. The assert
assert(AddrIsApp(p)) fails. The last value printed from mmap is
0xf00000000 which is indeed not MAP_FAILED but also not a valid address
acoording to mmap.cc's mapping table.
Is there something about SuSE 12's kernel that behaves differently from
what this test expects? I am not a kernel guy...
The sequence of the last handful of addresses returned and printed by
the test is:
0x5600000000
0x5500000000
0x5400000000
0x5300000000
0x5200000000
0x5100000000
0x5000000000
0xf00000000
That jump in value looks suspicious to me.
Also, a lot of sanitizer symbols are reported to be "optimized out" by
gdb even with a debug LLVM build and gdb gets very confused about where
execution is going. Is that expected? Is there a special cmake build
flag to enable more debug info in compiler-rt and/or the sanitizer
runtime?
-David
Evgenii Stepanov via llvm-dev
2018-Sep-10 21:57 UTC
[llvm-dev] [msan] Failing mmap.cc test
See https://reviews.llvm.org/D51364 - a very similar bug was introduced by a compiler-rt change and then fixed by a revert. On Mon, Sep 10, 2018 at 8:54 AM, David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote:> The mmap.cc test is failing for me on aarch64 SuSE 12. The assert > assert(AddrIsApp(p)) fails. The last value printed from mmap is > 0xf00000000 which is indeed not MAP_FAILED but also not a valid address > acoording to mmap.cc's mapping table. > > Is there something about SuSE 12's kernel that behaves differently from > what this test expects? I am not a kernel guy... > > The sequence of the last handful of addresses returned and printed by > the test is: > > 0x5600000000 > 0x5500000000 > 0x5400000000 > 0x5300000000 > 0x5200000000 > 0x5100000000 > 0x5000000000 > 0xf00000000 > > That jump in value looks suspicious to me. > > Also, a lot of sanitizer symbols are reported to be "optimized out" by > gdb even with a debug LLVM build and gdb gets very confused about where > execution is going. Is that expected? Is there a special cmake build > flag to enable more debug info in compiler-rt and/or the sanitizer > runtime? > > -David > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180910/116aecc8/attachment.html>
Evgenii Stepanov via llvm-dev
2018-Sep-10 21:58 UTC
[llvm-dev] [msan] Failing mmap.cc test
And the jump is expected because of a previous mapping that ends at 0x50...00. On Mon, Sep 10, 2018 at 2:57 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote:> See https://reviews.llvm.org/D51364 - a very similar bug was introduced > by a compiler-rt change and then fixed by a revert. > > > On Mon, Sep 10, 2018 at 8:54 AM, David Greene via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> The mmap.cc test is failing for me on aarch64 SuSE 12. The assert >> assert(AddrIsApp(p)) fails. The last value printed from mmap is >> 0xf00000000 which is indeed not MAP_FAILED but also not a valid address >> acoording to mmap.cc's mapping table. >> >> Is there something about SuSE 12's kernel that behaves differently from >> what this test expects? I am not a kernel guy... >> >> The sequence of the last handful of addresses returned and printed by >> the test is: >> >> 0x5600000000 >> 0x5500000000 >> 0x5400000000 >> 0x5300000000 >> 0x5200000000 >> 0x5100000000 >> 0x5000000000 >> 0xf00000000 >> >> That jump in value looks suspicious to me. >> >> Also, a lot of sanitizer symbols are reported to be "optimized out" by >> gdb even with a debug LLVM build and gdb gets very confused about where >> execution is going. Is that expected? Is there a special cmake build >> flag to enable more debug info in compiler-rt and/or the sanitizer >> runtime? >> >> -David >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180910/85c34d6a/attachment.html>
Evgenii Stepanov <eugeni.stepanov at gmail.com> writes:> See https://reviews.llvm.org/D51364 - a very similar bug was > introduced by a compiler-rt change and then fixed by a revert.Ok, so what do we do about this? D50940 seems to have introduced the problem but it was reverted. The "tentative fix" in D51364 was abandoned but it's not clear to me why (maybe because D50940 was reverted?). It is also not clear to me how D50940 could have introduced the problem. Was it just coincidence that someone saw this issue after D50940 was applied? -David> On Mon, Sep 10, 2018 at 8:54 AM, David Greene via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > The mmap.cc test is failing for me on aarch64 SuSE 12. The assert > assert(AddrIsApp(p)) fails. The last value printed from mmap is > 0xf00000000 which is indeed not MAP_FAILED but also not a valid > address > acoording to mmap.cc's mapping table. > > Is there something about SuSE 12's kernel that behaves differently > from > what this test expects? I am not a kernel guy... > > The sequence of the last handful of addresses returned and printed > by > the test is: > > 0x5600000000 > 0x5500000000 > 0x5400000000 > 0x5300000000 > 0x5200000000 > 0x5100000000 > 0x5000000000 > 0xf00000000 > > That jump in value looks suspicious to me. > > Also, a lot of sanitizer symbols are reported to be "optimized > out" by > gdb even with a debug LLVM build and gdb gets very confused about > where > execution is going. Is that expected? Is there a special cmake > build > flag to enable more debug info in compiler-rt and/or the sanitizer > runtime? > > -David > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev