Comment 42 for bug 1640518

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.