cts: regression: crash after commit d7c5a8ae4b9cba8318906490d13fd83ea62aefaf

[titan73]

Describe the bug

After the commit:

commit d7c5a8ae4b9cba8318906490d13fd83ea62aefaf => BAD
Merge: c00d74874 928902cae
Author: Matt Liberty <[email protected]>
Date:   Thu Nov 21 12:59:23 2024 -0800

    Merge pull request #6134 from arthurjolo/cts_enhance_clkgater_handling
    
    Cts enhance clkgater handling

CTS causes a crash with no backtrace:

[WARNING CTS-0002] No paths found for pin I_digital_top/alwayson_top_i/i2c_top_i/u_i2c_bus_monitor/stop_o_reg/CP.
[WARNING CTS-0002] No paths found for pin I_digital_top/alwayson_top_i/i2c_top_i/u_i2c_bus_monitor/start_o_reg/CP.
[WARNING CTS-0002] No paths found for pin I_digital_top/nvm_control_top_0/u_nvm_mmu_softip_top/u_nvm_ctrl/c_nvm_wrapper/s_trim_addr_regx0x/CP.
[WARNING CTS-0002] No paths found for pin I_digital_top/nvm_control_top_0/u_nvm_mmu_softip_top/u_nvm_ctrl/c_nvm_wrapper/s_trim_addr_regx1x/CP.
[WARNING CTS-0002] No paths found for pin I_digital_top/nvm_control_top_0/u_nvm_mmu_softip_top/u_nvm_ctrl/c_nvm_wrapper/s_trim_addr_regx2x/CP.
Segmentation fault (core dumped)

Full log before commit: ok.zip

Full log after commit: bad.zip

Expected Behavior

No crash

Environment

Commit-id provided

To Reproduce

Not been able to make a testcase yet

Relevant log output

No response

Screenshots

No response

Additional Context

No response

[titan73]

I get this width/height with 0 value twice after commit:

[INFO CTS-0025]     Width:  0.0000.
[INFO CTS-0026]     Height: 0.0000.
 Level 1
    Direction: Vertical
    Sinks per sub-region: 1
    Sub-region size: 0.0000 X 0.0000
[INFO CTS-0034]     Segment length (rounded): 1.

And this height = 0 in both logs:

[INFO CTS-0025]     Width:  0.1167.
[INFO CTS-0026]     Height: 0.0000.
 Level 1
    Direction: Horizontal
    Sinks per sub-region: 1
    Sub-region size: 0.0583 X 0.0000

This may be expected but looks surprising.

[arthurjolo]

@titan73 Is there any testcase I can run to reproduce the crash?

[arthurjolo]

I get this width/height with 0 value twice after commit:

[INFO CTS-0025]     Width:  0.0000.
[INFO CTS-0026]     Height: 0.0000.
 Level 1
    Direction: Vertical
    Sinks per sub-region: 1
    Sub-region size: 0.0000 X 0.0000
[INFO CTS-0034]     Segment length (rounded): 1.

And this height = 0 in both logs:

[INFO CTS-0025]     Width:  0.1167.
[INFO CTS-0026]     Height: 0.0000.
 Level 1
    Direction: Horizontal
    Sinks per sub-region: 1
    Sub-region size: 0.0583 X 0.0000

This may be expected but looks surprising.

For the 0 x 0 region is expected because there is only one instance for that clock net to reach, so the area is 0. And on the the 0.0583 X 0.0000 case there is only 2 sinks, that are probably on the same Y coordinate, so the height is 0.

[titan73]

@titan73 Is there any testcase I can run to reproduce the crash?

@arthurjolo Not yet. We're in the process of signing a NDA with PII. Meanwhile I'm trying to make a simple test case.

[arthurjolo]

@titan73 Is there any testcase I can run to reproduce the crash?

@arthurjolo Not yet. We're in the process of signing a NDA with PII. Meanwhile I'm trying to make a simple test case.

Ok, while there is not much I can do, as soon as you send the test case I can start looking into the issue.

[maliberty]

A stack trace could also help.

[titan73]

A stack trace could also help.

Unfortunately this particular crash does not show any backtrace.

[maliberty]

You can always get one in gdb.

[titan73]

@maliberty Here is the backtrace:

#0  0x00005555582258a8 in cts::TritonCTS::isSink(odb::dbITerm*) ()
#1  0x000055555823daa1 in cts::TritonCTS::computeSinkArrivalRecur(odb::dbNet*, odb::dbITerm*, float&, unsigned int&, sta::Graph*) [clone .part.0] ()
#2  0x000055555823dc3b in cts::TritonCTS::computeSinkArrivalRecur(odb::dbNet*, odb::dbITerm*, float&, unsigned int&, sta::Graph*) [clone .part.0] ()
#3  0x000055555823dc3b in cts::TritonCTS::computeSinkArrivalRecur(odb::dbNet*, odb::dbITerm*, float&, unsigned int&, sta::Graph*) [clone .part.0] ()
#4  0x000055555823dc3b in cts::TritonCTS::computeSinkArrivalRecur(odb::dbNet*, odb::dbITerm*, float&, unsigned int&, sta::Graph*) [clone .part.0] ()
....

The last line is repeated 10000 times.
Looks like a recursive call that never finishes.

[maliberty]

That suggests some sort of loop in the clock tree which sounds odd.

[maliberty]

We could solve the recursion with a visited set but I'm afraid we might just be hiding some deeper issue.