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
Regression on POSIX ql_syscall_open #1442
Comments
Hi there and thanks for reporting this. According to POSIX manuals It is true that we don't set |
Hello, you are correct about libc implementation returning -1 and setting errno but this is the syscall version (has no access to errno) so the error is returned which is then set to errno in libc's wrapper. This does cause problems as specifically musl libc version 1.2.0 when trying to search through the libary paths will specifically check for ENOENT or something of the sort but will fail outright if it encounters EPERM aka -1. If you see the mentioned issues i believe for the same reason they are having the same problem. In the past open has been correct which i why i say regression, one of my emulations has failed from 1.4.5 to 1.4.6 due to this. |
Can you please point me to a resource I can look into it? (syscall vs. libc wrapped) |
Yep sure, hopefully musl source would suffice. This is not exclusive to just open, most libc funcs that set errno are done with return value from syscall. So if you see the implmentation of It calls __syscall_ret. Which is defined as: All syscall errors are negative, so they flip the sign and set it to errno. Which is why in my proposed change i return -errno. |
You can also test this on your host machine by calling the syscall directly avoiding libc and see the return value. I can provide that too if you wish. |
I believe this is the commit that caused the regression: |
@iMoD1998, I opened a PR with the necessary fixes. |
Thanks i appricate it. |
Describe the bug
In version 1.4.6,
ql_syscall_open
is hard coded to always return EPERM (-1) for evey failed open attempt, preventing some libc implementations from traversing the LD_LIBRARY_PATH. Fixing this should also fix: #1403 and possibly #1412 ??Sample Code
Expected behavior
Open should return actual open error code like before.
Proposed Change
Something like the following will work, or something similar from 1.4.5.
The text was updated successfully, but these errors were encountered: