aboutsummaryrefslogtreecommitdiff
path: root/lib/libgssapi/gss_process_context_token.c
diff options
context:
space:
mode:
authorPeter Wemm <peter@FreeBSD.org>2008-12-07 02:32:49 +0000
committerPeter Wemm <peter@FreeBSD.org>2008-12-07 02:32:49 +0000
commit70ba1e8fc192b8d7e85bcf0869bfe0254bd1ef4d (patch)
tree24ec6a1e099529415de6cce28a2cc94f628bcd9a /lib/libgssapi/gss_process_context_token.c
parent1af2e19172eb1621ff027ee3fdc91909ec253485 (diff)
downloadsrc-70ba1e8fc192b8d7e85bcf0869bfe0254bd1ef4d.tar.gz
src-70ba1e8fc192b8d7e85bcf0869bfe0254bd1ef4d.zip
When libthr and rtld start up, there are a number of magic spells cast
in order to get the symbol binding state "just so". This is to allow locking to be activated and not run into recursion problems later. However, one of the magic bits involves an explicit call to _umtx_op() to force symbol resolution. It does a wakeup operation on a fake, uninitialized (ie: random contents) umtx. Since libthr isn't active, this is harmless. Nothing can match the random wakeup. However, valgrind finds this and is not amused. Normally I'd just write a suppression record for it, but the idea of passing random args to syscalls (on purpose) just doesn't feel right.
Notes
Notes: svn path=/head/; revision=185728
Diffstat (limited to 'lib/libgssapi/gss_process_context_token.c')
0 files changed, 0 insertions, 0 deletions