Description of problem:

    Perl appears to leak memory when threads are created and 
    then detached.

Version-Release number of selected component (if applicable):

    perl-5.8.8-27.el5

How reproducible:

    100%

Steps to Reproduce:
    1.  Create and run simple test program like:

        #!/usr/bin/perl

        use threads;

        my $subref = sub { 42; };

        my $t;

        while(1) {
          $t=threads->new($subref);
          $t->detach();
        }

Actual results:
 
    The test program will consume memory, seemingly without bounds.

    Running "valgrind --leak-check=full ..." on the test program
    reports bytes that are "definitely lost."

Expected results:
 
    No memory lost.  If the thread is detached, it should release its
    memory after exiting.

Additional info:

I think the root cause of the problem may be somewhere in Perl_ithread_destruct () in ext/threads/thread.xs.  Specifically, lines 137-140:

    126 /*
    127  *  free an ithread structure and any attached data if its count == 0
    128  */
    129 void
    130 Perl_ithread_destruct (pTHX_ ithread* thread, const char *why)
    131 {
    132         MUTEX_LOCK(&thread->mutex);
    133         if (!thread->next) {
    134             MUTEX_UNLOCK(&thread->mutex);
    135             Perl_croak(aTHX_ "panic: destruct destroyed thread %p (%s)",
    135 thread, why);
    136         }
    137         if (thread->count != 0) {
    138                 MUTEX_UNLOCK(&thread->mutex);
    139                 return;
    140         }
    141         MUTEX_LOCK(&create_destruct_mutex);
    142         /* Remove from circular list of threads */
    143         if (thread->next == thread) {
    144             /* last one should never get here ? */
    145             threads = NULL;
    146         }
    147         else {
    148             thread->next->prev = thread->prev;
    149             thread->prev->next = thread->next;
    150             if (threads == thread) {
    151                 threads = thread->next;
    152             }
    153             thread->next = NULL;
    154             thread->prev = NULL;
    155         }
    156         known_threads--;
    157         assert( known_threads >= 0 );
    158 #if 0
    159         Perl_warn(aTHX_ "destruct %d @ %p by %p now %d",
    160                   thread->tid,thread->interp,aTHX, known_threads);
    161 #endif
    162         MUTEX_UNLOCK(&create_destruct_mutex);
    163         /* Thread is now disowned */
    164
    165         S_ithread_clear(aTHX_ thread);
    166         MUTEX_UNLOCK(&thread->mutex);
    167         MUTEX_DESTROY(&thread->mutex);
    168 #ifdef WIN32
    169         if (thread->handle)
    170             CloseHandle(thread->handle);
    171         thread->handle = 0;
    172 #endif
    173         PerlMemShared_free(thread);
    174 }

While running the perl test program under gdb, the following was discovered:

    Starting program: /usr/bin/perl ./test2.pl
    [Thread debugging using libthread_db enabled]
    [New Thread 0x2b8a73ba0250 (LWP 1680)]
    [New Thread 0x41b64940 (LWP 1683)]
    [Switching to Thread 0x41b64940 (LWP 1683)]
   
    Breakpoint 1, Perl_ithread_destruct (my_perl=0xa0d0590, thread=0xa0ca900,
        why=0x2b8a7719f0d3 "detached finish") at threads.xs:131
    131     {
    (gdb) display thread->count
    1: thread->count = 2

    Because thread->count == 2 when the thread is destroyed,
    Perl_ithread_destruct() exits immediately and S_ithread_clear()
    (which actually cleans up the thread memory) is never called.

    I'm not sure if having thread->count == 2 when
    Perl_ithread_destruct() is called is correct or not, but it does
    seem to be preventing cleanup of the Perl thread's memory.

As a quick hack, I tried adding the following patch:

    --- perl-5.8.8.old/ext/threads/threads.xs 2009-12-15 12:02:49.940004000 -0800
    +++ perl-5.8.8.new/ext/threads/threads.xs 2009-12-15 13:06:30.493553000 -0800
    @@ -201,6 +201,11 @@
    PERL_THREAD_DETACH(thread->thr);
    #endif
        }
    +
    +    /* Make sure the thread is cleaned up after it's done */
    +    if ( thread->count > 0 )
    +       thread->count--;
    +
        if ((thread->state & PERL_ITHR_FINISHED) &&
            (thread->state & PERL_ITHR_DETACHED)) {
          MUTEX_UNLOCK(&thread->mutex);

but that resulted in the following error during the build:

    ext/threads/t/basic.......................*** glibc detected *** ./perl:
    munmap_chunk(): invalid pointer: 0x00000000097a11f0 ***
    ======= Backtrace: =========
    /lib64/libc.so.6(cfree+0x166)[0x2b0009db5856]
    /builddir/build/BUILD/perl-5.8.8/libperl.so(Perl_PerlIO_close+0x2b)[0x2b00088b97eb]
    /builddir/build/BUILD/perl-5.8.8/libperl.so(PerlIO_cleantable+0x41)[0x2b00088b9881]
    /builddir/build/BUILD/perl-5.8.8/libperl.so(PerlIO_cleanup+0x40)[0x2b00088b98f0]
    /builddir/build/BUILD/perl-5.8.8/libperl.so(perl_destruct+0xe22)[0x2b0008800492]
    ../lib/auto/threads/threads.so[0x2b000d893bcb]
    ../lib/auto/threads/threads.so(Perl_ithread_join+0x1c3)[0x2b000d893de3]
    ../lib/auto/threads/threads.so(XS_threads_join+0x73)[0x2b000d893f13]
    /builddir/build/BUILD/perl-5.8.8/libperl.so(Perl_pp_entersub+0x3f6)[0x2b0008857a96]
    /builddir/build/BUILD/perl-5.8.8/libperl.so(Perl_runops_standard+0xe)[0x2b000885133e]
    /builddir/build/BUILD/perl-5.8.8/libperl.so(perl_run+0x30a)[0x2b00087ff08a]
    ./perl(main+0xfc)[0x4017bc]
    /lib64/libc.so.6(__libc_start_main+0xf4)[0x2b0009d60994]
    ./perl[0x401609]

There are reports of problems like this upstream:

    http://rt.perl.org/rt3/Public/Bug/Display.html?id=40416
    http://rt.perl.org/rt3/Public/Bug/Display.html?id=37134

These seem to have been resolved in the latest version of perl, but the upstream threading code seems to be significantly different, so I'm not sure exactly what changed to fix this.

This can be worked around by explicitly undef-ing the thread variable in the loop, but another problem, as described in Bug 537777, is preventing this.