On 10/05/2013 12:30 PM, Michael Stone wrote: > On Sat, Oct 05, 2013 at 10:21:55AM -0700, you wrote: >> I'd like to ask if there is any updates on this bug. > > I see a big downside in potential complexity and fragility for the > system without much upside. The only use case cited ended up being a > library problem rather than a coreutils problem. Is there a better use > case which would suggest that there's a good benefit to doing this?
Well, just today I found valgrind is reporting a "points to uninitialised byte" and "definitely lost: 8 bytes in 1 blocks" in the timeout tool. Without -dbg, this is what I get in valgrind: ==32492== Syscall param timer_create(evp) points to uninitialised byte(s) ==32492== at 0x4E36E1A: timer_create@@GLIBC_2.3.3 (timer_create.c:83) ==32492== by 0x402607: ??? (in /usr/bin/timeout) ==32492== by 0x4022C5: ??? (in /usr/bin/timeout) ==32492== by 0x5278994: (below main) (libc-start.c:260) ==32492== Address 0x7fefffe80 is on thread 1's stack ... which is useless to the devs (or even me, if I wanted to try fixing it out). Otherwise, "valgrind --leak-check=full timeout 30 ./app-to-test" will always give me false positives that don't even have to do with app-to-test. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
