Hide Forgot
I have pushed a fix for jnr-posix to use a direct ByteBuffer as a defensive copy before passing the path out to posix_spawn_file_actions_addopen. I believe this will prevent the native path buffer from being deallocated until well after the posix_spawn call has completed. Please confirm: https://github.com/jnr/jnr-posix/pull/171
(In reply to Charles Oliver Nutter from comment #6) > I have pushed a fix for jnr-posix to use a direct ByteBuffer as a defensive > copy before passing the path out to posix_spawn_file_actions_addopen. I > believe this will prevent the native path buffer from being deallocated > until well after the posix_spawn call has completed. > > Please confirm: https://github.com/jnr/jnr-posix/pull/171 Thanks for coming up with a workaround. I commented on the pull request. I think we originally reviewed this change for RHEL 7 and concluded that applications out there might rely on the fact that the pathname is NOT copied, which is why we declined to fix this bug. I think changing the behavior in 7.9.z is too risky at this point, so I'm closing this bug.
(In reply to Florian Weimer from comment #7) > Thanks for coming up with a workaround. I commented on the pull request. I am responding to your comments and will do further updates on the PR. Thanks! > I think we originally reviewed this change for RHEL 7 and concluded that > applications out there might rely on the fact that the pathname is NOT > copied, which is why we declined to fix this bug. I think changing the > behavior in 7.9.z is too risky at this point, so I'm closing this bug. Perhaps I am missing some detail, but how would the lack of copying be externally visible, other than at a memory level?
(In reply to Charles Oliver Nutter from comment #8) > > I think we originally reviewed this change for RHEL 7 and concluded that > > applications out there might rely on the fact that the pathname is NOT > > copied, which is why we declined to fix this bug. I think changing the > > behavior in 7.9.z is too risky at this point, so I'm closing this bug. > > Perhaps I am missing some detail, but how would the lack of copying be > externally visible, other than at a memory level? The lack of copying could be used to launch different processes with different open files, by mutating the pathname argument in place after calling posix_spawn_file_actions_addopen (and reusing the specified file actions list).
> The lack of copying could be used to launch different processes with different open files, by mutating the pathname argument in place after calling posix_spawn_file_actions_addopen (and reusing the specified file actions list). Well, that's kinda scary, but I understand. Thank you for the clarification! The workaround in jnr-posix has been released in 3.1.8.
We're fone here. Wontfix.