Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ian Lewis
    @ianlewis
    So the test fails to compile or the test just fails?
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    The test fails when running ``make test TARGETS="//test/syscalls:io_uring_setup_test_native"
    1 reply
    Ian Lewis
    @ianlewis
    It compiles but fails the test?
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    Yes
    Ian Lewis
    @ianlewis
    Yeah, I'm not sure. make test runs the tests in a container so that may have something to do with it?
    1 reply
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    external/com_google_absl/absl/synchronization/internal/graphcycles.cc: In member function 'void absl::synchronization_internal::GraphCycles::RemoveNode(void*)':
    external/com_google_absl/absl/synchronization/internal/graphcycles.cc:450:26: error: 'numeric_limits' is not a member of 'std'
      450 |   if (x->version == std::numeric_limits<uint32_t>::max()) {
          |                          ^~~~~~~~~~~~~~
    external/com_google_absl/absl/synchronization/internal/graphcycles.cc:450:49: error: expected primary-expression before '>' token
      450 |   if (x->version == std::numeric_limits<uint32_t>::max()) {
          |                                                 ^
    external/com_google_absl/absl/synchronization/internal/graphcycles.cc:450:52: error: '::max' has not been declared; did you mean 'std::max'?
      450 |   if (x->version == std::numeric_limits<uint32_t>::max()) {
          |                                                    ^~~
          |                                                    std::max
    In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/algorithm:62,
                     from external/com_google_absl/absl/synchronization/internal/graphcycles.cc:38:
    /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/bits/stl_algo.h:3467:5: note: 'std::max' declared here
     3467 |     max(initializer_list<_Tp> __l, _Compare __comp)
          |     ^~~
    Target //test/syscalls:io_uring_setup_test_native failed to build
    Use --verbose_failures to see the command lines of failed build steps.
    And I've read here that Just note that they require specific configuration to work. This is handled automatically by the test scripts in the scripts directory and they can be used to run tests locally on your machine. but I can't find the scripts directory anywhere...
    Ian Lewis
    @ianlewis
    That needs to be updated because the scripts directory doesn't exist. I think the Makefile handles everything now.
    That blurb refers to "For the above noted cases, the relevant runtime must be installed via runsc install before running."
    Which is only the case for integration, image, and root tests IIUC
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    Ok. I will look into what the Makefile is doing then. It is strange that the tests and its dependencies compiles fine in the docker but not using bazel directly
    prattmic
    @prattmic:matrix.org
    [m]
    I think we need to update Abseil
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    I'm using g++ 11
    prattmic
    @prattmic:matrix.org
    [m]
    huh, abseil/abseil-cpp#887 points to the same commit that I did as fixing absl for GCC 11
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    Weird
    That's what I did in WORKSPACE:
    # System Call test dependencies.
    http_archive(
        name = "com_google_absl",
        sha256 = "1764491a199eb9325b177126547f03d244f86b4ff28f16f206c7b3e7e4f777ec",
        strip_prefix = "abseil-cpp-278e0a071885a22dcd2fd1b5576cc44757299343",
        urls = [
            "https://github.com/abseil/abseil-cpp/archive/278e0a071885a22dcd2fd1b5576cc44757299343.tar.gz"
        ],
    )
    I used the latest release (7 days ago)
    And remove ~/.cache/bazel to make sure it will be downloaded
    prattmic
    @prattmic:matrix.org
    [m]
    Perhaps double check that $(bazel info output_base)/external/com_google_absl/absl/synchronization/internal/graphcycles.cc contains the <limits> include?
    1 reply
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    I'm new to bazel, is there something to do to "setup" the "workspace"?
    prattmic
    @prattmic:matrix.org
    [m]
    No, changing the WORKSPACE should have been sufficient, even without clearing cache.
    Let me give it a try
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    Thanks for helping me out
    prattmic
    @prattmic:matrix.org
    [m]
    Ugh, I see.
    Update gRPC to
    http_archive(
        name = "com_github_grpc_grpc",
        sha256 = "abd9e52c69000f2c051761cfa1f12d52d8b7647b6c66828a91d462e796f2aede",
        strip_prefix = "grpc-1.38.0",
        urls = [
            "https://github.com/grpc/grpc/archive/v1.38.0.tar.gz",
        ],   
    )
    The grpc_deps() adds an absl dependency which takes precedence over ours since it comes first.
    1 reply
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    Ah, makes sense. I can make a PR with these 2 changes if you want
    prattmic
    @prattmic:matrix.org
    [m]
    Right, if the same dep name is added twice, only the first is used. And grpc adds com_google_absl in https://github.com/grpc/grpc/blob/master/bazel/grpc_deps.bzl#L263. (I wish Bazel made multiple definition an error).
    A PR would be great. IMO we should probably move our absl above gRPC so it actually does something.
    2 replies
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    Ok I see
    Now the test is correctly compiled but it fails anyway with io_uring_setup returning -1 when using the native runner. How can it fails in the test but not as a standalone executable... Anyway thanks for the help
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    I'm running into a problem. I'm trying to debug runsc following this tutorial. But enven with bazel build -c dbg //runsc:runsc, dvl is warning me Warning: debugging optimized function and I cannot print any arguments nor local variables:
    (dlv) args
    t = ("*gvisor.dev/gvisor/pkg/sentry/kernel.Task")(0xc0001ee000)
    args = gvisor.dev/gvisor/pkg/sentry/arch.SyscallArguments [...]
    ~r2 = (unreadable empty OP stack)
    ~r3 = (unreadable empty OP stack)
    ~r4 = (unreadable empty OP stack)
    Any idea ?
    Ian Lewis
    @ianlewis
    You're sure you're running the runsc binary that you build with -c dbg?
    1 reply
    The debugging instructions are missing a step of actually installing the binary as a docker runtime.
    https://gvisor.dev/docs/user_guide/debugging/#debugger
    Bojan
    @bojand
    Hello, not sure if this is the right place... or minikube issue... I am following these instructions:
    https://github.com/kubernetes/minikube/tree/master/deploy/addons/gvisor
    and trying to get a simple app running using gVisor and it's stuck in ContainerCreating status... regardless of the runtime class I use...? As soon as turn on the gVisor plugin i can't seem to create workloads successfully
    ---
    apiVersion: v1
    kind: Namespace
    metadata:
      name: bbgv
    spec: {}
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: bbapp
      namespace: bbgv
    spec:
      replicas: 1
      selector:
        matchLabels:
          name: bbgvtest
      template:
        metadata:
          labels:
            name: bbgvtest
        spec:
          runtimeClassName: gvisor
          containers:
            - name: bbapp
              image: busybox
              args:
                - /bin/sh
                - -c
                - >
                  echo "starting busybox"
                  i=0;
                  while true;
                  do
                    echo "$i: $(date) message from busybox gvisor";
                    echo "$(date) INFO $i message from busybox gvisor";
                    echo ""
                    i=$((i+1));
                    sleep 20;
                  done
    Bojan
    @bojand

    Somewhat related to what I am trying to get to debugging... does gVisor allow inotify system calls, specifically inotify_init*() and inotify_add_watch()? is there anything needed to get that working? fluentbit tail plugin uses those to watch and tail log files... and from what I can tell it never gets any notifications...

    [2021/06/11 03:09:38] [debug] [input:tail:tail.0] inotify watch fd=22
    [2021/06/11 03:09:38] [debug] [input:tail:tail.0] scanning path /applogs/*.log
    [2021/06/11 03:09:38] [debug] [input:tail:tail.0] inode=97 with offset=219 appended as /applogs/0.log
    [2021/06/11 03:09:38] [debug] [input:tail:tail.0] scan_glob add(): /applogs/0.log, inode 97
    [2021/06/11 03:09:38] [debug] [input:tail:tail.0] 1 new files found on path '/applogs/*.log'
    [2021/06/11 03:09:38] [debug] [stdout:stdout.0] created event channels: read=24 write=25
    [2021/06/11 03:09:38] [debug] [router] match rule tail.0:stdout.0
    [2021/06/11 03:09:38] [ info] [sp] stream processor started
    [2021/06/11 03:09:38] [debug] [input:tail:tail.0] inode=97 file=/applogs/0.log promote to TAIL_EVENT
    [2021/06/11 03:09:38] [ info] [input:tail:tail.0] inotify_fs_add(): inode=97 watch_fd=1 name=/applogs/0.log

    looks like things get setup ok, but it never seems to get any data as it's written to the log file.

    Ian Lewis
    @ianlewis
    @skallwar:matrix.org
    try running
    make dev BAZEL_OPTIONS="-c dbg"
    docker run --runtime=<git branch name>-d --rm --name=test -p 8080:80 -d nginx
    You can break on something like gvisor.dev/gvisor/pkg/sentry/socket/netstack.(*SocketOperations).Accept and then curl http://localost:8080/ to get it to hit the breakpoint.
    If you debug code in runsc you should be able to see the code and print args and locals
    1 reply
    Ian Lewis
    @ianlewis
    @bojand inotify is supported but you only get notificatations for changes that occur inside the sandbox. Any changes to files outside the sandbox won't generate events. Syscall support is summarized here:
    https://gvisor.dev/docs/user_guide/compatibility/linux/amd64/
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    Skallwar (Esteban Blanc)
    @skallwar:matrix.org
    [m]
    I tried to used gdb but I have the same behavior:
    (gdb) p params
    No symbol "params" in current context.
    Lior Neumann
    @liornm

    huh, interesting, that may be a bug. Could you file an issue to attach the runsc debug+strace logs (https://gvisor.dev/docs/user_guide/debugging/)? The .boot and .gofer logs should be most relevant.

    Sorry for the delay, added an issue google/gvisor#6180 , if somebody has a clue about what is causing it, I would highly appreciate it :)

    Ian Lewis
    @ianlewis
    @skallwar:matrix.org I'm not sure what's wrong there. I'm able to find symbols when I use dlv. I can use 'p' and list 'locals' and 'args'
    Ian Lewis
    @ianlewis
    Ah, I can reproduce it. It seems to only be that way when inside the syscall function. It's ok once you step inside other functions. I'm not sure why it's like that but maybe has to do with how the platform invokes the syscall function.
    1 reply
    @skallwar:matrix.org Can you create an issue explaining the problem and we can maybe follow up at some point. Given it's a pretty small scope, it probably won't be high priority though. If you wanted to do some more digging to figure out the problem that would be appreciated.
    1 reply