"fatal: Value cannot be null (Parameter 'ptr')" on macOS during git-gvfs-helper

[derrickstolee]

Version

2.4.1

Operating system

macOS

OS version or distribution

(unknown at this time)

Git hosting provider(s)

Azure DevOps

Other hosting provider

(Plus GVFS Protocol)

(Azure DevOps only) What format is your remote URL?

https://{organization}.visualstudio.com/DefaultCollection/...

Can you access the remote repository directly in the browser?

Yes, I can access the repository

Expected behavior

Doing a git pull authenticates and succeeds.

Actual behavior

GCM fails (returns code -1 in Program.cs) with this error message:

fatal: Value cannot be null (Parameter 'ptr')

Logs

While poking around the code (I'm unable to debug on behalf of this user) I found what I think is the only case where a macOS client could pass a null value into a method that has a ptr parameter:

In src/shared/Core/Interop/MacOS/MacOSKeychain.cs:

// Check if an entry already exists in the keychain
int findResult = SecKeychainFindGenericPassword(
    IntPtr.Zero, serviceNameLength, serviceName, accountLength, account,
    out uint passwordDataLength, out passwordData, out itemRef);

switch (findResult)
{
    // Update existing entry only if the password/secret is different
    case OK when !InteropUtils.AreEqual(secretBytes, passwordData, passwordDataLength):
        ThrowIfError(
            SecKeychainItemModifyAttributesAndData(itemRef, IntPtr.Zero, (uint) secretBytes.Length, secretBytes),
            "Could not update existing item"
        );
        break;

The InteropUtils.AreEqual() method takes passwordData directly from the out-parameter in the external method SecKeychainFindGenericPassword() without validation. I'm not sure if this is the issue or what could cause that problem, but hopefully this gives some help towards discovering the problem.

Please see the attached trace.txt given by setting GIT_TRACE2_PERF="$(pwd)/trace.txt" on the git pull calls.

[mjcheetham]

Hello! Thanks for including trace2 logs, unfortunately we would require trace(1) logs to investigate further. Trace2 is pretty sparse in GCM and we're only getting the basic app version info in Trace2 at the moment.

Does this issue happen reliably?