martinpitt / umockdev

Mock hardware devices for creating unit tests and bug reporting

Home Page:https://launchpad.net/umockdev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

O_TMPFILE test failing

cazfi opened this issue · comments

I have O_TMPFILE test failing. More precisely, it's the "errno == 0" assert that fails. Likely the problem is that you don't have as strict checks for whether it's even supposed to work as actual tests are:

/* open() with O_TMPFILE; this hasn't been supported in Linux for very long
 * (>= 3.11), so check that it works in the testbed only if it also works
 * in the "normal" file system. */
fd = g_open("/tmp", O_TMPFILE|O_RDWR, 0644);
if (fd >= 0) {
    close(fd);
    errno = 0;
    fd = g_open("/dev", O_TMPFILE|O_RDWR, 0644);
    g_assert_cmpint(errno, ==, 0);
    g_assert_cmpint(fd, >, 0);
    g_assert_cmpint(write(fd, "hello", 5), ==, 5);
    close(fd);
} else {
    g_printf("(Skipping O_TMPFILE test, not supported on this kernel: %m) ");
}

So you are saying yuo have a system where this fails with ENOSYS? But why does the first g_open() succeed then? That's precisely what the else branch is meant to do.. How does it fail exactly? the g_assert_cmpint should print the actual value.

EOPNOTSUPP, I think:

assertion failed (errno == 0): (95 == 0)

OK, so your kernel supports O_TMPFILE in general (in /tmp/, and the mocked /dev usually lives in /tmp/. So I can't make sense of this yet...

Or it means that the redirection is not working and it opened the real /dev? e.g. LD_PRELOAD not having kicked in?

Possibly, but I'd expect an EPERM/EACCESS then, as the user is hopefully not allowed to write into /dev

❱❱❱ strace -e openat touch /etc/foo
openat(AT_FDCWD, "/etc/foo", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = -1 EACCES (Permission denied)

Either way, @cazfi please let me know some details here --- OS, build environment, how you built, and please run the whole thing through strace -fvvs1024 -o /tmp/trace. Thanks!

the mocked /dev usually lives in /tmp/.

It might be that "usually" is the key word here. This is a NixOS build, so things might live in unusual places.

Ah, NixOS! Do you have $TMPDIR or $TEMPDIR set in that environment? Could you try a build with replacing the "/tmp" with g_get_tmp_dir()?

I don't have that particular setup any more, and on other kind of setups I have everything works.

OK, thanks for reporting back. I'll commit the g_get_tmpdir() thing, can't hurt.