[Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change

["nars at yottadb dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29863

--- Comment #5 from Narayanan Iyer <nars at yottadb dot com> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Narayanan Iyer from comment #3) 
> > More importantly this code works fine prior to glibc 2.36. It fails only
> > with glibc 2.36.
> 
> On x86_64. My bet it fails on most other targets and always had failed.
> The Seg fault is just saying you are violating atomicity.
> It is not only a race condition but the race condition is inside memcmp
> itself now since memcmp is not atomic for the whole length, it is a byte
> wise comparison which can be read more than once so you just happen to run
> into a bug in your code.
> Having memcmp being atomicity and reading from the memory only once is ABI
> thing really and x86_64 ABI does not talk about that. It just happened to
> work on accident does not mean the behavior should go back to what it was.

Seems to me you are saying that `memcmp()` can only be called on memory that is
guaranteed to be never changing. And that it should never be called on a shared
memory buffer whose contents could be concurrently changing as it goes into
undefined behavior territory. That does not sound right to me as we have been
using `memcmp()` with shared memory (where multiple processes write to that
memory buffer all the time) for the past 25+ years on a variety of
architectures and operating systems and have never once seen a SIG-11 in
memcmp().

-- 
You are receiving this mail because:
You are on the CC list for the bug.