Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A test failure while building luv in mock for Amazon Linux 2023 #707

Open
jafd opened this issue Jun 21, 2024 · 0 comments
Open

A test failure while building luv in mock for Amazon Linux 2023 #707

jafd opened this issue Jun 21, 2024 · 0 comments
Labels

Comments

@jafd
Copy link

jafd commented Jun 21, 2024

This is more a question than anything. I'm building luv for Amazon Linux 2023, and when running test, the test called "pipe getsockname abstract" fails for a reason that I cannot quite understand. That is, I can see why the assertion fails, but cannot see where the failure is coming from.

For context, the test has this block of code:

    if isLinux then
      assert(server:bind2('\0' .. pipe_name))
      local name = server:getsockname()
      assert(#name == #pipe_name + 1 )
      assert(name:sub(1, #pipe_name + 1) == '\0' .. pipe_name)
      pipe_name = name

and this is the assertion that is failing:

      assert(#name == #pipe_name + 1 )

I tried some print debugging, and found that: #name is 108 while #pipe_name is a saner 17. I asked lua to print bytes within name, and they were just what I'd expect to find but padded with zeroes to 108.

  0     47      116     109     112     47      117     118     45      116     101     115     116     45      115     111     99      107     0       0       0       0       0       0       0       0       0       0       0
        0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0
        0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0
        0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0       0

I don't really know why this is happening and where this is happening. Rebuilding on the same machine but for Fedora 40 runs as expected.

Upon closer inspection, I can see that getsockname() returns always exactly 108 bytes padded with zero bytes as needed (reading the relevant libuv sources confirms that this is as expected because they do memset on the buffer at the start). Longer names are truncated. I'm out of ideas where the number 108 may be coming from. Okay, I now see that sun_path has the maximum of 108 bytes, however, I was under the impression that the leading zero byte in the socket name should address precisely this, and then it doesn't explain why are shorter names being padded with zero bytes to exactly 108.

Amazon Linux 2023 ships libuv-1.47.0, and the downstream patches don't muck with the related functions in any shape or form.

Has anyone bumped into this before? Any ideas why it might be happening?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants