A commercial application (Cadence) that runs with an older libc gives
incorrect results with the current libc. I've tracked down the
problem to strcpy. If I make my own strcopy, following the template of
https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38, the tool gives
correct results. Here is mystrcpy.c:
$ cat mystrcpy.c
char *strcpy(char *dest, const char *src){
char *destcopy=dest;
while(*dest++ = *src++)
;
return destcopy;
}
I've traced through the application and see that it
is calling strcpy with overlapping source and destination,
and that the execution goes through __strcpy_ssse3,
which seems to cause the problem.
I made a small testcase to replicate the behavior.
Following http://forums.gentoo.org/viewtopic-t-840983-start-0.html,
here is my test case:
------------
$ cat strcopytest.c
char *strcpy(char *,char *);
int main(){
char buf[80];
strcpy(buf, "012345678\n");
strcpy(buf, buf+1);
puts(buf);
return 0;
}
$ gcc -O2 -c mystrcpy.c
$ ld -G mystrcpy.o -o mystrcpy.so
$ gcc strcopytest.c -o strcopytest
$ ./strcopytest
12345688
$ LD_PRELOAD=./mystrcpy.so ./strcopytest
12345678
----------------
I know that I can make my testcase work with #include "string.h",
but the I cannot recompile the commercial application, so that's not
a workable solution.
ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: libc6 2.13-0ubuntu13
ProcVersionSignature: Ubuntu 2.6.39-3.10-generic 2.6.39
Uname: Linux 2.6.39-3-generic x86_64
Architecture: amd64
Date: Thu Jul 14 13:43:36 2011
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100317.1)
ProcEnviron:
LANGUAGE=en_US:en
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: eglibc
UpgradeStatus: Upgraded to natty on 2011-04-29 (76 days ago)
Status changed to 'Confirmed' because the bug affects multiple users.