occasional ERROR: Assert `switch_it->signal.size() == compare_it.size()' failed in kernel/rtlil.cc:2258.

[oharboe]

Version

Yosys 0.51 (git sha1 c4b5190, g++ 14.2.0-19ubuntu2 -fPIC -O3)

On which OS did this happen?

Linux

Reproduction Steps

@povik FYI

This is occasional, so capturing what I have before I try to whittle it down.

Untar and run https://drive.google.com/file/d/1J2Be9V2y5_YNRGTV6Cv52TVG-eiQiWCG/view?usp=sharing

Occasional:

+ yosys -v 3 -c external/bazel-orfs~~orfs_repositories~docker_orfs/OpenROAD-flow-scripts/flow/scripts/synth.tcl
Using ABC speed script.
Extracting clock period from SDC file: .//results/asap7/BoomTile/base/clock_period.txt
Setting clock period to 1200
1. Executing RTLIL frontend.
2. Executing HIERARCHY pass (managing design hierarchy).
2.1. Analyzing design hierarchy..
2.2. Analyzing design hierarchy..
3. Executing SYNTH pass.
3.1. Executing HIERARCHY pass (managing design hierarchy).
3.1.1. Analyzing design hierarchy..
3.1.2. Analyzing design hierarchy..
ERROR: Assert `switch_it->signal.size() == compare_it.size()' failed in kernel/rtlil.cc:2258.

Expected Behavior

No assert.

Actual Behavior

assert, occasionally

[povik]

@oharboe Can you do a quick run without -v 3 in YOSYS_FLAGS to capture final log messages?

[oharboe]

@oharboe Can you do a quick run without -v 3 in YOSYS_FLAGS to capture final log messages?

So far I've only been able to reproduce it twice, both times with -v 3. Running 100 iterations now, but no luck in simply running it many times, so once it is "stable" it appears not to fail anymore.

[oharboe]

@povik Unable to reproduce.. Any ideas on initial conditions I can change to trigger slightly different code-paths?

Is yosys single threaded? temp files? pointer indexed hashes where members are iterated over in which case anything could cause slightly different initial conditions?

If this can't be reproduced, then I don't know what value there is to keeping this issue open...

[povik]

Is yosys single threaded?

I believe so.

temp files?

It creates those at the abc step, and they shouldn't be a source of indeterminism.

pointer indexed hashes where members are iterated over in which case anything could cause slightly different initial conditions?

We're trying to get rid of those but some could be persisting.

[oharboe]

I'm running out of ideas to change initial conditions:

• valgrind
• Removing -v 3
• gdb

Unless there's something that can be guessed from the assert that can clue us in on how to reproduce this, I guess the issue should be closed as not actionable?

[povik]

Probably. Let me ping @widlarizer in case he has ideas.

[widlarizer]

I'll give reproducing it a shot later. If you reproduce with yosys built with SANITIZER=undefined, I guess we would be likely to catch something closer to the source of the problem, quite likely even if you don't reproduce the assertion failure it might catch a memory safety problem. Though I'm not sure if it's stronger than valgrind at anything. We also have some "memhasher" infrastructure that does random reallocations whenever a RTLIL::Cell is constructed, so yosys -M might help you shuffle the decks. There's also --hash-seed <seed> which mixes <seed> into the hashing function

For hard to reproduce problems, keep issues open, they don't have to be immediately actionable

[whitequark]

Unless there's something that can be guessed from the assert that can clue us in on how to reproduce this, I guess the issue should be closed as not actionable?

If you are able to get rr to reproduce the issue it should be easy to track down.

[oharboe]

Unless there's something that can be guessed from the assert that can clue us in on how to reproduce this, I guess the issue should be closed as not actionable?

If you are able to get rr to reproduce the issue it should be easy to track down.

🤯

[oharboe]

@whitequark Any pointers on how I can use rr when creating a self contained actionable reproducible issue for yosys?

I would have thought that this is a tool that is useful on a developer's computer, but that it isn't easy to use for bug reporting. The user normally runs with optimized release code, so the data that rr generates doesn't have debug information.

Though, to me it sounds like rr would really shine on heisenbugs, where debug information is a luxury anyway.

Is there a reason yosys does not dump a stack trace on an assert?

https://linux.die.net/man/3/backtrace_symbols_fd

[whitequark]

The user normally runs with optimized release code, so the data that rr generates doesn't have debug information.

I think you'll have to build yosys yourself (with debug information) if you intend to debug it.

[oharboe]

Not actionable at this point