Bug#645592: libc6: 2.11 (maybe?) breaks backwards (binary) compatibility
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
Reply to: