]> CyberLeo.Net >> Repos - FreeBSD/stable/8.git/commit
MFC 220888
authorrstone <rstone@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Fri, 11 Nov 2011 02:10:24 +0000 (02:10 +0000)
committerrstone <rstone@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Fri, 11 Nov 2011 02:10:24 +0000 (02:10 +0000)
commita82e6c0f6dea14e07f726c4fb643459eecac6610
treebfbde05eb8979b2bfa0d5519fa657c8bb255eed4
parent2e5a8f31ee76be9085417ad7e0cc7c20e0bcb45d
MFC 220888

 r179417 introduced a bug into pthread_once().  Previously pthread_once()
 used a global pthread_mutex_t for synchronization.  r179417 replaced that
 with an implementation that directly used atomic instructions and thr_*
 syscalls to synchronize callers to pthread_once.  However, calling
 pthread_mutex_lock on the global mutex implicitly ensured that
 _thr_check_init() had been called but with r179417 this was no longer
 guaranteed.  This meant that if you were unlucky enough to have your first
 call into libthr be a call to pthread_once(), you would segfault when
 trying to access the pointer returned by _get_curthread().

 The fix is to explicitly call _thr_check_init() from pthread_once().

git-svn-id: svn://svn.freebsd.org/base/stable/8@227438 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
lib/libthr/thread/thr_once.c