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

macOS sysctl mappings have incorrect type for size arguments #1350

Closed
dbwiddis opened this issue May 25, 2021 · 2 comments · Fixed by #1351
Closed

macOS sysctl mappings have incorrect type for size arguments #1350

dbwiddis opened this issue May 25, 2021 · 2 comments · Fixed by #1351

Comments

@dbwiddis
Copy link
Contributor

  1. Version of JNA and related jars: 5.8.0, although this bug has existed since 4.2
  2. Version and vendor of the java virtual machine: Any JDK
  3. Operating system: macOS 11.x
  4. System architecture (CPU type, bitness of the JVM): 64-bit
  5. Complete description of the problem:

Mappings of sysctl contributed in #452 incorrectly used IntByReference as the type for the size parameter, which is incorrect, as its type is size_t.

This incorrect mapping did not seem to cause any problems in macOS 10.x. However, beginning in macOS 11.x systcl calls are failing randomly.

The bug was introduced when the mappings were originally committed in #452 in someone's first PR to JNA.

  1. Steps to reproduce:

Retrieve the command line arguments of a process:

int[] mib = new int[3];
mib[0] = 1; // CTL_KERN
mib[1] = 49; // KERN_PROCARGS2
mib[2] = getProcessID();

IntByReference size = new IntByReference(1048576); // argmax

if (0 != SystemB.INSTANCE.sysctl(mib, mib.length, procargs, size, null, 0)) {
    // call fails randomly on macOS Big Sur
}

Comments: Happy to fix my own blunder, will by definition not be backwards compatible. How do we handle situations like this?

@matthiasblaesing
Copy link
Member

I suggest to mark the broken functions @deprecated and add fixed versions with corrected arguments. I would move the documentation to the new method and retain only a pointer to the new method and a reasoning to not continue use. That way everybody who cares will be warned and situation where the functions with the old binding work, will continue to work.

@dbwiddis
Copy link
Contributor Author

Will do. I'll add a size_t type to SystemB.

How best to handle a size_t by reference? I could put a Pointer in the mapping, or create a class very similar to NativeLongByReferene that switches on Native.SIZE_T_SIZE rather than pointer size.

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

Successfully merging a pull request may close this issue.

2 participants