threads/163512: libc defaults to single threaded

[Steven Wills]

>Number:         163512
>Category:       threads
>Synopsis:       libc defaults to single threaded
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-threads
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec 21 19:10:09 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Steven Wills
>Release:        
>Organization:
>Environment:
>Description:
1) libc defaults to being single-threaded
2) thus apps not linked against libthr don't initialize the structures that threading depends on
3) this causes bugs when said app loads a library that loads libthr
4) said library will take the threaded code path and reference uninitialized data structures

An example of this can be seen by removing ports/devel/p5-Glib2/files/patch-threadstest then after building, run "make test" from work/Glib-1.241. Perl will hang in state umtxn.

I believe this may also be the source of an intermittent hang in automoc4 (also stuck in state umtxn) seen while building x11/kde4. This was discussed here:

http://mail.kde.org/pipermail/kde-freebsd/2011-November/012211.html
https://bugs.kde.org/show_bug.cgi?id=276461


>How-To-Repeat:
1. update ports tree
2. Ensure perl is not build with threads (currently not building with threads is the default)
2. cd /usr/ports/devel/p5-Glib2
3. rm files/patch-threadstest
4. make
5. cd work/Glib-1.241
6. make test
7. Verify perl is hung trying to run t/9.t
>Fix:
I'm told merging libthr into libc may help, but I'm not really sure. No ideas beyond that.

>Release-Note:
>Audit-Trail:
>Unformatted: