First, I'm not sure what I was doing wrong yesterday, but I now have the LD_PRELOAD lock-elision-disablement running. And, when running under valgrind, we no longer see the reports from valgrind. I'm now running without valgrind to see whether we still observe stack corruption.
A few comments on the most recent comments. Re #40: Bill, we have never actually seen a natural SEGV in __lll_unlock_elision in our tests - instead we see random stack corruption, per my description in #5. We saw some complaints about __lll_lock_elision when running under valgrind, but some comments in this thread have made me question whether valgrind actually understands what is happening there. Re #38: We were thinking the same thing. I will ask around to see if we have any appropriate machines. Re #37: I don't think it is an option for us as almost all of our locks are wrapped pthread locks via std::mutex. Re #35: Almost all of our lock management is via C++ RAII types (std::unique_lock, etc), and we run these tests across many many systems. I'm almost certain that a double unlock would have been caught by now, or would cause crashes elsewhere. In particular I would expect that the windows debug runtime would alert us. However, I will see if there is some easy way we can check for this. I'm running the original repro right now with HLE disabled. Usually it takes a few hours before we see a stack corruption event, so I will follow up later today with more results. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1640518 Title: MongoDB Memory corruption To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1640518/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
