Skip to content

ExeWithContext returns an error with a Go binary on newer versions of macOS #1622

Closed
@MDrakos

Description

Describe the bug
The ExeWithContext function here expects a specific number of ftxt entries before it extract the executable file path. It appears that on newer versions of macOS this output has changed.

To Reproduce
Passing the following code a running Go binary creates an error. I haven't tested with other running processes.

❯ CGO_ENABLED=0 go run main.go 64030
Could not get executable of process: missing txt data returned by lsof
exit status 1
package main

import (
	"errors"
	"fmt"
	"os"
	"strconv"

	"github.com/shirou/gopsutil/v3/process"
)

func main() {
	if err := run(); err != nil {
		fmt.Println(err)
		os.Exit(1)
	}
}

func run() error {
	if len(os.Args) != 2 {
		return errors.New("Usage: process <pid>")
	}

	pidArg := os.Args[1]
	pid, err := strconv.Atoi(pidArg)
	if err != nil {
		return fmt.Errorf("Could not parse pid: %w", err)
	}

	proc, err := process.NewProcess(int32(pid))
	if err != nil {
		return fmt.Errorf("Could not create process: %w", err)
	}

	_, err = proc.Exe()
	if err != nil {
		return fmt.Errorf("Could not get executable of process: %w", err)
	}

	return nil
}

When I run the lsof command I can see only one ftxt line in the output.

Expected behavior
The proc.Exe() call does not fail and returns the executable file path.

Environment (please complete the following information):

  • Windows: [paste the result of ver]
  • Linux: [paste contents of /etc/os-release and the result of uname -a]
  • Mac OS: [paste the result of sw_vers and uname -a
~
❯ sw_vers
ProductName:		macOS
ProductVersion:		14.4.1
BuildVersion:		23E224

~
❯ uname -a
Darwin M1-MacBook-Pro-6.local 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000 arm64
  • FreeBSD: [paste the result of freebsd-version -k -r -u and uname -a]
  • OpenBSD: [paste the result of uname -a]

Additional context
For the product I'm working on we have an integration test suite that runs on an older version of macOS. The issue does not appear to be present there. Below are the details from the integration test runner:

Operating System
  macOS
  11.7.10
  20G1427
Runner Image
  Image: macos-11
  Version: 20240127.1
  Included Software: https://github.com/actions/runner-images/blob/macOS-11/20240127.1/images/macos/macos-11-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/macOS-11%2F20240127.1

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions