Puzzle

Difficulty: Hard · Puzzle 2 of 6 · Topic: Deadlock Scenario Puzzles: Objection and Phase Stalls

Phase appears idle, but simulation does not cleanly finish and memory usage climbs. Investigate leaked runtime threads.

Code

1
2
3
4
5
6
7
8
9
10
11
12
13

task run_phase(uvm_phase phase);
  phase.raise_objection(this);
  fork
    begin
      forever begin
        poll_status();
        #100ns;
      end
    end
  join_none
  start_traffic();
  phase.drop_objection(this);
endtask

Hint

Dropping objection does not automatically terminate orphaned forever loops.

Step-by-step solution

1) Use process listing / debug prints to confirm watchdog thread remains alive after drop.
2) Verify join_none returns immediately and no handle/disable path is stored.
3) Add explicit thread control: process handle + kill, event-based stop, or disable fork scope.
4) Ensure shutdown path signals and joins child threads before dropping final objection.
5) Add test that checks thread count stabilizes after traffic ends.

Answer

Answer: Bug: join_none launches a forever polling thread that is never stopped. Fix: keep process handle or controlled fork label and terminate thread before phase completion.

Why candidates get it wrong

Objection mechanics are necessary but not sufficient for process lifecycle correctness.

Interviewer follow-up

How would you standardize stoppable background threads across agents/components?

Related topics

• Back to Deadlock Scenario Puzzles: Objection and Phase Stalls

• Scenario & Debug Puzzles section