Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate core dumps for tests that segfault #1030

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Conversation

azeey
Copy link
Contributor

@azeey azeey commented Oct 11, 2023

This would help in debugging tests that crash on CI, but not locally. The docker flags are based on https://ddanilov.me/how-to-configure-core-dump-in-docker-container

@j-rivero @nuclearsandwich is this a potential security risk? I didn't think it was since the tests are running inside docker and AFAIK the workspace is not accessible by users that are not logged in to Jenkins, but I wanted to confirm with y'all.

@azeey azeey requested a review from j-rivero as a code owner October 11, 2023 16:49
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
Signed-off-by: Addisu Z. Taddese <[email protected]>
@j-rivero
Copy link
Contributor

@j-rivero @nuclearsandwich is this a potential security risk? I didn't think it was since the tests are running inside docker and AFAIK the workspace is not accessible by users that are not logged in to Jenkins, but I wanted to confirm with y'all.

Discussed in the infra meeting. The public publication of the core dump file might be a security risk given the information dumped in these files. You are right about that we protect the workspace of Jenkins to be read only by admins, buildfarmers and github osrf/employees group (to be updated) so technically it could be safe. If other external contributors need access to them, they should be manually inspected first. Said all this, we believe that the best approach would be to have a reproducible build (see #923) but there is not ETA when that will be done.

Another thing to consider from the core dumps is that they are quite big, several Gbs usually. If we enable the generation of them automatically, we could have problems with disk space in nodes. How about introducing a parameter to activate the core dump exportation?

if [[ -d $WORKSPACE/core_dumps ]]; then
for corefile in $WORKSPACE/core_dumps/core.*
do
gdb --batch -ex "sharedlibrary; thread apply all bt" --core \$corefile | tee \${corefile}_backtrace.txt
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
gdb --batch -ex "sharedlibrary; thread apply all bt" --core \$corefile | tee \${corefile}_backtrace.txt
gdb --batch -ex "sharedlibrary; thread apply all bt" --core "\$corefile" | tee "\${corefile}_backtrace.txt"

@j-rivero
Copy link
Contributor

Spoken with @azeey offline, we agreed that exporting the core dump file without #923 implemented would have little interested since reproducibility would be hard to obtain. A possible path forward could be to run the gdb in-the-build and export a stacktrace of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants