On Sat, 2016-11-05 at 20:32 +0100, Christian Seiler wrote: > On 11/05/2016 08:13 PM, Ian Jackson wrote: > > I have just been debugging a ghostscript segfault on jessie amd64. > > > > Looking at the code, I think that gs in jessie is plainly violating > > the rules about the use of pthread locks. On my partner's machine, > > this makes it segfault on termination (with some input files, at > > least). On my machine it works just fine. The code in sid is better. > > > > I recently encountered what seems to be a similar bug in ogg123 in > > stable. #842796. > > > > Has something changed in jessie's libc recently ? I find it difficult > > to imagine that these bugs would have been missed earlier during the > > life of jessie. > > Recently Frank Fegert discovered a problem with locking in open-iscsi > that only occurs on new hardware. The code previously was wrong, but > earlier CPUs were more forgiving when it came to this error and it > couldn't be triggered. > > Frank wrote about the problem in his blog in great detail: > http://www.bityard.org/blog/2016/08/05/debugging_segfaults_open-iscsi_iscsiuio_intel_broadwell [...]
This is not really a case of older CPUs being 'more forgiving'; they had no locking operations[*] and nothing to forgive. However, glibc uses transactional memory (TSX) on the newer CPUs that implement it, and that new code does result in the CPU detecting some locking errors. It's worth noting that TSX is broken in 'Haswell' processors and is supposed to be disabled via a microcode update. I don't know whether glibc avoids using it on these processors if the microcode update is not applied. (Linux doesn't appear to hide the feature flags.) * The LOCK prefix is for 'bus locking' during a single instruction, i.e. making it atomic. The CPU can't know what higher-level operation it's being used for. Ben. -- Ben Hutchings The world is coming to an end. Please log off.
signature.asc
Description: This is a digitally signed message part
