Skip to content

gdb, testsuite: add gdb.rocm/aspace-nullptr.exp to test nullptr access - #250

Open
aktemur wants to merge 1 commit into
amd-stagingfrom
users/aktemur/nullptr-access
Open

gdb, testsuite: add gdb.rocm/aspace-nullptr.exp to test nullptr access#250
aktemur wants to merge 1 commit into
amd-stagingfrom
users/aktemur/nullptr-access

Conversation

@aktemur

@aktemur aktemur commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Add a new test to check accessing nullptr in various address spaces.

@aktemur
aktemur requested a review from a team as a code owner August 5, 2026 13:49
@aktemur

aktemur commented Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

dbgapi companion PR: ROCm/rocm-systems#9707

Comment thread gdb/testsuite/gdb.rocm/aspace-nullptr.exp Outdated
Comment thread gdb/testsuite/gdb.rocm/aspace-nullptr.cpp
@aktemur aktemur assigned aktemur and unassigned lumachad Aug 9, 2026
@aktemur
aktemur force-pushed the users/aktemur/nullptr-access branch from ed7fd03 to 7ca2551 Compare August 13, 2026 14:55
@aktemur

aktemur commented Aug 13, 2026

Copy link
Copy Markdown
Contributor Author

Update above is only a rebase.

Add a new test to check accessing nullptr in various address spaces.

Bug: AIROCGDB-645
@aktemur
aktemur force-pushed the users/aktemur/nullptr-access branch from 7ca2551 to 83e2b72 Compare August 13, 2026 15:42
@aktemur aktemur assigned czidev-amd and unassigned aktemur Aug 13, 2026
{
/* Make sure that if anything goes wrong, the program eventually
gets killed. */
gdb_watchdog (30);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Is this needed? I do not really see the program having an infinite loop or anything that would prevent forward progress.

This seems unnecessary (and often annoying when building manually testcases, as pretty quickly in the debug session, the program just terminates unless we explicitly ask GDB to ignore SIGALRM).

Comment thread gdb/testsuite/gdb.rocm/aspace-nullptr.cpp
return
}
set bp_line [gdb_get_line_number "Break here"]
gdb_breakpoint $bp_line -allow-pending -temporary

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

As far as I can see, could just break at kern and have the same effect. No need for a breakpoint by line.

set aspaces [dict create]

gdb_test_multiple "maint print address-spaces" "" {
-re "Name$trailer" {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

could as well test that maint print address-space gives us the colums we are looking for, so we can detect early if GDB changes in a way which breaks this test

 -re "Name${sp}Fiald2${sp}..." {
    exp_continue
  }
  -re "Name${trailer}" {
    # indicates the first pattern failed, the header changed, so we can fail the test early
    verbose -log "columns changed"
    fail $gdb_test_name
  }

@czidev-amd czidev-amd left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Once solved Lancelot questions, I have nothing to add.

@lumachad

lumachad commented Aug 21, 2026

Copy link
Copy Markdown
Collaborator

It seems we're hitting timeouts with the new test.

2026-08-13 17:22:16,582 - INFO: print {int}private_wave#0xffffffff
2026-08-13 17:22:16,582 - INFO: FAIL: gdb.rocm/aspace-nullptr.exp: access nullptr in aspace private_wave (timeout)
2026-08-13 17:22:16,582 - INFO: print {int}private_lane#0xffffffff
2026-08-13 17:22:16,582 - INFO: FAIL: gdb.rocm/aspace-nullptr.exp: access nullptr in aspace private_lane (timeout)
2026-08-13 17:22:16,582 - INFO: print {int}local#0xffffffff
2026-08-13 17:22:16,582 - INFO: FAIL: gdb.rocm/aspace-nullptr.exp: access nullptr in aspace local (timeout)

@lumachad

Copy link
Copy Markdown
Collaborator

Could we please make sure this runs clean when O1~O3 and/or flto is used?

@lumachad

Copy link
Copy Markdown
Collaborator

Could you please make sure this is clean when using O1~O3 and/or -flto in the testsuite?

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.

4 participants