rust --version may trip a pthreads assertion

[alexcrichton]

$ gdb --args rust --version
(gdb) r
Starting program: /Users/alex/code/rust/bin/rust --version
/Users/alex/code/rust/bin/rust 0.8-pre (578e680 2013-08-27 19:35:44 -0700)
host: x86_64-apple-darwin
pthread_mutex_lock(&_mutex) failed in src/rt/sync/lock_and_signal.cpp at line 79, result = 22 (Invalid argument) 

Program received signal SIGABRT, Aborted.
[Switching to process 27750 thread 0x4b03]
0x00007fff81171212 in __pthread_kill ()
(gdb) bt
#0  0x00007fff81171212 in __pthread_kill ()
#1  0x00007fff8d110b54 in pthread_kill ()
#2  0x00007fff8d154dce in abort ()
#3  0x00000001032389a9 in lock_and_signal::lock (this=<value temporarily unavailable, due to optimizations>) at lock_and_signal.cpp:79
#4  0x00000001032393b2 in rust_initialize_rt_tls_key (key=0x4b03) at rust_builtin.cpp:462
#5  0x00000001000770d3 in rt::sched::__extensions__::meth_23615::bootstrap::_1eead8453d4ed64c::_0$x2e8$x2dpre ()
#6  0x00007fff8d10f7a2 in _pthread_start ()
#7  0x00007fff8d0fc1e1 in thread_start ()
(gdb) The program is running.  Exit anyway? (y or n) n
Not confirmed.
(gdb) info threads
* 17                         0x00007fff81171212 in __pthread_kill ()
  16                         0x00007fff81171d16 in kevent ()
  15                         0x00007fff81171d16 in kevent ()
  14                         0x00007fff81171d16 in kevent ()
  13                         0x00007fff81171d16 in kevent ()
  12                         0x00007fff81171d16 in kevent ()
  11                         0x00007fff81171d16 in kevent ()
  10                         0x00007fff8d110284 in pthread_threadid_np ()
   9                         0x00007fff8116f686 in mach_msg_trap ()
   8                         0x00007fff8116f686 in mach_msg_trap ()
   7                         0x00007fff8116f686 in mach_msg_trap ()
   6                         0x00007fff8116f686 in mach_msg_trap ()
   5                         0x00007fff8116f686 in mach_msg_trap ()
   4                         0x00007fff8116f686 in mach_msg_trap ()
   3                         0x00007fff8116f686 in mach_msg_trap ()
   2                         0x00007fff8116f686 in mach_msg_trap ()
   1 "com.apple.main-thread" 0x00007fff81171386 in __semwait_signal ()
(gdb)                                                                                                                                                   

There's a few interesting things going on here. First, why does rust spawn 17 threads for a simple program which will immediately return? Second, it seems odd that we're tripping the assertion in the first place...

cc @brson

[alexcrichton]

To reproduce, I just kept running rust --version until I got the assertion failure.

[klutzy]

newrt's start() creates a number of threads and passes main() to one of them. (src/libstd/rt/mod.rs#L360)

[alexcrichton]

It's unfortunate though because 17 seems like a lot... I could just be worrying about nothing though

[indirect]

I am seeing this about 50-70% of the time I run rust --version with rust 0.8-pre (2ba36ec 2013-08-10 07:47:14 -0700) host: x86_64-apple-darwin.

[brson]

I'm guessing this is an 8 core machine, so there is the main thread, 8 scheduler threads, and 8 mystery threads. on OS X libuv was creating an extra thread per event loop, but I thought that was fixed in #8407.

[alexcrichton]

@brson, looking in gdb now on the same machine, there are only 9 threads. This may have been in the interim period where I just had a bad rustc.

Regardless, 9 seems more appropriate (1 per core).

[alexcrichton]

I believe that this was fixed in #9480 and superseded by #9473

[thestinger]

Yup, I can confirm that this is now fixed on Linux.