Bug#277667: libc6: printf formats using parameter numbers and floats has internal error
Package: libc6
Version: 2.3.2.ds1-16
Severity: normal
There seems to be a problem when using printf() format specifies that
combine paramenter number specification and floating point values, e.g.
"%1$3.2f".
Consider this code:
#include <stdio.h>
int main(void)
{
int d= 5;
int h = 7;
double x= 3.2;
printf(" Okay: float: %4.1f, int: %4d\n", x, d);
printf(" Okay: int: %1$4d, int: %2$4d\n", h, d);
printf("Problem: float: %1$4.1f, int: %2$4d\n", x, d);
return 0;
}
Compiled and run under valgrind, you get this output:
==18169== Memcheck, a memory error detector for x86-linux.
==18169== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==18169== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==18169== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==18169== For more details, rerun with: -v
==18169==
Okay: float: 3.2, int: 5
Okay: int: 7, int: 5
==18169== Conditional jump or move depends on uninitialised value(s)
==18169== at 0x1B9641E9: __printf_fp (in /lib/libc-2.3.2.so)
==18169== by 0x1B961A6B: _IO_vfprintf (in /lib/libc-2.3.2.so)
==18169== by 0x1B9688D1: _IO_printf (in /lib/libc-2.3.2.so)
==18169== by 0x8048465: main (in /home/steveg/src/testsyslog)
Problem: float: 3.2, int: 5
==18169==
==18169== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 11 from 1)
==18169== malloc/free: in use at exit: 0 bytes in 0 blocks.
==18169== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==18169== For a detailed leak analysis, rerun with: --leak-check=yes
==18169== For counts of detected errors, rerun with: -v
This is almost certainly an upstream problem, as I get identical (well,
different addresses) results on RHEL 3.0, but if I report it to you, I
don't have to fight bugzilla. :-)
I realize this is fairly obscure, but I found this while trying to track
down why a particular program would (very rarely) go into an infinite
loop *after* exit(), deep down in the libc cleanup routines. Presumably
*something* was stomping on internal memory. This might be it. Or not.
In any case, worth fixing eventually, yes?
Steve
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (800, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-686
Locale: LANG=C, LC_CTYPE=C (ignored: LC_ALL set to C)
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7 The Berkeley database routines [gl
-- no debconf information
Reply to: