* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
@ 2022-12-12 13:02 ` nars at yottadb dot com
2022-12-13 18:26 ` pinskia at gcc dot gnu.org
` (22 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: nars at yottadb dot com @ 2022-12-12 13:02 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
Narayanan Iyer <nars at yottadb dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nars at yottadb dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
2022-12-12 13:02 ` [Bug libc/29863] " nars at yottadb dot com
@ 2022-12-13 18:26 ` pinskia at gcc dot gnu.org
2022-12-13 18:28 ` pinskia at gcc dot gnu.org
` (21 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-12-13 18:26 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu.org
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Is this defined code? Because you have a race condition here.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
2022-12-12 13:02 ` [Bug libc/29863] " nars at yottadb dot com
2022-12-13 18:26 ` pinskia at gcc dot gnu.org
@ 2022-12-13 18:28 ` pinskia at gcc dot gnu.org
2022-12-13 18:33 ` nars at yottadb dot com
` (20 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-12-13 18:28 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this code is undefined as there is no memory atomic load/stores. memcmp
is not atomic in C11 either.
So changing the memory that memcmp is using is just undefined code.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (2 preceding siblings ...)
2022-12-13 18:28 ` pinskia at gcc dot gnu.org
@ 2022-12-13 18:33 ` nars at yottadb dot com
2022-12-13 18:39 ` pinskia at gcc dot gnu.org
` (19 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: nars at yottadb dot com @ 2022-12-13 18:33 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #3 from Narayanan Iyer <nars at yottadb dot com> ---
(In reply to Andrew Pinski from comment #1)
> Is this defined code? Because you have a race condition here.
Yes there is a race condition here. That is intentional and only to demonstrate
the underlying issue in memcmp-sse2.S.
The `memcmp()` in one thread can return 1 or 0 depending on how the other
thread changes the memory. I am fine with the non-deterministic return value.
But that should never result in a SIG-11 in my understanding.
More importantly this code works fine prior to glibc 2.36. It fails only with
glibc 2.36.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (3 preceding siblings ...)
2022-12-13 18:33 ` nars at yottadb dot com
@ 2022-12-13 18:39 ` pinskia at gcc dot gnu.org
2022-12-13 18:45 ` nars at yottadb dot com
` (18 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-12-13 18:39 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (4 preceding siblings ...)
2022-12-13 18:39 ` pinskia at gcc dot gnu.org
@ 2022-12-13 18:45 ` nars at yottadb dot com
2022-12-13 18:52 ` pinskia at gcc dot gnu.org
` (17 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: nars at yottadb dot com @ 2022-12-13 18:45 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (5 preceding siblings ...)
2022-12-13 18:45 ` nars at yottadb dot com
@ 2022-12-13 18:52 ` pinskia at gcc dot gnu.org
2022-12-13 19:13 ` goldstein.w.n at gmail dot com
` (16 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-12-13 18:52 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Narayanan Iyer from comment #5)
> 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().
That does not mean it is correctly well defined code.
memcmp cannot be used on memory which is going to be changed under its back.
since it is not atomic.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (6 preceding siblings ...)
2022-12-13 18:52 ` pinskia at gcc dot gnu.org
@ 2022-12-13 19:13 ` goldstein.w.n at gmail dot com
2022-12-13 19:36 ` bhaskar at yottadb dot com
` (15 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: goldstein.w.n at gmail dot com @ 2022-12-13 19:13 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
Noah Goldstein <goldstein.w.n at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |goldstein.w.n at gmail dot com
--- Comment #7 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
The fix is basically just:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/memcmp-sse2.S;h=afd450d0206d6633da9fbc4607a7fa6aeb4e137c;hb=HEAD#l46
```
-# define SIZE_OFFSET (CHAR_PER_VEC * 2)
+# define SIZE_OFFSET 0
```
Want to add the other functions / implementations are likely
also affected by a similar bug.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (7 preceding siblings ...)
2022-12-13 19:13 ` goldstein.w.n at gmail dot com
@ 2022-12-13 19:36 ` bhaskar at yottadb dot com
2022-12-13 20:09 ` goldstein.w.n at gmail dot com
` (14 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bhaskar at yottadb dot com @ 2022-12-13 19:36 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
K.S. Bhaskar <bhaskar at yottadb dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bhaskar at yottadb dot com
--- Comment #8 from K.S. Bhaskar <bhaskar at yottadb dot com> ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Narayanan Iyer from comment #5)
> > 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().
>
> That does not mean it is correctly well defined code.
> memcmp cannot be used on memory which is going to be changed under its back.
> since it is not atomic.
Since memcmp() is not atomic, it is of course appropriate for the the results
of the comparison to have a race condition. However, since the addresses by
which a process has that memory mapped don't change, a SIG-11 should never
occur. Even if all other processes which have that memory mapped terminate
while the memcmp() is running in a process, that process will not unmap the
memory and it will remain valid (assuming it was valid to start with).
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (8 preceding siblings ...)
2022-12-13 19:36 ` bhaskar at yottadb dot com
@ 2022-12-13 20:09 ` goldstein.w.n at gmail dot com
2022-12-13 20:18 ` goldstein.w.n at gmail dot com
` (13 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: goldstein.w.n at gmail dot com @ 2022-12-13 20:09 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #9 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to K.S. Bhaskar from comment #8)
> (In reply to Andrew Pinski from comment #6)
> > (In reply to Narayanan Iyer from comment #5)
> > > 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().
> >
> > That does not mean it is correctly well defined code.
> > memcmp cannot be used on memory which is going to be changed under its back.
> > since it is not atomic.
>
> Since memcmp() is not atomic, it is of course appropriate for the the
> results of the comparison to have a race condition. However, since the
> addresses by which a process has that memory mapped don't change, a SIG-11
> should never occur. Even if all other processes which have that memory
> mapped terminate while the memcmp() is running in a process, that process
> will not unmap the memory and it will remain valid (assuming it was valid to
> start with).
memcmp() is incorrect if the values change from under it. How that
incorrectness will manifest is completely undefined.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (9 preceding siblings ...)
2022-12-13 20:09 ` goldstein.w.n at gmail dot com
@ 2022-12-13 20:18 ` goldstein.w.n at gmail dot com
2022-12-13 20:46 ` nars at yottadb dot com
` (12 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: goldstein.w.n at gmail dot com @ 2022-12-13 20:18 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #10 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to Noah Goldstein from comment #9)
> (In reply to K.S. Bhaskar from comment #8)
> > (In reply to Andrew Pinski from comment #6)
> > > (In reply to Narayanan Iyer from comment #5)
> > > > 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().
> > >
> > > That does not mean it is correctly well defined code.
> > > memcmp cannot be used on memory which is going to be changed under its back.
> > > since it is not atomic.
> >
> > Since memcmp() is not atomic, it is of course appropriate for the the
> > results of the comparison to have a race condition. However, since the
> > addresses by which a process has that memory mapped don't change, a SIG-11
> > should never occur. Even if all other processes which have that memory
> > mapped terminate while the memcmp() is running in a process, that process
> > will not unmap the memory and it will remain valid (assuming it was valid to
> > start with).
>
> memcmp() is incorrect if the values change from under it. How that
> incorrectness will manifest is completely undefined.
Out of curiosity what is the use-case that causes this to happen? Is it
idiomatic in some way?
I'm unhappy that the code causes a SIG-11 in this case, but changing
it to harden against this case is not free for correct usage performance
so I'm not really convinced it's worth supporting this buggy usage unless
this bug is common to some idiomatic schema (although even then, I'm not
sure whether we could harden the entire string/mem library to that
usage or even what changes that would imply).
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (10 preceding siblings ...)
2022-12-13 20:18 ` goldstein.w.n at gmail dot com
@ 2022-12-13 20:46 ` nars at yottadb dot com
2022-12-13 21:09 ` hjl.tools at gmail dot com
` (11 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: nars at yottadb dot com @ 2022-12-13 20:46 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #11 from Narayanan Iyer <nars at yottadb dot com> ---
(In reply to Noah Goldstein from comment #10)
> Out of curiosity what is the use-case that causes this to happen? Is it
> idiomatic in some way?
>
> I'm unhappy that the code causes a SIG-11 in this case, but changing
> it to harden against this case is not free for correct usage performance
> so I'm not really convinced it's worth supporting this buggy usage unless
> this bug is common to some idiomatic schema (although even then, I'm not
> sure whether we could harden the entire string/mem library to that
> usage or even what changes that would imply).
We implement a database called YottaDB. It uses optimistic concurrency control
(also known as OCC) to implement transaction processing. See
https://en.wikipedia.org/wiki/Optimistic_concurrency_control for more details.
Every process that is in a transaction reads database values (from shared
memory) without holding a lock and tentatively prepare the needed changes in
private memory. To do this, it needs to examine shared memory contents and it
is here that we do the `memcmp()` calls which ended up with a SIG-11.
At the end of the transaction, we grab a lock and see if anything changed since
we started the transaction and if not we proceed to commit. If we notice
something changed, we restart the transaction. We minimize the use of locks
using this approach to get faster transaction throughput.
As I had mentioned in a previous comment, this model has been in use by us for
the past 25+ years in various architectures (x86_64, i386, RS6000, Alpha, VAX,
Sparc, HPPA etc.) and operating systems (Linux, AIX, Tru64, Solaris, HPUX etc.)
and has never caused a SIG-11 until now (i.e. glibc 2.36).
As you can see in the `Examples` section of the wikipedia link I mention above,
there are a lot of databases that use OCC. It is likely all of them use similar
techniques and are affected as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (11 preceding siblings ...)
2022-12-13 20:46 ` nars at yottadb dot com
@ 2022-12-13 21:09 ` hjl.tools at gmail dot com
2022-12-13 21:53 ` bhaskar at yottadb dot com
` (10 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: hjl.tools at gmail dot com @ 2022-12-13 21:09 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (12 preceding siblings ...)
2022-12-13 21:09 ` hjl.tools at gmail dot com
@ 2022-12-13 21:53 ` bhaskar at yottadb dot com
2022-12-13 23:01 ` goldstein.w.n at gmail dot com
` (9 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bhaskar at yottadb dot com @ 2022-12-13 21:53 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #12 from K.S. Bhaskar <bhaskar at yottadb dot com> ---
While I can't speak to the other databases, the YottaDB code base goes back
much further than 25 years. Under the name GT.M, it first saw live production
use in 1986. Its use of optimistic concurrency control was inspired by Kung &
Robinson's seminal paper
(https://www.eecs.harvard.edu/~htk/publication/1981-tods-kung-robinson.pdf). I
personally know the original author of the code, as well as someone who has
worked on the code base since the mid 1980s. In addition to those mentioned by
Narayanan, the code has over the decades run on several other CPU architectures
and operating systems.
I hope this suffices as a use case.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (13 preceding siblings ...)
2022-12-13 21:53 ` bhaskar at yottadb dot com
@ 2022-12-13 23:01 ` goldstein.w.n at gmail dot com
2022-12-13 23:16 ` nars at yottadb dot com
` (8 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: goldstein.w.n at gmail dot com @ 2022-12-13 23:01 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #13 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to K.S. Bhaskar from comment #12)
> While I can't speak to the other databases, the YottaDB code base goes back
> much further than 25 years. Under the name GT.M, it first saw live
> production use in 1986. Its use of optimistic concurrency control was
> inspired by Kung & Robinson's seminal paper
> (https://www.eecs.harvard.edu/~htk/publication/1981-tods-kung-robinson.pdf).
> I personally know the original author of the code, as well as someone who
> has worked on the code base since the mid 1980s. In addition to those
> mentioned by Narayanan, the code has over the decades run on several other
> CPU architectures and operating systems.
>
> I hope this suffices as a use case.
Can you test the following dif:
```
@@ -308,7 +308,7 @@ L(ret_nonzero_vec_end_0):
setg %dl
leal -1(%rdx, %rdx), %eax
# else
- addl %edx, %eax
+ addq %rdx, %rax
movzbl (VEC_SIZE * -1 + SIZE_OFFSET)(%rsi, %rax), %ecx
movzbl (VEC_SIZE * -1 + SIZE_OFFSET)(%rdi, %rax), %eax
subl %ecx, %eax
```
If that fixes things I'm okay making the change.
I'm opposed to explicitly supporting it, but am happy
to try and make this failure from the unsupported
usage less dramatic.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (14 preceding siblings ...)
2022-12-13 23:01 ` goldstein.w.n at gmail dot com
@ 2022-12-13 23:16 ` nars at yottadb dot com
2022-12-13 23:39 ` goldstein.w.n at gmail dot com
` (7 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: nars at yottadb dot com @ 2022-12-13 23:16 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #14 from Narayanan Iyer <nars at yottadb dot com> ---
(In reply to Noah Goldstein from comment #13)
>
> Can you test the following dif:
> ```
> @@ -308,7 +308,7 @@ L(ret_nonzero_vec_end_0):
> setg %dl
> leal -1(%rdx, %rdx), %eax
> # else
> - addl %edx, %eax
> + addq %rdx, %rax
> movzbl (VEC_SIZE * -1 + SIZE_OFFSET)(%rsi, %rax), %ecx
> movzbl (VEC_SIZE * -1 + SIZE_OFFSET)(%rdi, %rax), %eax
> subl %ecx, %eax
>
> ```
>
> If that fixes things I'm okay making the change.
>
> I'm opposed to explicitly supporting it, but am happy
> to try and make this failure from the unsupported
> usage less dramatic.
This change sounds much better.
Is there a url that describes how to build glibc from source and use it in my
application?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (15 preceding siblings ...)
2022-12-13 23:16 ` nars at yottadb dot com
@ 2022-12-13 23:39 ` goldstein.w.n at gmail dot com
2022-12-14 0:14 ` goldstein.w.n at gmail dot com
` (6 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: goldstein.w.n at gmail dot com @ 2022-12-13 23:39 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #15 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to Narayanan Iyer from comment #14)
> (In reply to Noah Goldstein from comment #13)
> >
> > Can you test the following dif:
> > ```
> > @@ -308,7 +308,7 @@ L(ret_nonzero_vec_end_0):
> > setg %dl
> > leal -1(%rdx, %rdx), %eax
> > # else
> > - addl %edx, %eax
> > + addq %rdx, %rax
> > movzbl (VEC_SIZE * -1 + SIZE_OFFSET)(%rsi, %rax), %ecx
> > movzbl (VEC_SIZE * -1 + SIZE_OFFSET)(%rdi, %rax), %eax
> > subl %ecx, %eax
> >
> > ```
> >
> > If that fixes things I'm okay making the change.
> >
> > I'm opposed to explicitly supporting it, but am happy
> > to try and make this failure from the unsupported
> > usage less dramatic.
>
> This change sounds much better.
>
> Is there a url that describes how to build glibc from source and use it in
> my application?
I just built the current/fixed memcmp into a single library and used
LD_PRELOAD.
This fix seems to keep it from segfaulting although I wouldn't be
surprised if there are some edge cases in other impls / paths
around page boundaries where it can still segfault.
I'll submit a patch with these changes although I'm not sure
its going to get backported.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (16 preceding siblings ...)
2022-12-13 23:39 ` goldstein.w.n at gmail dot com
@ 2022-12-14 0:14 ` goldstein.w.n at gmail dot com
2022-12-14 7:45 ` sam at gentoo dot org
` (5 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: goldstein.w.n at gmail dot com @ 2022-12-14 0:14 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #16 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to Narayanan Iyer from comment #14)
> (In reply to Noah Goldstein from comment #13)
> >
> > Can you test the following dif:
> > ```
> > @@ -308,7 +308,7 @@ L(ret_nonzero_vec_end_0):
> > setg %dl
> > leal -1(%rdx, %rdx), %eax
> > # else
> > - addl %edx, %eax
> > + addq %rdx, %rax
> > movzbl (VEC_SIZE * -1 + SIZE_OFFSET)(%rsi, %rax), %ecx
> > movzbl (VEC_SIZE * -1 + SIZE_OFFSET)(%rdi, %rax), %eax
> > subl %ecx, %eax
> >
> > ```
> >
> > If that fixes things I'm okay making the change.
> >
> > I'm opposed to explicitly supporting it, but am happy
> > to try and make this failure from the unsupported
> > usage less dramatic.
>
> This change sounds much better.
>
> Is there a url that describes how to build glibc from source and use it in
> my application?
Posted a patch which should fix the issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (17 preceding siblings ...)
2022-12-14 0:14 ` goldstein.w.n at gmail dot com
@ 2022-12-14 7:45 ` sam at gentoo dot org
2022-12-14 15:40 ` nars at yottadb dot com
` (4 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: sam at gentoo dot org @ 2022-12-14 7:45 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
Sam James <sam at gentoo dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sam at gentoo dot org
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (18 preceding siblings ...)
2022-12-14 7:45 ` sam at gentoo dot org
@ 2022-12-14 15:40 ` nars at yottadb dot com
2022-12-14 18:17 ` nars at yottadb dot com
` (3 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: nars at yottadb dot com @ 2022-12-14 15:40 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #17 from Narayanan Iyer <nars at yottadb dot com> ---
(In reply to Noah Goldstein from comment #16)
>
> Posted a patch which should fix the issue.
Thank you very much for the prompt fix.
I will try to verify this in my system using the LD_PRELOAD trick you
mentioned.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (19 preceding siblings ...)
2022-12-14 15:40 ` nars at yottadb dot com
@ 2022-12-14 18:17 ` nars at yottadb dot com
2023-05-14 21:46 ` ppluzhnikov at google dot com
` (2 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: nars at yottadb dot com @ 2022-12-14 18:17 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #18 from Narayanan Iyer <nars at yottadb dot com> ---
(In reply to Narayanan Iyer from comment #17)
>
> Thank you very much for the prompt fix.
>
> I will try to verify this in my system using the LD_PRELOAD trick you
> mentioned.
I tried compiling just memcmp-sse2.S but encountered issues. So went ahead and
rebuilt the full glibc without and with your fix. And verified that without
your fix, the test program crashed reliably whereas with your fix the test
program ran fine all the time.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (20 preceding siblings ...)
2022-12-14 18:17 ` nars at yottadb dot com
@ 2023-05-14 21:46 ` ppluzhnikov at google dot com
2023-05-14 21:48 ` ppluzhnikov at google dot com
2023-05-14 21:49 ` ppluzhnikov at google dot com
23 siblings, 0 replies; 25+ messages in thread
From: ppluzhnikov at google dot com @ 2023-05-14 21:46 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
Paul Pluzhnikov <ppluzhnikov at google dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
CC| |ppluzhnikov at google dot com
--- Comment #19 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
Fixed by:
Author: Noah Goldstein <goldstein.w.n@gmail.com>
Date: Wed Dec 14 10:52:10 2022 -0800
x86: Prevent SIGSEGV in memcmp-sse2 when data is concurrently modified [BZ
#29863]
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (21 preceding siblings ...)
2023-05-14 21:46 ` ppluzhnikov at google dot com
@ 2023-05-14 21:48 ` ppluzhnikov at google dot com
2023-05-14 21:49 ` ppluzhnikov at google dot com
23 siblings, 0 replies; 25+ messages in thread
From: ppluzhnikov at google dot com @ 2023-05-14 21:48 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
--- Comment #20 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
(In reply to Paul Pluzhnikov from comment #19)
> Fixed by:
>
commit b712be52645282c706a5faa038242504feb06db5
> Author: Noah Goldstein <goldstein.w.n@gmail.com>
> Date: Wed Dec 14 10:52:10 2022 -0800
>
> x86: Prevent SIGSEGV in memcmp-sse2 when data is concurrently modified
> [BZ #29863]
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change
2022-12-07 10:49 [Bug libc/29863] New: Segmentation fault in memcmp-sse2.S if memory contents can concurrently change nars at yottadb dot com
` (22 preceding siblings ...)
2023-05-14 21:48 ` ppluzhnikov at google dot com
@ 2023-05-14 21:49 ` ppluzhnikov at google dot com
23 siblings, 0 replies; 25+ messages in thread
From: ppluzhnikov at google dot com @ 2023-05-14 21:49 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=29863
Paul Pluzhnikov <ppluzhnikov at google dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2.37
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 25+ messages in thread