This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/21182] segfaults with glibc-2.25 on i686
- From: "leah at vuxu dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 27 Feb 2017 07:37:09 +0000
- Subject: [Bug libc/21182] segfaults with glibc-2.25 on i686
- Auto-submitted: auto-generated
- References: <bug-21182-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21182
--- Comment #6 from Leah Neukirchen <leah at vuxu dot org> ---
(In reply to Florian Weimer from comment #5)
> (In reply to Leah Neukirchen from comment #4)
> > I could reproduce this on Linux 4.4.6 with glibc 2.25 and gcc 6.3.0 directly
> > running on i686 "Intel(R) Atom(TM) CPU N270 @ 1.60GHz" (no PAE, 1G RAM).
> >
> > Please consider the test case I just added. As you can see, addresses which
> > are less than 16 bytes off the end will result in searching pages behind the
> > buffer and make memchr return pointers outside of the area.
>
> I wasn't able to get access to an Atom N270 machine so far. We need to
> single-step through the new code and see what happens to the register
> contents, to find the root cause of this bug. So unless you can do that
> (comparing it with a working i386 machine), or someone can provide remote
> shell access to such a machine, we are stuck.
I realized the machines where it works all use __memchr_sse2_bsf, but
I couldn't yet figure out how to force them to use __memchr_sse2 instead,
to make such a comparison trace.
Is there a trick to override the ifunc selection?
It would be nice if you could update the bug description to
"__memchr_sse2: regression in glibc-2.25 on i686"
or something, perhaps other people can find it easier then.
--
You are receiving this mail because:
You are on the CC list for the bug.