RE: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change

["Narayanan Iyer" <nars@yottadb.com>]

As I also mentioned at https://sourceware.org/bugzilla/show_bug.cgi?id=29863#c3, it might not be a well defined test case. But memcmp() is never expected to SIG-11 in any circumstance as long as the buffers it is passed in are accessible from start to finish.

In the same bug report, I had also provided a timeline of the instructions that I believe got executed in the crash case and pointed to the failing assembly instruction. The test case was just a easy way for you to see the problem yourself. Even if you don't accept the test case, can you take a look at the rest of my bug report to see if you agree with the finding.

Thanks,
Narayanan.

-----Original Message-----
From: Andrew Pinski [mailto:pinskia@gmail.com] 
Sent: Tuesday, December 13, 2022 1:32 PM
To: Narayanan Iyer <nars@yottadb.com>
Cc: libc-alpha@sourceware.org
Subject: Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change

On Tue, Dec 13, 2022 at 10:21 AM Narayanan Iyer via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> Hi,
>
> I had created a glibc bug report at https://sourceware.org/bugzilla/show_bug.cgi?id=29863
>
> And have included the title of that report in the email subject as well.
>
> It has been a week since I created the issue and I did not hear anything back. I believe this is a regression in glibc 2.36 and have provided enough information in the bug report (along with the commit that caused the regression).

I don't see how this is a valid well defined testcase. Changing memory
without barriers in both threads is not well defined. memcmp is not
guaranteed to be atomic or have any atomicity either.
So you just happen to work before and now your undefined code does not work.

Thanks,
Andrew Pinski

>
> Given the upcoming glibc 2.37 release, I was asked (by Carlos O'Donell <carlos@redhat.com>) to raise it on this mailing list to get the attention of the glibc developers.
>
> I am hoping one of you could take a quick look at the bug report and see if it is worth fixing it in time for glibc 2.37.
>
> Thanks,
> Narayanan.
>
>