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
Evgenii Stepanov via llvm-dev
2018-Sep-11 18:23 UTC
[llvm-dev] [msan] Failing mmap.cc test
Do you see the problem after r340957? On Tue, Sep 11, 2018 at 6:57 AM, David Greene <dag at cray.com> wrote:> 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? >We figured it out in https://reviews.llvm.org/D51364 - msan shadow mapping function can not distinguish a failed mmap with a successfull mmap at address 0 with the new interface.> > -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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180911/b521c2cc/attachment.html>
Evgenii Stepanov <eugeni.stepanov at gmail.com> writes:> Do you see the problem after r340957?Yes. -David> On Tue, Sep 11, 2018 at 6:57 AM, David Greene <dag at cray.com> wrote: > > 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? > > We figured it out in https://reviews.llvm.org/D51364 - msan shadow > mapping function can not distinguish a failed mmap with a successfull > mmap at address 0 with the new interface. > > -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 >