I’m with the Graal native-image team and we use Travis CI on our GitHub repository (.travis.yml). native-image is a tool to build binaries (executables or shared libraries) for Java applications. We have a feature called isolates for which we look up the memory mapping of our binary in the process memory via
/proc/self/maps and read its file path, for example
/home/travis/build/oracle/graal/substratevm/svmbuild/hello.hello. We then open the file at this path to map parts of the file into process memory using
Unfortunately, in Travis CI (specifically on arm64), procfs seems to provide paths from outside of the container in which the build runs, such as
/var/snap/lxd/common/lxd/storage-pools/instances/containers/travis-job-oracle-graal-714752907/rootfs/home/travis/build/oracle/graal/substratevm/svmbuild/hello.hello. We cannot use this path from within the container as it is, and there does not seem to be a good way to find out which part of the path is in the container’s root filesystem.
I’ve introduced some diagnostics code to print the contents some files in
/proc/self/map_files/contains symlinks to the same paths as in
maps, so the links are broken
/proc/self/root, which is a symlink to the
chroot'ed filesystem of the process, but links to
/proc/self/mountinfo, which contains:
858 588 0:155 / / rw,relatime - shiftfs /var/snap/lxd/common/lxd/storage-pools/instances/containers/travis-job-oracle-graal-714752907/rootfs rw,passthrough=3 ... 861 858 0:154 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw ...
Full output at: https://travis-ci.org/github/oracle/graal/jobs/714752907#L4787
Could this be a configuration problem in the container infrastructure, possibly related to how
procfs are used?
Are there any ideas how to work around this issue reliably? Ideally we would like to avoid using file paths in the first place, but there doesn’t seem to be a way to clone memory mappings under Linux or to directly obtain a file descriptor for an existing memory mapping.