LOCKFREE-HASH-CONCURRENT-TWIDDLING fails because of memory corruption

[Chris Wagner]

When running the tests/info.impure.lisp tests, LOCKFREE-HASH-CONCURRENT-TWIDDLING tests fails pretty much consistently:

::: Running :LOCKFREE-HASH-CONCURRENT-TWIDDLING
CORRUPTION WARNING in SBCL pid 3257(tid 0x7fff7d514310):
Memory fault at b00c5010 (pc=0x7fff97964de9, sp=0x11fe900)
The integrity of this image is possibly compromised.
Continuing with fingers crossed.
::: UNEXPECTED-FAILURE :LOCKFREE-HASH-CONCURRENT-TWIDDLING
    due to #<MEMORY-FAULT-ERROR {1002EE0433}>:
        "Unhandled memory fault at #xB00C5010."

Note that this could be related to the same problem that causes the ATOMIC-PUSH test (in tests/compare-and-swap.impure.lisp) to fail regularly, though not systematically, with the same error message. (I have yet to check that the exception leading the corruption detection is the same in both cases.)

[Chris Wagner (christian-r-wagner)]

The problem affects SBCL 1.2.3 and 1.2.4, at least.

I built them using SBCL 1.1.6.0-3c5581a as host Lisp (because that's the latest officially distributed binary version of SBCL for MacOS/X). I can forward the log of the build process.

The platform is:
$ system_profiler SPSoftwareDataType
 System Version: OS X 10.9.5 (13F34)
 Kernel Version: Darwin 13.4.0

$ system_profiler SPHardwareDataType
 Model Name: MacBook Pro
 Model Identifier: MacBookPro5,1
 Processor Name: Intel Core 2 Duo

$ uname -a
 ... root:xnu-2422.115.4~1/RELEASE_X86_64

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

[Douglas Katzman (dougk)]

macOS multithreading seems to be working better than it was 4 years ago.
I'd say this issue is obsolete