posixのtimer_create関数内で確保されるメモリはどのように解放するのか

Question

表題の件につきましてお尋ねしたいです。

POSIXのtimer_create関数を使用すると、valgrindでメモリリークを検知してしまいます。検知を抑制すれば済む問題ではあるのですが、timer_create関数のソースコードを見ると、timer_create関数から作成されているヘルパー関数のスレッドが終了しないということが原因になっているように思います。
メモリリークしていないのかもしれないのですが、timer_create関数内で生成されたスレッドは終わらないのがデフォルトの挙動という理解でよいのでしょうか？

• timer_create
• ヘルパー関数

以下のコードをvalgirnd経由で実行すると、下部に記載するメモリのサマリが表示されます。

#include <inttypes.h>
#include <pthread.h>
#include <signal.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

const struct itimerspec its = { .it_value = { 1 } };
const struct timespec ts = { 3 };

void notifyFunc(union sigval sv)
{
        printf("notifyfunc: timer has expired.\n");
}

int main(void)
{
        struct sigevent se;
        struct sigaction sa;
        timer_t timerid_thread;
        timer_t timerid_signal;

        memset(&se, 0, sizeof(se));
        se.sigev_value.sival_int = 1;
        se.sigev_notify = SIGEV_THREAD;
        se.sigev_notify_function = notifyFunc;
        se.sigev_notify_attributes = NULL;
        timer_create(CLOCK_REALTIME, &se, &timerid_thread);
        timer_settime(timerid_thread, 0, &its, NULL);

        nanosleep(&ts, NULL);

        int res;
        res = timer_delete(timerid_thread);
        printf("TIMER_DELETE RES: %d\n", res);

        return 0;
}

valgrindのサマリ

==28846== HEAP SUMMARY:
==28846==     in use at exit: 272 bytes in 1 blocks
==28846==   total heap usage: 10 allocs, 9 frees, 3,366 bytes allocated
==28846==
==28846== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==28846==    at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28846==    by 0x40134F6: allocate_dtv (dl-tls.c:286)
==28846==    by 0x40134F6: _dl_allocate_tls (dl-tls.c:530)
==28846==    by 0x504C227: allocate_stack (allocatestack.c:627)
==28846==    by 0x504C227: pthread_create@@GLIBC_2.2.5 (pthread_create.c:644)
==28846==    by 0x4E4151A: __start_helper_thread (timer_routines.c:176)
==28846==    by 0x5053826: __pthread_once_slow (pthread_once.c:116)
==28846==    by 0x4E403BA: timer_create@@GLIBC_2.3.3 (timer_create.c:101)
==28846==    by 0x1089C6: main (in /home/xxx/sample/sample_timer_2)
==28846==
==28846== LEAK SUMMARY:
==28846==    definitely lost: 0 bytes in 0 blocks
==28846==    indirectly lost: 0 bytes in 0 blocks
==28846==      possibly lost: 272 bytes in 1 blocks
==28846==    still reachable: 0 bytes in 0 blocks
==28846==         suppressed: 0 bytes in 0 blocks

上記に表示されているスレッドはメインの処理が終わった後も残り続けているのだと思うのですが、問題ないのでしょうか？
ご教示いただけますと幸いです。よろしくお願いいたします。

Answer 1

同じ状況を検証できる環境にないので推測での回答ですが、time_create()で登録するハンドラーは、pthread_exit()で終了させるものではないように思います。Pthreads(POSIXスレッド)とは少しカテゴリが違う関数群のはずです。

pthread_exit()の呼び出しを止めてみたら状況が変わりませんでしょうか。

void notifyFunc(union sigval sv)
{
    printf("notifyfunc: timer has expired.\n");

/*
    pthread_exit(NULL);
*/
}

Comments

[dodox86]

表題の「posixのtimer_create関数内で確保されるメモリはどのように解放するのか」を解決する回答ではありませんが、使っているコードに問題があるのではないか、と言う視点から回答させていただきました。

[Ykkykk]

ご回答いただきありがとうございます。
そちらのpthread_exitはもともとつけていなかったのですが、ハンドラー関数のスレッドが終わってないのかと思いつけてみていました。
このpthread_exitがなくてもあってもvalgrindで表示されるメモリリークは同じなのです。。。
timer_create関数の中でヘルパー関数が別のスレッドとして起動されており、そちらの関数を止めることができていない形です。
ご回答いただきありがとうございます！

[Ykkykk]

上記のご指摘を本文に反映いたしました。

[dodox86]

> そちらのpthread_exitはもともとつけていなかったのですが、ハンドラー関数のスレッドが終わってないのかと思いつけてみていました。

なるほど、そうだったのですね。もしLinux下での実行なのであれば、Ptheradライブラリで扱われるLinuxのスレッドはcloneシステムコールで生成される同じメモリを共有するプロセスなので、main()が終わってもcloneされたスレッド側の何かが残っているのかもしれませんね。引き続き有識者の方からの回答をお待ちいただければと思います。お役に立てずすみません。

[Ykkykk]

いえ、むしろお忙しいところご回答いただきありがとうございます！
Ubuntuで実行しているのでおっしゃっているようにメイン関数終了後にも恐らくですがヘルパー関数のスレッド自体が残ってしまっているのだと思います。。。
何はともあれ、ご回答いただきありがとうございました！