libuuid clock.txt fd leaks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



libuuid's gen_uuid.c:get_clock() goes to some length to try to reuse
its fd and avoid repeated opens of /var/lib/libuuid/clock.txt and also
to be thread safe.  But the current implementation must lead to fd
leakage in multithreaded applications.  This has been reported
multiple places as the gen_uuid.c file seems to have been reused in
various open source projects.  But I don't see mention of this issue
in the util-linux archives.

Some mentions I've found:
http://sourceforge.net/tracker/index.php?func=detail&aid=3276476&group_id=2406&atid=102406
https://github.com/samuel/python-gearman/pull/3
And it's come into my lap by way of some complicated Java application
I can't claim to understand, but they error on too many open files and
note via lsof that opens of clock.txt grow unbounded during their
runtime.

While googling around I also noticed the C++98 spec (well maybe
anyway...as referenced here:
http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/C_002b_002b98-Thread_002dLocal-Edits.html#C_002b_002b98-Thread_002dLocal-Edits)
includes the idea that things in TLS shouldn't have non-trivial
destructors.  Shows at least that somebody's thought about the
problem.  I'd guess having to have something know to do fclose() /
close() on parts of the TLS counts as non-trivial and shouldn't be
done.

The sourceforge.net link above includes a number of suggested options.
 And there's also just the simple implementation option for
get_clock() that doesn't have the fd as static much less TLS and
opens/closes at each invocation.  That maybe comes with a noticable
performance hit for some types of users and I don't really know the
full list of possible use cases here...do some people really need that
high performance uuid generation?  Either way, the "right" general
solution isn't immediately obvious to me so I thought I'd see what
others here thought...




Tim
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux