vtr_reg_strong failures on master branch

[sfkhalid]

When running vtr_reg_strong on the master branch with sanitizers on (locally, not on Travis CI), there are multiple run failures and qor test failures.

Expected Behaviour

All runs and qor tests should pass when on the master branch.

Current Behaviour

Many of the tests fail. Many of the qor tests return result = -1, and a few of the qor tests have results = exited with return code 3. A few tests pass, such as the no_timing test or the strong_multiclock test.

Possible Solution

May have something to do with vtr_flow rewrite.

Steps to Reproduce

1. Checkout master branch
2. run the command ./run_reg_test.pl vtr_reg_strong

Your Environment

• VTR revision used:
• Operating System and version: Ubuntu 18.04
• Compiler version:

[sfkhalid]

To add extra detail:

The following file has the output of vtr_reg_strong when it is run on the latest master branch with sanitizers turned on:
reg_strong_log.txt

The majority of runs and qor tests fail with some exceptions.
The tests that pass include:
no_timing
fracturable_luts
four of the target_pin_util tests
pack_disable
clock_pll

The log files of the tests that fail shows that VPR succeeds when running the test. However, they all have the same error in the log file vpr.out:

==20915==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 7168 byte(s) in 56 object(s) allocated from:
#0 0x7f90f91baf30 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdef30)
#1 0x7f90f6df7ae2 (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xa7ae2)

SUMMARY: AddressSanitizer: 7168 byte(s) leaked in 56 allocation(s).
Command exited with non-zero status 1

The above-mentioned tests that pass (no_timing, fracturable_luts, etc.) do not have the LeakSanitizer error in their vpr.out files.

[sfkhalid]

This is a sample vpr.out file from one of the tests that fail (strong_analysis_only):

strong_analysis_vpr_out.txt

[vaughnbetz]

Memory leak: 56 realloc calls. Unfortunately the sanitizers don't give much info about where the allocation came from. I suggest waiting and seeing if Shad's inclusion of the suppression file makes this go away. If it doesn't, run valgrind with --leak-check=full to get a more detailed report on where the leak came from. If you have time / don't want to wait you could do that valgrind run sooner to see where this came from.