__gettimeofday visibility and sem_timedwait

[Maciek Borzecki <maciek dot borzecki at gmail dot com>]

Hi all,

I've been chasing a stragen issue in our code where sem_timedwait
would hang indefinitely. Going down in the stack to the futex call, I
found that the timeout value for FUTEX_WAIT was surprisingly large (in
the range of current time, as returned from gettimeofday). Eventually,
the problem was traced back to one of our internal libraries which
went through some cleanups recently. As it turned out, the library
defined __gettimeofday symbol and a missing static was not spotted
during review.
Obvious error as it is, the effect it had on nptl were quite
interesting. As sem_timedwait does refer __gettimeofday, which in turn
is defined in libc, but that happens to be resolved only after our
libraries got loaded, sem_timedwait woudl effectively call our code.
Given that the declarations were compatible (same return value, same
args), everything remained fine, aside from the timeout being in the
range of ~40years (our function used CLOCK_REALTIME to read curren
time, which starts counting from 0 upon system startup - Linux 3.x).

Now it got me thinking wherther, lpthread should actually refer
__gettimeofday from libc, and wouldn't it be better if it was
reimplemented in lpthread. I'm not saying that it's wrong, merely
indicating that it's easy to break things accidentally. There's
obviously no excuse for missing static in our library, yet I wonder
how often such errors pop up. Quick readelf -s /lib/libc-2.14.90.so? |
egrep 'FUNC.*GLOBAL' | awk '/__[a-z_]+$/ {print $8}'? | wc -l shows
~390 symbols. Given how frequently '__' prefix is used I can imagine
someone wrapping a libc symbol and breaking stuff.
It seems that the namespace of libc symbols may not be isolated
enough, but I'm obviously not an expert here.

--
Maciek Borzecki