glibc: the x86 mem[r]chr changes cause random segfaults

glibc: the x86 mem[r]chr changes cause random segfaults

[Manuel Lauss]

Hi Noah,

One of your recent x86 mem[r]chr patches to glibc causes random segfaults in
gcc;  I haven't nailed it down to a single patch yet, but a glibc built
up to commit 0218463dd8265ed937622f88ac68c7d984fe0cfc (all your
commits from 07th June reverted) works just fine.
For me it's very easy to reproduce, just rebuild glibc.

The backtraces all look like this (sorry, no debug symbols for gcc):
#0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
malloc.c:3368
warning: Source file is more recent than executable.
3368      if (chunk_is_mmapped (p))                       /* release
mmapped memory. */
(gdb) bt
#0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
malloc.c:3368
#1  0x00007fdd9debe3e0 in scratch_buffer_free (buffer=0x7ffcc7137fe0)
at ../include/scratch_buffer.h:86
#2  realpath_stk (name=<optimized out>, resolved=<optimized out>,
rname_buf=rname_buf@entry=0x7ffcc7137fe0) at canonicalize.c:423
#3  0x00007fdd9debeaff in __GI___realpath (name=<optimized out>,
resolved=<optimized out>) at canonicalize.c:449
#4  0x000000000048b818 in ?? ()
#5  0x000000000048a62c in ?? ()
#6  0x000000000040d9b4 in ?? ()
#7  0x0000000000416b62 in ?? ()
#8  0x00000000004054e9 in ?? ()
#9  0x0000000000405a89 in ?? ()
#10 0x00007fdd9dea82b7 in __libc_start_call_main
(main=main@entry=0x405a60, argc=argc@entry=103,
argv=argv@entry=0x7ffcc7139708)
   at ../sysdeps/nptl/libc_start_call_main.h:58
#11 0x00007fdd9dea8375 in __libc_start_main_impl (main=0x405a60,
argc=103, argv=0x7ffcc7139708, init=<optimized out>, fini=<optimized
out>, rtld_fini=<optimized out>,
   stack_end=0x7ffcc71396f8) at ../csu/libc-start.c:381
#12 0x0000000000405bb1 in ?? ()

Thanks,
      Manuel

Re: glibc: the x86 mem[r]chr changes cause random segfaults

[H.J. Lu]

On Wed, Jun 8, 2022 at 11:22 AM Manuel Lauss via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> Hi Noah,
>
> One of your recent x86 mem[r]chr patches to glibc causes random segfaults in
> gcc;  I haven't nailed it down to a single patch yet, but a glibc built
> up to commit 0218463dd8265ed937622f88ac68c7d984fe0cfc (all your
> commits from 07th June reverted) works just fine.
> For me it's very easy to reproduce, just rebuild glibc.
>
> The backtraces all look like this (sorry, no debug symbols for gcc):
> #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> malloc.c:3368
> warning: Source file is more recent than executable.
> 3368      if (chunk_is_mmapped (p))                       /* release
> mmapped memory. */
> (gdb) bt
> #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> malloc.c:3368
> #1  0x00007fdd9debe3e0 in scratch_buffer_free (buffer=0x7ffcc7137fe0)
> at ../include/scratch_buffer.h:86
> #2  realpath_stk (name=<optimized out>, resolved=<optimized out>,
> rname_buf=rname_buf@entry=0x7ffcc7137fe0) at canonicalize.c:423
> #3  0x00007fdd9debeaff in __GI___realpath (name=<optimized out>,
> resolved=<optimized out>) at canonicalize.c:449

I suspect that rawmemchr isn't properly handled.

> #4  0x000000000048b818 in ?? ()
> #5  0x000000000048a62c in ?? ()
> #6  0x000000000040d9b4 in ?? ()
> #7  0x0000000000416b62 in ?? ()
> #8  0x00000000004054e9 in ?? ()
> #9  0x0000000000405a89 in ?? ()
> #10 0x00007fdd9dea82b7 in __libc_start_call_main
> (main=main@entry=0x405a60, argc=argc@entry=103,
> argv=argv@entry=0x7ffcc7139708)
>    at ../sysdeps/nptl/libc_start_call_main.h:58
> #11 0x00007fdd9dea8375 in __libc_start_main_impl (main=0x405a60,
> argc=103, argv=0x7ffcc7139708, init=<optimized out>, fini=<optimized
> out>, rtld_fini=<optimized out>,
>    stack_end=0x7ffcc71396f8) at ../csu/libc-start.c:381
> #12 0x0000000000405bb1 in ?? ()
>
> Thanks,
>       Manuel



-- 
H.J.

Re: glibc: the x86 mem[r]chr changes cause random segfaults

[Noah Goldstein]

On Wed, Jun 8, 2022 at 11:57 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Wed, Jun 8, 2022 at 11:22 AM Manuel Lauss via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> >
> > Hi Noah,
> >
> > One of your recent x86 mem[r]chr patches to glibc causes random segfaults in
> > gcc;  I haven't nailed it down to a single patch yet, but a glibc built
> > up to commit 0218463dd8265ed937622f88ac68c7d984fe0cfc (all your
> > commits from 07th June reverted) works just fine.
> > For me it's very easy to reproduce, just rebuild glibc.
> >
> > The backtraces all look like this (sorry, no debug symbols for gcc):
> > #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> > malloc.c:3368
> > warning: Source file is more recent than executable.
> > 3368      if (chunk_is_mmapped (p))                       /* release
> > mmapped memory. */
> > (gdb) bt
> > #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> > malloc.c:3368
> > #1  0x00007fdd9debe3e0 in scratch_buffer_free (buffer=0x7ffcc7137fe0)
> > at ../include/scratch_buffer.h:86
> > #2  realpath_stk (name=<optimized out>, resolved=<optimized out>,
> > rname_buf=rname_buf@entry=0x7ffcc7137fe0) at canonicalize.c:423
> > #3  0x00007fdd9debeaff in __GI___realpath (name=<optimized out>,
> > resolved=<optimized out>) at canonicalize.c:449
>
> I suspect that rawmemchr isn't properly handled.
>

Correct. The new code changes how pointers were aligned in the page cross
case and didn't adjust rawmemchr accordingly.

> > #4  0x000000000048b818 in ?? ()
> > #5  0x000000000048a62c in ?? ()
> > #6  0x000000000040d9b4 in ?? ()
> > #7  0x0000000000416b62 in ?? ()
> > #8  0x00000000004054e9 in ?? ()
> > #9  0x0000000000405a89 in ?? ()
> > #10 0x00007fdd9dea82b7 in __libc_start_call_main
> > (main=main@entry=0x405a60, argc=argc@entry=103,
> > argv=argv@entry=0x7ffcc7139708)
> >    at ../sysdeps/nptl/libc_start_call_main.h:58
> > #11 0x00007fdd9dea8375 in __libc_start_main_impl (main=0x405a60,
> > argc=103, argv=0x7ffcc7139708, init=<optimized out>, fini=<optimized
> > out>, rtld_fini=<optimized out>,
> >    stack_end=0x7ffcc71396f8) at ../csu/libc-start.c:381
> > #12 0x0000000000405bb1 in ?? ()
> >
> > Thanks,
> >       Manuel
>
>
>
> --
> H.J.

Re: glibc: the x86 mem[r]chr changes cause random segfaults

[Dorian ROSSE]

Hello the libc alpha team,


I don't success to install glibc,

I have follow the readme but this doesn't work,

Please can you help myself the e-mail send has now one or two month I have set up some options for the building without success,

Thanks you in advance for your help,

Regards.


Dorian Rosse.
________________________________
From: Libc-alpha <libc-alpha-bounces+dorianbrice=hotmail.fr@sourceware.org> on behalf of H.J. Lu via Libc-alpha <libc-alpha@sourceware.org>
Sent: Wednesday, June 8, 2022 8:57:11 PM
To: Manuel Lauss <manuel.lauss@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: glibc: the x86 mem[r]chr changes cause random segfaults

On Wed, Jun 8, 2022 at 11:22 AM Manuel Lauss via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> Hi Noah,
>
> One of your recent x86 mem[r]chr patches to glibc causes random segfaults in
> gcc;  I haven't nailed it down to a single patch yet, but a glibc built
> up to commit 0218463dd8265ed937622f88ac68c7d984fe0cfc (all your
> commits from 07th June reverted) works just fine.
> For me it's very easy to reproduce, just rebuild glibc.
>
> The backtraces all look like this (sorry, no debug symbols for gcc):
> #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> malloc.c:3368
> warning: Source file is more recent than executable.
> 3368      if (chunk_is_mmapped (p))                       /* release
> mmapped memory. */
> (gdb) bt
> #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> malloc.c:3368
> #1  0x00007fdd9debe3e0 in scratch_buffer_free (buffer=0x7ffcc7137fe0)
> at ../include/scratch_buffer.h:86
> #2  realpath_stk (name=<optimized out>, resolved=<optimized out>,
> rname_buf=rname_buf@entry=0x7ffcc7137fe0) at canonicalize.c:423
> #3  0x00007fdd9debeaff in __GI___realpath (name=<optimized out>,
> resolved=<optimized out>) at canonicalize.c:449

I suspect that rawmemchr isn't properly handled.

> #4  0x000000000048b818 in ?? ()
> #5  0x000000000048a62c in ?? ()
> #6  0x000000000040d9b4 in ?? ()
> #7  0x0000000000416b62 in ?? ()
> #8  0x00000000004054e9 in ?? ()
> #9  0x0000000000405a89 in ?? ()
> #10 0x00007fdd9dea82b7 in __libc_start_call_main
> (main=main@entry=0x405a60, argc=argc@entry=103,
> argv=argv@entry=0x7ffcc7139708)
>    at ../sysdeps/nptl/libc_start_call_main.h:58
> #11 0x00007fdd9dea8375 in __libc_start_main_impl (main=0x405a60,
> argc=103, argv=0x7ffcc7139708, init=<optimized out>, fini=<optimized
> out>, rtld_fini=<optimized out>,
>    stack_end=0x7ffcc71396f8) at ../csu/libc-start.c:381
> #12 0x0000000000405bb1 in ?? ()
>
> Thanks,
>       Manuel



--
H.J.

Re: glibc: the x86 mem[r]chr changes cause random segfaults

[Noah Goldstein]

On Wed, Jun 8, 2022 at 12:06 PM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
>
> On Wed, Jun 8, 2022 at 11:57 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Wed, Jun 8, 2022 at 11:22 AM Manuel Lauss via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> > >
> > > Hi Noah,
> > >
> > > One of your recent x86 mem[r]chr patches to glibc causes random segfaults in
> > > gcc;  I haven't nailed it down to a single patch yet, but a glibc built
> > > up to commit 0218463dd8265ed937622f88ac68c7d984fe0cfc (all your
> > > commits from 07th June reverted) works just fine.
> > > For me it's very easy to reproduce, just rebuild glibc.
> > >
> > > The backtraces all look like this (sorry, no debug symbols for gcc):
> > > #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> > > malloc.c:3368
> > > warning: Source file is more recent than executable.
> > > 3368      if (chunk_is_mmapped (p))                       /* release
> > > mmapped memory. */
> > > (gdb) bt
> > > #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> > > malloc.c:3368
> > > #1  0x00007fdd9debe3e0 in scratch_buffer_free (buffer=0x7ffcc7137fe0)
> > > at ../include/scratch_buffer.h:86
> > > #2  realpath_stk (name=<optimized out>, resolved=<optimized out>,
> > > rname_buf=rname_buf@entry=0x7ffcc7137fe0) at canonicalize.c:423
> > > #3  0x00007fdd9debeaff in __GI___realpath (name=<optimized out>,
> > > resolved=<optimized out>) at canonicalize.c:449
> >
> > I suspect that rawmemchr isn't properly handled.
> >
>
> Correct. The new code changes how pointers were aligned in the page cross
> case and didn't adjust rawmemchr accordingly.
>

Made bugzilla and posted fix there. Testing right now:
https://sourceware.org/bugzilla/show_bug.cgi?id=29234
> > > #4  0x000000000048b818 in ?? ()
> > > #5  0x000000000048a62c in ?? ()
> > > #6  0x000000000040d9b4 in ?? ()
> > > #7  0x0000000000416b62 in ?? ()
> > > #8  0x00000000004054e9 in ?? ()
> > > #9  0x0000000000405a89 in ?? ()
> > > #10 0x00007fdd9dea82b7 in __libc_start_call_main
> > > (main=main@entry=0x405a60, argc=argc@entry=103,
> > > argv=argv@entry=0x7ffcc7139708)
> > >    at ../sysdeps/nptl/libc_start_call_main.h:58
> > > #11 0x00007fdd9dea8375 in __libc_start_main_impl (main=0x405a60,
> > > argc=103, argv=0x7ffcc7139708, init=<optimized out>, fini=<optimized
> > > out>, rtld_fini=<optimized out>,
> > >    stack_end=0x7ffcc71396f8) at ../csu/libc-start.c:381
> > > #12 0x0000000000405bb1 in ?? ()
> > >
> > > Thanks,
> > >       Manuel
> >
> >
> >
> > --
> > H.J.

Re: glibc: the x86 mem[r]chr changes cause random segfaults

[Noah Goldstein]

On Wed, Jun 8, 2022 at 12:54 PM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
>
> On Wed, Jun 8, 2022 at 12:06 PM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
> >
> > On Wed, Jun 8, 2022 at 11:57 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Wed, Jun 8, 2022 at 11:22 AM Manuel Lauss via Libc-alpha
> > > <libc-alpha@sourceware.org> wrote:
> > > >
> > > > Hi Noah,
> > > >
> > > > One of your recent x86 mem[r]chr patches to glibc causes random segfaults in
> > > > gcc;  I haven't nailed it down to a single patch yet, but a glibc built
> > > > up to commit 0218463dd8265ed937622f88ac68c7d984fe0cfc (all your
> > > > commits from 07th June reverted) works just fine.
> > > > For me it's very easy to reproduce, just rebuild glibc.
> > > >
> > > > The backtraces all look like this (sorry, no debug symbols for gcc):
> > > > #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> > > > malloc.c:3368
> > > > warning: Source file is more recent than executable.
> > > > 3368      if (chunk_is_mmapped (p))                       /* release
> > > > mmapped memory. */
> > > > (gdb) bt
> > > > #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> > > > malloc.c:3368
> > > > #1  0x00007fdd9debe3e0 in scratch_buffer_free (buffer=0x7ffcc7137fe0)
> > > > at ../include/scratch_buffer.h:86
> > > > #2  realpath_stk (name=<optimized out>, resolved=<optimized out>,
> > > > rname_buf=rname_buf@entry=0x7ffcc7137fe0) at canonicalize.c:423
> > > > #3  0x00007fdd9debeaff in __GI___realpath (name=<optimized out>,
> > > > resolved=<optimized out>) at canonicalize.c:449
> > >
> > > I suspect that rawmemchr isn't properly handled.
> > >
> >
> > Correct. The new code changes how pointers were aligned in the page cross
> > case and didn't adjust rawmemchr accordingly.
> >
>
> Made bugzilla and posted fix there. Testing right now:
> https://sourceware.org/bugzilla/show_bug.cgi?id=29234

Posted patch.
> > > > #4  0x000000000048b818 in ?? ()
> > > > #5  0x000000000048a62c in ?? ()
> > > > #6  0x000000000040d9b4 in ?? ()
> > > > #7  0x0000000000416b62 in ?? ()
> > > > #8  0x00000000004054e9 in ?? ()
> > > > #9  0x0000000000405a89 in ?? ()
> > > > #10 0x00007fdd9dea82b7 in __libc_start_call_main
> > > > (main=main@entry=0x405a60, argc=argc@entry=103,
> > > > argv=argv@entry=0x7ffcc7139708)
> > > >    at ../sysdeps/nptl/libc_start_call_main.h:58
> > > > #11 0x00007fdd9dea8375 in __libc_start_main_impl (main=0x405a60,
> > > > argc=103, argv=0x7ffcc7139708, init=<optimized out>, fini=<optimized
> > > > out>, rtld_fini=<optimized out>,
> > > >    stack_end=0x7ffcc71396f8) at ../csu/libc-start.c:381
> > > > #12 0x0000000000405bb1 in ?? ()
> > > >
> > > > Thanks,
> > > >       Manuel
> > >
> > >
> > >
> > > --
> > > H.J.

Re: glibc: the x86 mem[r]chr changes cause random segfaults

[Manuel Lauss]

On Wed, Jun 8, 2022 at 9:59 PM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
>
> On Wed, Jun 8, 2022 at 12:54 PM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
> >
> > On Wed, Jun 8, 2022 at 12:06 PM Noah Goldstein <goldstein.w.n@gmail.com> wrote:
> > >
> > > On Wed, Jun 8, 2022 at 11:57 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Wed, Jun 8, 2022 at 11:22 AM Manuel Lauss via Libc-alpha
> > > > <libc-alpha@sourceware.org> wrote:
> > > > >
> > > > > Hi Noah,
> > > > >
> > > > > One of your recent x86 mem[r]chr patches to glibc causes random segfaults in
> > > > > gcc;  I haven't nailed it down to a single patch yet, but a glibc built
> > > > > up to commit 0218463dd8265ed937622f88ac68c7d984fe0cfc (all your
> > > > > commits from 07th June reverted) works just fine.
> > > > > For me it's very easy to reproduce, just rebuild glibc.
> > > > >
> > > > > The backtraces all look like this (sorry, no debug symbols for gcc):
> > > > > #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> > > > > malloc.c:3368
> > > > > warning: Source file is more recent than executable.
> > > > > 3368      if (chunk_is_mmapped (p))                       /* release
> > > > > mmapped memory. */
> > > > > (gdb) bt
> > > > > #0  0x00007fdd9df1d36a in __GI___libc_free (mem=0x672f7ffcc7137ff0) at
> > > > > malloc.c:3368
> > > > > #1  0x00007fdd9debe3e0 in scratch_buffer_free (buffer=0x7ffcc7137fe0)
> > > > > at ../include/scratch_buffer.h:86
> > > > > #2  realpath_stk (name=<optimized out>, resolved=<optimized out>,
> > > > > rname_buf=rname_buf@entry=0x7ffcc7137fe0) at canonicalize.c:423
> > > > > #3  0x00007fdd9debeaff in __GI___realpath (name=<optimized out>,
> > > > > resolved=<optimized out>) at canonicalize.c:449
> > > >
> > > > I suspect that rawmemchr isn't properly handled.
> > > >
> > >
> > > Correct. The new code changes how pointers were aligned in the page cross
> > > case and didn't adjust rawmemchr accordingly.
> > >
> >
> > Made bugzilla and posted fix there. Testing right now:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=29234

Hello,

The patch fixes the issue for me.

Thank you!
     Manuel