This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/21182] segfaults with glibc-2.25 on i686


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]