getaddrinfo not fork-safe

Bug #1966100 reported by Josh Reed
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)
New
Undecided
Unassigned

Bug Description

When compiling the following code and executing the program, the child process hangs forever on a mutex that was held by `getaddrinfo` on another thread at the time of the fork. I don't see anything in the manpage for `getaddrinfo` that suggests this shouldn't work. I suspect glibc is missing a call to `pthread_atfork`.

mre.cpp
```
#include <thread>

#include <netdb.h>
#include <unistd.h>

void spamGetaddrinfo()
{
    for (int i = 0; i< 100; ++i)
    {
        addrinfo *addrInfo{nullptr};
        ::getaddrinfo("google.com", "80", nullptr, &addrInfo);
    }
    printf("Thread is done\n");
}

int main()
{
    auto thread = std::thread{spamGetaddrinfo};

    usleep(1);

    if (auto pid = fork(); pid != 0)
    {
        // Parent
        printf("Parent is done\n");
        thread.join();
    }
    else
    {
        // Child
        addrinfo *addrInfo{nullptr};
        ::getaddrinfo("google.com", "80", nullptr, &addrInfo);

        printf("Child is done\n");
    }
}
```

Run `g++ -std=c++17 -pthread mre.cpp && ./a.out`

Expected output:
```
Parent is done
Child is done
Thread is done
```

Actual output:
```
Parent is done
Thread is done
```

When finished, use `pkill a.out` to remove the leftover child process.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: libc6 2.27-3ubuntu1.5
ProcVersionSignature: Ubuntu 4.15.0-166.174-generic 4.15.18
Uname: Linux 4.15.0-166-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.27
Architecture: amd64
Date: Wed Mar 23 10:32:43 2022
Dependencies:
 gcc-8-base 8.4.0-1ubuntu1~18.04
 libc6 2.27-3ubuntu1.5
 libgcc1 1:8.4.0-1ubuntu1~18.04
InstallationDate: Installed on 2019-12-07 (836 days ago)
InstallationMedia: Ubuntu-Server 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
ProcEnviron:
 LANG=en_US.UTF-8
 TERM=screen
 SHELL=/bin/bash
 XDG_RUNTIME_DIR=<set>
 PATH=(custom, user)
SourcePackage: glibc
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Josh Reed (reedjosh2626) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.