java-topology/defects/gdb-scan/CLEAN.md

3.2 KiB

GDB (GNU Debugger) — 5-MOAD Scan

Source: https://github.com/bminor/binutils-gdb (depth=1 snapshot 2026-03-31) Scan date: 2026-03-31

MOAD-0001 (CWE-407) — CLEAN

Our scan examined our primary hot paths:

  • gdb/breakpoint.cbuild_bpstat_chain() iterates all_breakpoints() with nested all_bp_locations_at_addr() using binary search (std::equal_range). update_global_location_list() sorts bp_locations then uses a sorted-scan duplicate-detection algorithm. No O(N^2) inner loops.
  • gdb/symtab.c — Symbol cache uses a hash-bucketed symbol_cache_slot array. Block lookup (block_lookup_symbol) delegates to a dictionary (hashtable). No linear membership inside outer loop.
  • gdb/dwarf2/read.c — DWARF CU processing uses gdb::unordered_set for visited sets throughout. visited_not_found / visited_found are explicit hash sets.
  • gdb/dwarf2/abbrev.h — Abbrev table stored as std::unordered_set with custom hash.
  • gdb/dwarf2/cooked-index-shard.cfind() uses std::equal_range (binary search) on sorted vector.
  • gdb/inline-frame.cinline_states is a small vector (one entry per active thread). find_inline_frame_state() is O(T) where T = thread count, called once per frame unwind. Not a scaling defect in practice.
  • gdb/solib-svr4.cglibc_tls_slots uses std::find to locate empty slot on SO load (fill) and locate slot by address on SO unload (erase). This is O(S) per SO load event where S = number of TLS-bearing SOs, giving O(S^2) across startup. With S typically < 100 for real programs, this amounts to < 5,000 comparisons total. Severity: NEGLIGIBLE.
  • gdb/cp-namespace.cfound_symbols is a std::map (ordered by name). Not a vector.
  • gdb/ada-lang.c — Exception dedup uses std::sort + std::unique (O(N log N)).

Verdict: CLEAN. Our codebase uses hash tables, binary search, and sorted arrays consistently throughout all hot paths. No actionable O(N^2) defects found.

MOAD-0002 (Intertangle) — CLEAN

GDB uses current_program_space, current_inferior(), and thread globals extensively. This is a known architectural design (single active inferior at a time) with a well-defined execution model, not an accidental coupling. Each command operates on an explicit context. No unintended cross-phase state bleed found.

MOAD-0003 (Leaked Context) — CLEAN

gdb/complaints.c uses thread_local complaint_interceptor* — this is a controlled, intentional use to redirect diagnostic output during symbol reading. It is scoped to the main UI thread only (gdb_assert (is_main_thread()) enforces this). Not a request-scoped identity leak.

MOAD-0004 (CWE-312 Logged Credentials) — CLEAN

GDB's RSP (remote serial protocol) in gdb/remote.c does not implement authentication. No auth tokens, passwords, or credentials pass through the GDB remote protocol layer. remote_debug output logs protocol packets but none contain credentials.

MOAD-0005 (Thundering Herd) — CLEAN / NOT APPLICABLE

GDB is architecturally single-threaded for all analysis operations. The UI thread is the only thread that accesses symbol tables, breakpoints, and inferior state. No concurrent cache access patterns possible. MOAD-0005 does not apply.