With the new exec errors that return snapshot state reference count goes off.
First issue:
from busybox
workdir /src
run --mount=target=. ls -l && fail
In daemon logs see many msg="releasing already released reference".
Second issue:
from busybox
workdir /src
run --mount=type=cache,target=/cache ls -l && fail
At least sometimes fails with error: failed to solve: rpc error: code = Unknown desc = error committing j1t2azk8c5bokbz3t55jq60ry: invalid mutable ref: invalid: executor failed running [/bin/sh -c ls -l && fail]: exit code: 127 . I debugged that it appears because mutable is already released and ref count is 0.
@hinshun Tried to debug this a bit but quite confusing. Not exactly sure who is the owner of refs in certain points. I think in long term using the wrapped error chain for snapshot refs is not stable enough and causes errors like this or df3a9ca . I think we need to return a special extra return value from vtx.Exec to make clear that everyone calling and passing these objects need to understand who owns and releases these objects. Would be good to find a smaller fix for the v0.8 patch release though.
Not sure if this is related to #1956 . The message is the same but to me, the error is not persistent. This might have an extra effect in combination with prune.
With the new exec errors that return snapshot state reference count goes off.
First issue:
In daemon logs see many
msg="releasing already released reference".Second issue:
At least sometimes fails with
error: failed to solve: rpc error: code = Unknown desc = error committing j1t2azk8c5bokbz3t55jq60ry: invalid mutable ref: invalid: executor failed running [/bin/sh -c ls -l && fail]: exit code: 127. I debugged that it appears because mutable is already released and ref count is 0.@hinshun Tried to debug this a bit but quite confusing. Not exactly sure who is the owner of refs in certain points. I think in long term using the wrapped error chain for snapshot refs is not stable enough and causes errors like this or df3a9ca . I think we need to return a special extra return value from
vtx.Execto make clear that everyone calling and passing these objects need to understand who owns and releases these objects. Would be good to find a smaller fix for the v0.8 patch release though.Not sure if this is related to #1956 . The message is the same but to me, the error is not persistent. This might have an extra effect in combination with prune.