Skip to content

gdb/testsuite: resume-exception.exp - handle failure to hit breakpoint - #238

Merged
akondrat-amd merged 1 commit into
amd-stagingfrom
users/akondrat/resume-exception-test-fix
Aug 20, 2026
Merged

gdb/testsuite: resume-exception.exp - handle failure to hit breakpoint#238
akondrat-amd merged 1 commit into
amd-stagingfrom
users/akondrat/resume-exception-test-fix

Conversation

@akondrat-amd

@akondrat-amd akondrat-amd commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

If GDB fails to hit the breakpoint in raise_fpe, gpu_thread is never
set and referencing it later would cause a Tcl error. Initialize
gpu_thread to "invalid" before running and return early if it was not
updated by the breakpoint handler.

Jira: AIROCGDB-640

@akondrat-amd
akondrat-amd requested a review from a team as a code owner July 30, 2026 04:55
@lumachad

Copy link
Copy Markdown
Collaborator

Hi @akondrat-amd. Do you know why such a thing would happen? Is it a timeout issue, a specific architecture that behaves differently? A bug?

@lumachad lumachad assigned akondrat-amd and unassigned lumachad Jul 30, 2026
Comment thread gdb/testsuite/gdb.rocm/resume-exception.exp
@akondrat-amd

Copy link
Copy Markdown
Contributor Author

Hi @akondrat-amd. Do you know why such a thing would happen? Is it a timeout issue, a specific architecture that behaves differently? A bug?

It's an issue with rocjitsu that will be eventually fixed.

@akondrat-amd
akondrat-amd force-pushed the users/akondrat/resume-exception-test-fix branch 2 times, most recently from fb3ecfd to 08d6037 Compare August 20, 2026 16:18
If GDB fails to hit the breakpoint in raise_fpe, gpu_thread is never
set and referencing it later would cause a Tcl error.  Initialize
gpu_thread to "invalid" before running and return early if it was not
updated by the breakpoint handler.
@akondrat-amd
akondrat-amd force-pushed the users/akondrat/resume-exception-test-fix branch from 08d6037 to e80e2dc Compare August 20, 2026 16:20
@lumachad

Copy link
Copy Markdown
Collaborator

Hi @akondrat-amd. Do you know why such a thing would happen? Is it a timeout issue, a specific architecture that behaves differently? A bug?

It's an issue with rocjitsu that will be eventually fixed.

Why would we need to adjust ROCgdb if it's a rocjitsu issue?

@akondrat-amd

Copy link
Copy Markdown
Contributor Author

Hi @akondrat-amd. Do you know why such a thing would happen? Is it a timeout issue, a specific architecture that behaves differently? A bug?

It's an issue with rocjitsu that will be eventually fixed.

Why would we need to adjust ROCgdb if it's a rocjitsu issue?

It's our bug, we do not initialize the variable, rocjitsu just exposed it by failing in the right place. It's more cosmetic than functional. If the subtest fails, we get a TCL error with a call stack instead of test failure.

@lumachad

Copy link
Copy Markdown
Collaborator

Hi @akondrat-amd. Do you know why such a thing would happen? Is it a timeout issue, a specific architecture that behaves differently? A bug?

It's an issue with rocjitsu that will be eventually fixed.

Why would we need to adjust ROCgdb if it's a rocjitsu issue?

It's our bug, we do not initialize the variable, rocjitsu just exposed it by failing in the right place. It's more cosmetic than functional. If the subtest fails, we get a TCL error with a call stack instead of test failure.

Oops. Sorry, that wasn't clear to me.

@lumachad lumachad left a comment

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.

This looks OK to me. Thanks.

@akondrat-amd
akondrat-amd merged commit 52d220e into amd-staging Aug 20, 2026
9 checks passed
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