NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.47k stars 13.66k forks source link

proj.x86_64-darwin build failing #142875

Closed bdj closed 2 years ago

bdj commented 2 years ago

Describe the bug

https://hydra.nixos.org/job/nixpkgs/trunk/proj.x86_64-darwin

The build is failing on darwin since the update to 8.1.1 (https://github.com/NixOS/nixpkgs/pull/138479)

Notify maintainers

@dotlambda @vbgl

dotlambda commented 2 years ago

@bdj Can you check whether adding

preCheck = ''
  export TMPDIR="/tmp"
'';

makes at least one of the two failing tests pass?

Artturin commented 2 years ago

this is the tempfile creation logic in proj_context_test.cpp

static std::string createTempDict(std::string &dirname, const char *filename) {
    const char *temp_dir = getenv("TEMP");
    if (!temp_dir) {
        temp_dir = getenv("TMP");
    }
#ifndef WIN32
    if (!temp_dir) {
        temp_dir = "/tmp";
    }
#endif
    if (!temp_dir)
        return std::string();

    dirname = temp_dir;

    std::string tmpFilename;
    tmpFilename = temp_dir;
    tmpFilename += DIR_CHAR;
    tmpFilename += filename;

    return createTmpFile(tmpFilename) ? tmpFilename : std::string();
}
risicle commented 2 years ago

I can't reproduce the failure on macos 10.15

risicle commented 2 years ago

I think we agreed in chat that we should disable these specific tests on darwin because none of us can reproduce this failure outside hydra, so I'm going to prepare a PR to do that but I think we need to keep this issue open until that has gone through and we can check that hydra's output is identical to our own builds. Otherwise we could be missing the fact that it's a genuinely broken output that's being built on hydra rather than just a dodgy test going wrong on hydra.

veprbl commented 2 years ago

I can reproduce failure on Mojave

r-burns commented 2 years ago

Oh, maybe that's it? I can't reproduce on catalina, and I've seen failures for other packages which are due to the builders using mojave.

toonn commented 2 years ago

I've been looking into this and it's because of a hardcoded assumption on the number of allowed open file descriptors on Linux AFAICT. On macOS the limit used to be 256 instead of Linux's 1024, don't know whether that changed.

veprbl commented 2 years ago

Do we have enough information to report the issue upstream? https://github.com/OSGeo/PROJ/issues

toonn commented 2 years ago

I'm looking into this. OPEN_MAX from stdio.h is the canonical source of the maximum number of file descriptors that can be open simultaneously but according to SO it's deprecated on Linux?

veprbl commented 2 years ago

What about getrlimit(RLIMIT_NOFILE)?

toonn commented 2 years ago

That's what I'm doing now but it does give up a little POSIX compatibility so I don't know how upstream will feel about it.

risicle commented 2 years ago

So.. #145371 deals with the CApi.open_plenty_of_contexts failure, but what about GridTest.VerticalShiftGridSet_gtx?

toonn commented 2 years ago

@risicle, I'm not sure about that, it doesn't seem like an actual failure. There's weirdness with the test suite where some other tests are sometimes affected by failures.

risicle commented 2 years ago

:crossed_fingers: