Package: libc6 Version: 2.11.1-1 Severity: important On amd64, one specific program behaves differently when run with libc6 2.10.2-9 (or earlier) than when run with libc6 2.11.1-1 (or later). So this smells like it could be either a libc6 backwards binary compatibility bug to me, or plainly a bug somewhere in eglibc. I suppose it is also possible that the program makes an invalid (not guaranteed) assumption and (e)glibc 2.11 changed something that breaks that assumption. The incorrect behaviour does not occur with the i386 version of the program, even with newer libc6. Neither on a full i386 Debian GNU/Linux, nor with the i386 version of the program installed on an amd64 Debian GNU/Linux with "--force-architecture" and ia32-libs.
The program is Symantec's Backup Exec Remote Agent for Linux and UNIX Servers, versions 2010R2 (13.0.4164) and 2010R3 (13.0.5204); hereafter called "beremote". Alas, it is proprietary and all that, so precise debugging and testing is rather complicated. In particular, I don't know if a recompile and/or relink against newer headers / libraries would "fix" the program's behaviour or not. The incorrect behaviour is that in the backup, many directory names are mangled and/or duplicated. For example, /boot is split between /boot and /bott, and /boot/grub becomes /boot/guub. Filenames seem to be OK. I've run beremote under various variants of gdb, strace, ltrace and latrace, but I haven't been able to pinpoint a specific call to a libc function that returns a wrong result. All I see is that beremote does readdir(), and then the directory name (e.g. "boot") reappears mangled (e.g. "bott") in a call to wmemcpy. I would appreciate detailed instructions on how to better pinpoint it: as l(a)trace does not support *wchar_t strings, but gdb (sid version) does, I've been mainly using gdb breakpoints to look at what happens (after installing libc6-dbg), but that is rather onerous and it shows me only the libc functions I thought to put a breakpoint on, not all calls like l(a)trace would. I can send you the strace, ltrace and latrace outputs if it is useful. I've started from a lenny system: problem does not appear. Upgraded kernel to squeeze version, problem does not appear. Upgraded libc6 to squeeze, problem appears. I started taking versions from snapshot.debian.org until I found that problem appears with 2.11.1-1, but not 2.10.2-9. So it looks like a 2.10 vs 2.11 thing. I vaguely looked at the NEWS file and diff of source code between those versions, the only thing that struck my eye is: * New optimized string functions for x86-64: strstr, strcasestr, memcmp, strcspn, strpbrk, strspn, strcpy, stpcpy, strncpy, strcmp (SSE2, SSE4.2), strncmp (SSE2, SSE4.2), strchr (SSE4.2), strrchr (SSE4.2). Contributed by H.J. Lu. strlen, rawmemchr, strcmp (SSSE3), strncmp (SSSE3). Implemented by Ulrich Drepper. But I think that if these functions were buggy, we would have noticed! So, unlikely. -- System Information: Versions of packages libc6 depends on: ii libc-bin 2.11.1-1 Embedded GNU C Library: Binaries ii libgcc1 1:4.3.2-1.1 GCC support library -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
