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

app-compat: Not a directory error and assertion failure when running gzip with app-elfloader #858

Closed
razvand opened this issue Apr 21, 2023 · 1 comment
Labels
kind/bug Something isn't working

Comments

@razvand
Copy link
Contributor

razvand commented Apr 21, 2023

Describe the bug

When using app-elfloader (via the run_app.sh script in run-app-elfloader) to run the gzip dynamic build and the gzip static PIE build, a Not a directory error appears based on a utimensat system call.

Also, a dentry-related assertion appears. This is also part of the echo dynamic build and the ls dynamic build.

Steps to reproduce

You can easily just use the ./do.sh script in the unikraft-upb/scripts repository:

$ ./do.sh setup
$ ./do.sh build
$ ./do.sh run_built gzip
$ ./do.sh run_built gzip_static

Expected behavior

There shouldn't be any errors printed.

Which architectures were you using or does this bug affect?

x86_64

Which platforms were you using or does this bug affect?

kvm

Relevant log output

write(fd:4, "\x1F\x8B\x08\x08gjBd\x00\x03test.txt\x00+I-.\xE1"..., 34) = 34
close(fd:3) = OK
utimensat(0x4, 0x0, ...) = Not a directory (-20)
gzip: write(fd:2, "gzip: ", 6) = 6
/test.txt.gz: Not a directory
write(fd:2, "/test.txt.gz: Not a dire"..., 30) = 30
fchown(0x4, 0x0, ...) = 0x0
fchmod(0x4, 0x1b4, ...) = 0x0
close(fd:4) = OK
rt_sigprocmask(0x0, 0x100021a600, ...) = 0x0
unlink(0x100021dd00, 0x100021a600, ...) = 0x0
rt_sigprocmask(0x2, 0x47f92f7d0, ...) = 0x0
lseek(0x0, 0x0, ...) = 0x0
close(fd:0) = OK
[    0.327286] CRIT: [libvfscore] <dentry.c @  216> Assertion failure: dp->d_refcnt > 0
@razvand razvand added the kind/bug Something isn't working label Apr 21, 2023
@marcrittinghaus
Copy link
Member

I can reproduce the assert. Looking into it...

marcrittinghaus added a commit to marcrittinghaus/unikraft that referenced this issue Apr 24, 2023
Previously, if pathname is either NULL or a relative path, and
dirfd is not AT_FDCWD, dirfd needed to refer to a directory.
However, in Linux there is a non-conformant behavior that
if pathname is NULL, the timestamps are applied to whatever
file dirfd refers to. For improved Linux compatibility, we
adopt this behavior.

This commit also fixes various leaks of the file descriptor
reference that is received via the call to vfscore_get_file().

Github-Fixes: unikraft#858
Signed-off-by: Marc Rittinghaus <marc.rittinghaus@unikraft.io>
StefanJum pushed a commit to unikraft-upb/unikraft that referenced this issue Jun 5, 2023
Previously, if pathname is either NULL or a relative path, and
dirfd is not AT_FDCWD, dirfd needed to refer to a directory.
However, in Linux there is a non-conformant behavior that
if pathname is NULL, the timestamps are applied to whatever
file dirfd refers to. For improved Linux compatibility, we
adopt this behavior.

This commit also fixes various leaks of the file descriptor
reference that is received via the call to vfscore_get_file().

Github-Fixes: unikraft#858
Signed-off-by: Marc Rittinghaus <marc.rittinghaus@unikraft.io>
Reviewed-by: Stefan Jumarea <stefanjumarea02@gmail.com>
Reviewed-by: Rares Miculescu <miculescur@gmail.com>
Approved-by: Razvan Deaconescu <razvand@unikraft.io>
Tested-by: Unikraft CI <monkey@unikraft.io>
GitHub-Closes: unikraft#865
razvanvirtan pushed a commit to razvanvirtan/unikraft that referenced this issue Jun 6, 2023
Previously, if pathname is either NULL or a relative path, and
dirfd is not AT_FDCWD, dirfd needed to refer to a directory.
However, in Linux there is a non-conformant behavior that
if pathname is NULL, the timestamps are applied to whatever
file dirfd refers to. For improved Linux compatibility, we
adopt this behavior.

This commit also fixes various leaks of the file descriptor
reference that is received via the call to vfscore_get_file().

Github-Fixes: unikraft#858
Signed-off-by: Marc Rittinghaus <marc.rittinghaus@unikraft.io>
Reviewed-by: Stefan Jumarea <stefanjumarea02@gmail.com>
Reviewed-by: Rares Miculescu <miculescur@gmail.com>
Approved-by: Razvan Deaconescu <razvand@unikraft.io>
Tested-by: Unikraft CI <monkey@unikraft.io>
GitHub-Closes: unikraft#865
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
Status: Done!
Development

Successfully merging a pull request may close this issue.

2 participants