This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/13540] Bug in ssse3 strcpy, strncpy, stpncpy, stpcpy, strcat, strncat
- From: "liubov.dmitrieva at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Fri, 23 Dec 2011 11:21:50 +0000
- Subject: [Bug libc/13540] Bug in ssse3 strcpy, strncpy, stpncpy, stpcpy, strcat, strncat
- Auto-submitted: auto-generated
- References: <bug-13540-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13540
--- Comment #7 from Liubov Dmitrieva <liubov.dmitrieva at gmail dot com> 2011-12-23 11:21:50 UTC ---
I regret this bug wasn't caught earlier.
It's too early to think this bug to be fixed.
The bug is wide spread in glibc string routines.
I've sent a patch with wcscpy fix (for x86_32) today additionally to my
yesterday patch which fixes strcpy/pcpy, strncpy/pncpy, strcat/ncat.
But that was only work regarding with x86_64 string routines.
But the same issue exists for x86_64 routines.
Yes, my attached test1 has good recall in 32bit mode but doesn't catch anything
in 64 bit mode.
Unfortunately I don't have any reproducer for 64bit mode now, I think it can be
two thread application where one thread calls string copy routines, the second
thread keeps some char variable very closed to a buffer the first thread uses.
The second thread should update variable and check if the first thread doesn't
load a char before update and restore it after. Test should change lengths,
alignments since the bug exists only for restricted cases.
I'm going to work with patches for x86_64 ASAP. An algorithm shall be modified
in similar files: strpy-ssse3.S and wcscpy-ssse3.S
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.