gdb/testsuite: Add runtime-core-attached test by amd-bfilipov · Pull Request #216 · ROCm/ROCgdb

amd-bfilipov · 2026-07-16T14:32:42Z

Test core dump generation while program runs under GDB. With the fix for core dump collection during debugging, verify that running under GDB in batch mode with signal passthrough generates both host and GPU cores, which can be merged and loaded.

What we're testing:

Run a HIP program under GDB
Configure GDB to pass signals through (not stop on them)
Program crashes with GPU fault
ROCm runtime generates core dumps even though GDB is attached
Verify GDB can load those cores and see GPU threads

Uses batch mode: -ex 'handle SIGABRT/SIGSEGV nostop pass' -ex 'run' This allows GDB to catch faults but pass them to runtime/kernel.

Motivation

Tests the new capability from ROCm/rocm-systems#6811 that enables core dump generation even when a debugger is
attached

Technical Details

Runs test program under GDB in batch mode with signal passthrough configuration
Verifies both host (core.*) and GPU (core.*.gpu) cores are generated
Merges cores using coremerge and validates they can be loaded in GDB
Uses system command to inherit test environment (LD_LIBRARY_PATH)
Tests pagefault and abort scenarios

lancesix

Some preliminary comments. Will do a more in depth review later.

lumachad

Could we please have a better description of what we're trying to test here? The "test core dump while gdb is attached" sounded to me like we were controlling rocgdb when generating the core file, but it sounds like what we want is for some unrelated process to be generating a core file while we test something else in the runtime.

Is that the case? If so, should this be a ROCR test instead?

aktemur · 2026-07-30T11:56:49Z

+    gdb_test "handle SIGABRT nostop pass" ".*"
+    gdb_test "handle SIGSEGV nostop pass" ".*"
+    gdb_test_no_output "set cwd $coredir"
+    gdb_test "set args $fault" ".*"


gdb_test_no_output

Done. Changed to gdb_test_no_output "set args $fault" on line 53.

aktemur · 2026-07-30T11:57:31Z

+    # a while for large core dumps.
+    with_timeout_factor 3 {
+	gdb_test_multiple "" "wait for program exit" {
+	    -re "Program terminated with signal" {


Also -wrap?

Multiple messages arrive before the prompt (both "Program terminated" and "The program no longer exists"), so
-wrap on each pattern causes race conditions; using exp_continue for messages and matching the final prompt
directly works correctly.

aktemur · 2026-07-30T11:58:21Z

+    with_timeout_factor 3 {
+	gdb_test_multiple "" "wait for program exit" {
+	    -re "Program terminated with signal" {
+		pass "program crashed"


Let's please use $gdb_test_name. Also in the occurrences below.

aktemur · 2026-07-30T12:11:20Z

+    gdb_test "target core $merged_core" \
+	[multi_line \
+	    ".*" \
+	    "Core was generated by .*" \


I feel uneasy about .*'s in such cases, because they can also match newline. Can we use \[\r\n\]* instead. Also in the line below.

The pattern (lines 120-124) follows the established pattern from runtime-core.exp for matching core file loading output. The leading .* on line 121 is necessary to skip the library loading messages that precede "Core was generated by". The trailing .* patterns allow matching variable content (command arguments, signal details, wave coordinates). The multi_line structure with these patterns has been proven to work correctly in the sibling test.

lancesix · 2026-08-03T12:25:52Z

+require allow_rocm_core_tests
+require allow_hip_tests
+
+standard_testfile runtime-core.cpp


We usually try to have a 1:1 mapping between .ccp and .exp. Either what is tested here fits in runtime-core.exp, or this test should have its own test program.

Sure, added runtime-core-attached.cpp

lancesix · 2026-08-03T12:32:20Z

+    # Check that ulimit allows core dumps.  The test environment must
+    # have ulimit -c set to unlimited before running this test.
+    set ulimit_value [exec sh -c "ulimit -c"]
+    if {$ulimit_value != "unlimited"} {


I am not sure checking ulimit that way is sufficient. For example, if building GDB with ASAN, the ASAN runtime implicitly turns ulimit to 0 (the ASAN has a heavy impact on core size otherwise):

$ ulimit -c unlimited $ ASAN_OPTIONS=detect_leaks=0 ./gdb/gdb -data-directory ./gdb/data-directory -ex "shell ulimit -c" -q -batch 0

I've removed the check, since runtime-core.exp does not check for it either.

lancesix · 2026-08-03T12:34:04Z

+    }
+
+    set hostcore_list [glob -nocomplain -directory $coredir "core*"]
+    set gpucore_list {}


isn't the runtime pringing the gpu core name? Could we find this in the gdb_test_multiple?

Test core dump generation while program runs under GDB. What we're testing: 1. Run a HIP program under GDB 2. Configure GDB to pass signals through (not stop on them) 3. Program crashes with GPU fault 4. ROCm runtime generates core dumps even though GDB is attached 5. Verify GDB can load those cores and see GPU threads Uses batch mode: -ex 'handle SIGABRT/SIGSEGV nostop pass' -ex 'run' This allows GDB to catch faults but pass them to runtime/kernel.

amd-bfilipov requested a review from a team as a code owner July 16, 2026 14:32

github-actions Bot assigned aktemur Jul 16, 2026

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 2 times, most recently from 6262869 to 3d062bb Compare July 16, 2026 14:42

lancesix reviewed Jul 16, 2026

View reviewed changes

Comment thread gdb/testsuite/gdb.rocm/runtime-core-attached.exp Outdated

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 2 times, most recently from 16e1248 to 6fa15be Compare July 16, 2026 15:35

aktemur reviewed Jul 17, 2026

View reviewed changes

aktemur assigned amd-bfilipov and unassigned aktemur Jul 17, 2026

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 3 times, most recently from 51b440f to 5108ffd Compare July 17, 2026 18:40

lumachad reviewed Jul 20, 2026

View reviewed changes

Comment thread gdb/testsuite/gdb.rocm/runtime-core-attached.exp Outdated

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 3 times, most recently from be3797f to 3e11ade Compare July 21, 2026 15:55

aktemur reviewed Jul 23, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 3 times, most recently from 531654b to 2b99b98 Compare July 27, 2026 13:52

amd-bfilipov requested a review from aktemur July 27, 2026 14:06

aktemur reviewed Jul 30, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 2 times, most recently from 37620ba to 5703c12 Compare August 3, 2026 10:58

lancesix reviewed Aug 3, 2026

View reviewed changes

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch from 5703c12 to 6fc6cb4 Compare August 3, 2026 12:41

amd-bfilipov requested review from aktemur and lancesix August 3, 2026 12:51

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch from 6fc6cb4 to f5ecd1e Compare August 4, 2026 10:01

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch 4 times, most recently from b35e2fd to aad3169 Compare August 4, 2026 10:16

amd-bfilipov force-pushed the users/bfilipov/coredump-testing branch from aad3169 to 6dd0052 Compare August 4, 2026 11:37

Uh oh!

Conversation

amd-bfilipov commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Technical Details

Uh oh!

lancesix left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lumachad left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

amd-bfilipov commented Jul 16, 2026 •

edited

Loading