-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Improper use of strerror_r in native/dispatch.c #215
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
Comments
Here is a sample program to show the issue and its output on Linux 32-bits. Other systems/architectures may work better.
Output:
|
Addressed in a676e3a, but need to verify no other side effects from the addition of |
mstyura
pushed a commit
to mstyura/jna
that referenced
this issue
Sep 9, 2024
Motivation: To make it easier to reuse the ChannelFutureListener in higher level protocols we should just use Channel.Unsafe directly to write the FIN, otherwise each handler in the pipeline will need to handle a QuicStreamFrame which makes things harder. Modifications: Use Unsafe directly to write the FIN Result: Easier to reuse the listener
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In native/dispatch.c, we have:
and then later:
However, strerror_r exists in two very different flavors: XSI and GNU, see for instance http://unixhelp.ed.ac.uk/CGI/man-cgi?strerror.
When the GNU flavor is used, the emsg buffer will maybe not be written to and the code will therefore use uninitialized data. This is exactly what we see in practice in our Java code on Linux 32-bits with errors like:
FWIW, the Linux man page contains:
So either the code should force the use of the XSI version of strerror_r or it should conditionally define STR_ERROR to work in both cases.
The text was updated successfully, but these errors were encountered: