Set BUILDKITE_CANCEL_SIGNAL to SIGQUIT for build and test

[vtjnash]

No description provided.

[vtjnash]

Observe here that I intentionally canceled this build, so that it would print SIGQUIT (which it successfully did). Though looks like no upload task then was able to get the core files (the timeout for uploading the core files after cancellation occurs is set to 10 seconds by default, unless changed in the worker configuration)
https://buildkite.com/julialang/julia-buildkite/builds/1556#019036ea-473f-436a-9633-b3828fe142e2

[staticfloat]

Looks to me like it's still not working.

[vtjnash]

Does it need an updated copy of the sandbox binary with JuliaContainerization/Sandbox.jl@269e91f?

[vtjnash]

At line 581, ABORTED (32: Broken pipe)!

This seems to indicate the running version is quite old?

[staticfloat]

This seems to indicate the running version is quite old?

Indeed, there were more layers of sandboxing than I remembered :P

[vtjnash]

well that is entertaining on musl:

$ /etc/buildkite-agent/plugins/github-com-JuliaCI-coreupload-buildkite-plugin-sf-error-reporting/hooks/post-command
2024-06-24 18:00:37 EDT	ERROR: Cannot find 'file', needed to parse executable paths out of corefiles!!
2024-06-24 18:00:37 EDT	🚨 Error: The plugin coreupload post-command hook exited with status 1

[staticfloat]

Aha, my extra debugging information coming in handy! Here's a fix for that minor issue: JuliaCI/rootfs-images#252

[staticfloat]

I tried canceling one of the test jobs, and it looks to me like the new sandbox executable segfaulted: https://buildkite.com/julialang/julia-buildkite/builds/1577#01904c26-78c2-4120-bdcc-d01a439b5bfa/1373-1378

[vtjnash]

It seems more likely to me that the child segfaulted and then the sandbox killed itself with the same exit code. Seems like the SIGQUIT got propagated though, which looked pretty good. Not sure why it then segfaulted and did not coredump, but maybe that is a quirk of rr? Or is the ulimit -c potentially disabled?

[staticfloat]

Or is the ulimit -c potentially disabled?

julia-buildkite/utilities/test_julia.sh

Line 141 in dea1b33

ulimit -c unlimited

[vtjnash]

But this is https://github.com/JuliaCI/julia-buildkite/blob/dea1b33fba992d460ffae69bce54f598330fb0d3/utilities/build_julia.sh, so is that yes?

[staticfloat]

The segfault I linked was a test job.

[vtjnash]

Right, but it was an rr job too

[staticfloat]

Right, so for rr jobs, we do not run ulimit -c unlimited, which means that core files are disabled. I believe we do that because rr already uploads traces that are better than core dumps anyway.

[DilumAluthge]

Would it hurt to just upload core dumps unconditionally (for both rr jobs and non-rr jobs)?

[DilumAluthge]

Would it hurt to just upload core dumps unconditionally (for both rr jobs and non-rr jobs)?

#368

[staticfloat]

It's just wasted compute time and storage space. There's really no information in a coredump that an rr trace does not have.

[vtjnash]

@staticfloat can you change DROPME: Use sandbox#main to use sandbox@v2 and merge this? CI is green now

[vtjnash]

Looks like sandbox needs that branch pushed to correspond to the release tags? And a rebase here

[vtjnash]

Okay, looks very close, but didn't get enough time to upload the coredump reports for the exact failing test we hope this PR will help with. But it did generate them when canceling (though didn't generate them when killing due to timeout). This will likely require JuliaCI/coreupload-buildkite-plugin#14 and fixing the JuliaCI/coreupload branch name in this PR

[vtjnash]

Needs resigning, and merge?

[vtjnash]

Assuming I updated correctly the SHA hash for the new rootfs versions, this may be still ready to re-sign and merge?