[PATCH] pthread_detach: add a comment about a known segfault bug.

[Paul Pluzhnikov]

On Wed, Nov 26, 2025 at 3:11 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Paul Pluzhnikov:
>
> > The pthread_detach errors seem to indicate a separate bug :-(
>
> I'm not sure?  If there is a synchronization defect, who knows what ends
> up at the address where struct pthread is stored?

I thought the race window started inside the call to pthread_detach
and thus pthread_detach itself should always succeed, but I could well
be wrong (and I haven't looked at the proposed fix yet).

> The trick to make the test start a new iteration triggers the EINVAL
> failure much more frequently:
>
> error: xpthread_check_return.c:32: pthread_detach: Invalid argument
> *** stack smashing detected ***: terminated

What is your observed failure rate?

I modified the test to run 1,000,000 iterations, also changed it to
not sleep when there are no remaining tasks, and ran 20 instances of
that binary overnight (with --direct to avoid timeout) on a single
machine against the ToT GLIBC build.
None of them crashed, and they reached 400,000+ iterations.

> /* Returns the number of threads in this process, by counting the
>    entries in /proc/self/task.  */
> static int
> current_thread_count (void)
> {
>   DIR *tasks = xopendir ("/proc/self/task");
>   int count = 0;
>   struct dirent *d;
>   while ((d = xreaddir (tasks)) != NULL)
>     if (d->d_name[0] != '.')
>       ++count;
>   xclosedir (tasks);
>   return count;
> }

I did that part as:

static int
ntasks (void)
{
  struct stat st_buf;
  xstat ("/proc/self/task", &st_buf);
  return st_buf.st_nlink - 2;
}


-- 
Paul Pluzhnikov