https://github.com/itamarst/gha-upload-cores
Demonstration of uploading core dumps from your GitHub Actions run
https://github.com/itamarst/gha-upload-cores
Last synced: 12 months ago
JSON representation
Demonstration of uploading core dumps from your GitHub Actions run
- Host: GitHub
- URL: https://github.com/itamarst/gha-upload-cores
- Owner: itamarst
- License: mit
- Created: 2022-07-13T17:13:11.000Z (almost 4 years ago)
- Default Branch: main
- Last Pushed: 2022-07-13T18:40:55.000Z (almost 4 years ago)
- Last Synced: 2025-04-08T12:18:19.118Z (about 1 year ago)
- Language: C
- Size: 10.7 KB
- Stars: 0
- Watchers: 2
- Forks: 2
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Howto: Get access to core dumps from GitHub Actions runs
Sometimes your software segfaults when running tests in CI. That's great! Better it fail in CI than in production. But then you need to debug that segfault, in which case a coredump would be very helpful.
Alternatives:
* [SSH into your running workflow](https://mxschmitt.github.io/action-tmate/)
## Getting coredumps
But how do you get a coredump to your computer?
In order to get coredumps you can debug, you need to:
1. Upload the binary that generated that coredump.
2. Make sure the coredump was stored to disk on segfaults and the like.
3. Upload the coredump even though a CI step has failed.
To ensure core dumps are stored to disk you need to:
1. Override `/proc/sys/kernel/core_pattern` so core dumps are written to file instead passed to `apport` (the default on Ubuntu).
2. Run `ulimit -c unlimited` in the relevant step to ensure core dumps get written to disk.
This repository demonstrates how to do this; see [the Workflow definition](.github/workflows/build.yml) to see the necessary steps.
The coredumps will end up as downloadable artifacts in the results of each relevant GitHub Actions runs.
## Debugging the resulting cores
The program will have been compiled on Ubuntu (whatever version you configured in GHA), so some of the shared libraries might not be in the right location unless you use a matching Docker image.
However, given the original executable you can at least see your own code.
After downloading `executable.zip` and `cores.zip` from the GHA artifacts to the directory with the source code:
```shell-session
$ unzip executable.zip
Archive: executable.zip
inflating: example
$ unzip cores.zip
Archive: cores.zip
inflating: example.1603.1657733715
$ gdb ./example -core ./example.1603.*
...
Core was generated by `./example'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000563a1b2b1190 in main () at main.c:6
6 string[0] = 'b';
(gdb)
```
If your code is a shared library, and it is in the current directory, you can load it into gdb like so:
```
(gdb) set solib-search-path .
(gdb) sharedlibrary library-downloaded-from-gha.so
```
## This repository is sponsored by [Sciagraph](https://sciagraph.com), a performance observability service for Python batch jobs.
And, yes, sometimes my code segfaults in CI.
That's why I run tests in CI, to catch bugs in advance before they're released!