[DynInst_API:] [dyninst/dyninst] eb6c62: parseAPI: DIAGNOSTIC differential oracle in getGap...


Date: Sat, 20 Jun 2026 12:31:51 -0700
From: bbiiggppiigg <noreply@xxxxxxxxxx>
Subject: [DynInst_API:] [dyninst/dyninst] eb6c62: parseAPI: DIAGNOSTIC differential oracle in getGap...
  Branch: refs/heads/bbiiggppiigg/getgaprange-oracle
  Home:   https://github.com/dyninst/dyninst
  Commit: eb6c62d156f0791a31fa02d7ec8411ac12e368c0
      https://github.com/dyninst/dyninst/commit/eb6c62d156f0791a31fa02d7ec8411ac12e368c0
  Author: wuxx1279 <bbiiggppiigg@xxxxxxxxx>
  Date:   2026-06-20 (Sat, 20 Jun 2026)

  Changed paths:
    M parseAPI/src/Parser-speculative.C

  Log Message:
  -----------
  parseAPI: DIAGNOSTIC differential oracle in getGapRange

Not a fix -- a diagnostic build. getGapRange computes the gap both ways on
every call: the original sorted_funcs rebuild (reference) and the optimized
funcsByRange query. On the first input where they disagree it dumps
curAddr/gapStart/gapEnd from both (plus the covering extents and the
funcsByRange successor) and asserts, so a Debug build aborts at the first
divergence with full context. Returns the OLD (reference) result otherwise.

Run the deterministic serial repro (OMP_NUM_THREADS=1) against this to pin the
exact input where the funcsByRange-based gap computation diverges from the
original -- expected: a covered/overlapping curAddr where IBSTree_fast's
high()-keyed successor disagrees with "smallest start > curAddr".

Co-Authored-By: Claude Opus 4.8 <noreply@xxxxxxxxxxxxx>



To unsubscribe from these emails, change your notification settings at https://github.com/dyninst/dyninst/settings/notifications
[← Prev in Thread] Current Thread [Next in Thread→]
  • [DynInst_API:] [dyninst/dyninst] eb6c62: parseAPI: DIAGNOSTIC differential oracle in getGap..., bbiiggppiigg <=