tl;dr version: The transactional lock elision code has a bug wherein a shared mutex may be written to by thread B after it has been deleted by thread A, thus resulting to a write of two bytes in thread A's stack space. There is a very small window where this can occur.
Try disabling SMT. If the problem goes away, that would be consistent with this being the same bug.
------- Comment From <email address hidden> 2016-11-15 11:18 EDT-------
Brian,
I highly suspect that this is the same glibc 2.23 bug identified here: https:/ /bugs.launchpad .net/ubuntu/ +source/ glibc/+ bug/1640518. We have opened a glibc bugzilla here: https:/ /sourceware. org/bugzilla/ show_bug. cgi?id= 20822. We have two potential fixes under test.
tl;dr version: The transactional lock elision code has a bug wherein a shared mutex may be written to by thread B after it has been deleted by thread A, thus resulting to a write of two bytes in thread A's stack space. There is a very small window where this can occur.
Try disabling SMT. If the problem goes away, that would be consistent with this being the same bug.
Bill