[Bug string/22644] New: memmove-sse2-unaligned on 32bit x86 produces garbage when crossing 2GB threshold
max at quendi dot de
sourceware-bugzilla@sourceware.org
Mon Dec 25 21:49:00 GMT 2017
https://sourceware.org/bugzilla/show_bug.cgi?id=22644
Bug ID: 22644
Summary: memmove-sse2-unaligned on 32bit x86 produces garbage
when crossing 2GB threshold
Product: glibc
Version: 2.21
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: string
Assignee: unassigned at sourceware dot org
Reporter: max at quendi dot de
Target Milestone: ---
Created attachment 10699
--> https://sourceware.org/bugzilla/attachment.cgi?id=10699&action=edit
Untested fix for memcpy-sse2-unaligned
We recently noticed some weird crashes in 32bit builds of our software when it
more than 1 GB of memory, when running on Linux. No such problems on *BSD or
Mac OS X. Also not on all Linux versions
I tracked down the cause to a bug in memmove, when moving data across the 2GB
boundary (i.e. the start of the memory region being moved is below 2^31, the
end after 2^31). This of course immediately makes one suspect a sign issue... I
wrote a minimal test case (see <https://github.com/fingolfin/memmove-bug>), and
run it on as many systems as I could get hold of. As far as I can tell, only
systems with GNU libc >= 2.21 are affected.
Looking at its release notes, I noticed that this version added
memmove-sse2-unaligned resp. memcpy-sse2-unaligned. Via a breakpoint in GDB on
memmove, I determined that on all affected systems, this was indeed using that
for the copying.
Looking closer, there are indeed a bunch of signed comparisons on memory
addresses. The attached patch, based on the master branch, attempts to fix
those, but it is completely untested, as I do not know how to compile and use
GNU libc from its sources (nor do I really want to learn how to do that, if I
can avoid it)... Anyway, even if my patch turns out to be wrong, I hope it
gives at least an indication were to start.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Glibc-bugs
mailing list