Skip to content

tests: fingerprint: fix: OMNeT++ 6.5's unused-entry warning is not a simulation error - #2

Open
tabgab wants to merge 1 commit into
inet-framework:devfrom
tabgab:fix/fingerprint-unused-entry-warning
Open

tabgab wants to merge 1 commit into
inet-framework:devfrom
tabgab:fix/fingerprint-unused-entry-warning

Conversation

@tabgab

@tabgab tabgab commented Nov 7, 2026

Copy link
Copy Markdown

Problem

With OMNeT++ 6.5.0, tests/fingerprint/fingerprinttest.py reports a failing fingerprint as
ERROR (should be PASS): other instead of FAILED (should be PASS): some fingerprint mismatch ....
The mismatch itself is hidden. Passing rows are not affected.

On 6.5.0 this misreported 33 rows, for example lte/multicell Interference-AllOn, -NoDownlink
and -NoUplink, nr/bgTraffic CBR-DL, lte/demo VoIP_DL-UL and nr/mec/multiMecHost MultiMec.

Cause

(line numbers on dev 764db6f, runSimulation in tests/fingerprint/fingerprinttest.py)

  • runProgram merges stderr into stdout.
  • Line 384 collects every output line that starts with <!>.
  • The loop at lines 395-418 sorts them. Fingerprint lines set the pass/fail data,
    Simulation time limit reached is ignored (line 410), and every other <!> line falls into the
    final else (line 412), which sets wasError = True.
  • OMNeT++ 6.5.0 added the unused-entry-check option (default warning). It prints
    <!> Warning: N configuration entries had no effect in this run ..., so any run with an
    unused ini entry lands in that else.
  • With wasError true, the if/elif chain at lines 430-440 takes the first branch and skips
    isFingerprintFail. result.isFingerprintOK stays None, and runTest raises Exception("other") (line 515).

Fix

The warning line is added to the ignored cases, next to Simulation time limit reached. The
pattern is anchored to the exact message of EnvirBase::formatUnusedEntriesReport()
(N configuration entry/entries had no effect ...).

I chose this over treating all <!> Warning: lines as non-errors. The script has no
special handling for any warning today: every <!> line that is not a fingerprint line or the time
limit line counts as an error, and that strictness is the intent of the test (a simulation that
prints a warning is not a clean run). A blanket rule would also hide other warnings, for example
the obsolete-option warning. Only the one message that 6.5.0 prints by default, and that says
nothing about the simulation result, is exempted. Only the first line of the multi-line report
starts with <!>, so one pattern covers it.

--- a/tests/fingerprint/fingerprinttest.py
+++ b/tests/fingerprint/fingerprinttest.py
@@ -409,6 +409,8 @@ class SimulationTestCase(unittest.TestCase):
                         raise Exception("Cannot parse fingerprint-related error message: " + err + "\nPattern: >>>"+pattern+'<<<')
             elif re.search("Simulation time limit reached", err):
                 pass
+            elif re.search(r"^<!> Warning: \d+ configuration entr(y|ies) had no effect", err):
+                pass  # OMNeT++ 6.5 unused-entry-check; not a simulation error
             else:
                 errorMsg += "\n" + err
                 wasError = True

Verification

Full fingerprint suite (python3 fingerprinttest.py -t 8, release build) on macOS, OMNeT++ 6.5.0,
INET 4.7.0, before (script from dev) and after (script with the fix), same binaries:

PASS FAILED ERROR (other)
before 113 108 33
after 113 141 0

The 33 rows move from ERROR to FAILED with their real mismatch, and no passing row changes.
For example Interference-AllOn: before ERROR: other, after
FAILED: some fingerprint mismatch: actual '4eb8-526d/sz', expected: '4e98-526d/sz'.
The FAILED rows are fingerprint differences on 6.5.0/INET 4.7.0 and are not part of this change.

The Simu5G build used for testing needed the macOS intval_t commit from PR #1 (3a50c1d4, applied
only on a local test branch). This PR is independent of it and contains only the script change.

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.

1 participant