* glibc: the x86 mem[r]chr changes cause random segfaults
@ 2022-06-08 18:21 Manuel Lauss
2022-06-08 18:57 ` H.J. Lu
0 siblings, 1 reply; 7+ messages in thread
From: Manuel Lauss @ 2022-06-08 18:21 UTC (permalink / raw)
To: Noah Goldstein, libc-alpha
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: glibc: the x86 mem[r]chr changes cause random segfaults
2022-06-08 18:21 glibc: the x86 mem[r]chr changes cause random segfaults Manuel Lauss
@ 2022-06-08 18:57 ` H.J. Lu
2022-06-08 19:06 ` Noah Goldstein
2022-06-08 19:40 ` Dorian ROSSE
0 siblings, 2 replies; 7+ messages in thread
From: H.J. Lu @ 2022-06-08 18:57 UTC (permalink / raw)
To: Manuel Lauss; +Cc: Noah Goldstein, GNU C Library
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: glibc: the x86 mem[r]chr changes cause random segfaults
2022-06-08 18:57 ` H.J. Lu
@ 2022-06-08 19:06 ` Noah Goldstein
2022-06-08 19:54 ` Noah Goldstein
2022-06-08 19:40 ` Dorian ROSSE
1 sibling, 1 reply; 7+ messages in thread
From: Noah Goldstein @ 2022-06-08 19:06 UTC (permalink / raw)
To: H.J. Lu; +Cc: Manuel Lauss, GNU C Library
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: glibc: the x86 mem[r]chr changes cause random segfaults
2022-06-08 19:06 ` Noah Goldstein
@ 2022-06-08 19:54 ` Noah Goldstein
2022-06-08 19:58 ` Noah Goldstein
0 siblings, 1 reply; 7+ messages in thread
From: Noah Goldstein @ 2022-06-08 19:54 UTC (permalink / raw)
To: H.J. Lu; +Cc: Manuel Lauss, GNU C Library
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: glibc: the x86 mem[r]chr changes cause random segfaults
2022-06-08 19:54 ` Noah Goldstein
@ 2022-06-08 19:58 ` Noah Goldstein
2022-06-08 20:14 ` Manuel Lauss
0 siblings, 1 reply; 7+ messages in thread
From: Noah Goldstein @ 2022-06-08 19:58 UTC (permalink / raw)
To: H.J. Lu; +Cc: Manuel Lauss, GNU C Library
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: glibc: the x86 mem[r]chr changes cause random segfaults
2022-06-08 19:58 ` Noah Goldstein
@ 2022-06-08 20:14 ` Manuel Lauss
0 siblings, 0 replies; 7+ messages in thread
From: Manuel Lauss @ 2022-06-08 20:14 UTC (permalink / raw)
To: Noah Goldstein; +Cc: H.J. Lu, GNU C Library
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: glibc: the x86 mem[r]chr changes cause random segfaults
2022-06-08 18:57 ` H.J. Lu
2022-06-08 19:06 ` Noah Goldstein
@ 2022-06-08 19:40 ` Dorian ROSSE
1 sibling, 0 replies; 7+ messages in thread
From: Dorian ROSSE @ 2022-06-08 19:40 UTC (permalink / raw)
To: H.J. Lu, Manuel Lauss; +Cc: GNU C Library
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-06-08 20:15 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-08 18:21 glibc: the x86 mem[r]chr changes cause random segfaults Manuel Lauss
2022-06-08 18:57 ` H.J. Lu
2022-06-08 19:06 ` Noah Goldstein
2022-06-08 19:54 ` Noah Goldstein
2022-06-08 19:58 ` Noah Goldstein
2022-06-08 20:14 ` Manuel Lauss
2022-06-08 19:40 ` Dorian ROSSE
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).