Bug#277667: libc6: printf formats using parameter numbers and floats has internal error
tags 277667 confirmed fixed-upstream
thanks
At Thu, 21 Oct 2004 11:21:26 -0500,
Steve Greenland wrote:
> 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 bug should be fixed in the next glibc update.
> 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. :-)
Don't be afraid to use 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?
If you find such infinite loop will be occured after our update,
please submit another bug report.
Regards,
-- gotom
Reply to: