Memory leak in src/runtime/thread.c:create_thread_struct()

[Stelian Ionescu]

Compiling 1.3.0.91-f9db2f1 under AddressSanitizer(https://github.com/google/sanitizers) shows an apparent memory leak.
I'll try to investigate this as soon as possible, and I'm open to ideas.

==624611==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 56 byte(s) in 1 object(s) allocated from:
    #0 0x4d85fb in __interceptor_malloc third_party/llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:52:3
    #1 0x4fdaa6 in create_thread_struct /tmp/sbcldCmjaECERB/src/src/runtime/thread.c:726
    #2 0x4fe42b in create_initial_thread /tmp/sbcldCmjaECERB/src/src/runtime/thread.c:844
    #3 0x4241fb in main /tmp/sbcldCmjaECERB/src/src/runtime/runtime.c:732
    #4 0x7ffff710fce7 in __libc_start_main (/usr/grte/v4/lib64/libc.so.6+0x38ce7)
    #5 0x42d5c8 in _start /usr/grte/v4/debug-src/glibc-2.19/csu/../sysdeps/x86_64/start.S:108

[Christophe Rhodes (csr21-cantab)]

Has this been sorted out by the various changes since? We are more careful about allocation of the pthread_addr_t field which appeared to cause this.

[Stas Boukarev (stassats)]

I don't think there was actually a leak there, I remember creating lots of threads and the heap didn't grow.

[Christophe Rhodes (csr21-cantab)]

I also think the leak detected was a mostly false positive: I think it is (was?) an artifact of the initial_thread_trampoline never returning. If the analyser didn't know that, it might look like a leak.