Unix tests' core-cracking script looks in the wrong place for core dumps

[danmoseley]

Eg., from a crash in a unit test run on Linux:

----- end Wed Jul 14 21:46:14 UTC 2021 ----- exit code 134 ----------------------------------------------------------
exit code 134 means SIGABRT Abort. Managed or native assert, or runtime check such as heap corruption, caused call to abort(). Core dumped.
ulimit -c value: unlimited
...
Waiting a few seconds for any dump to be written..
cat /proc/sys/kernel/core_pattern: /home/helixbot/dotnetbuild/dumps/core.%u.%p
cat /proc/sys/kernel/core_uses_pid: 0
cat: /proc/sys/kernel/coredump_filter: No such file or directory
cat /proc/sys/kernel/coredump_filter:
Looking around for any Linux dump..
... found no dump in /root/helix/work/workitem

The script we use to run unit tests tries to find any core dump, crack it with gdb, dump all threads' stacks, then make a copy in case it's useful. This is broken, because it's looking in the current directory for the dump, and it's nowadays found in /home/helixbot/dotnetbuild/dumps/. It needs to read core_pattern so it knows to look there.

Note, Helix gathers the dump just fine because it uses core_pattern (in fact it set that). It would be nice to fix this so that we also dump some free info in the log.

cc fyi @MattGal

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Eg., from a crash in a unit test run on Linux:

----- end Wed Jul 14 21:46:14 UTC 2021 ----- exit code 134 ----------------------------------------------------------
exit code 134 means SIGABRT Abort. Managed or native assert, or runtime check such as heap corruption, caused call to abort(). Core dumped.
ulimit -c value: unlimited
...
Waiting a few seconds for any dump to be written..
cat /proc/sys/kernel/core_pattern: /home/helixbot/dotnetbuild/dumps/core.%u.%p
cat /proc/sys/kernel/core_uses_pid: 0
cat: /proc/sys/kernel/coredump_filter: No such file or directory
cat /proc/sys/kernel/coredump_filter:
Looking around for any Linux dump..
... found no dump in /root/helix/work/workitem

The script we use to run unit tests tries to find any core dump, crack it with gdb, dump all threads' stacks, then make a copy in case it's useful. This is broken, because it's looking in the current directory for the dump, and it's nowadays found in /home/helixbot/dotnetbuild/dumps/. It needs to read core_pattern so it knows to look there.

Note, Helix gathers the dump just fine because it uses core_pattern (in fact it set that). It would be nice to fix this so that we also dump some free info in the log.

cc fyi @MattGal

Author:	danmoseley
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[ViktorHofer]

I think that the most of the RunnerTemplate logic for Unix is outdated and can probably be removed. At least the parts here and the other ones at the bottom of the script.

[danmoseley]

Really none of this need be repo specific right? Arcade spoils have any dump cracking logic.

[ViktorHofer]

Exactly. I don't think any of that logic is important for local testing either.

[danmoseley]

Would you perhaps be able to open an issue in Arcade pointing to where the logic should go?

[ViktorHofer]

The way dotnet/runtime, more specifically libraries, execute tests is still very much repo specific. I don't think it makes sense to move this into Arcade. IMO we can just remove parts of that code and no one will notice.