Local LeetCode C++ debugging

This workspace builds small local runners, not the submission files themselves. Each runner includes one submission file and supplies main(). This keeps LeetCode submissions unchanged and prevents different Solution classes from being linked together.

Debug in WinDbg

The workspace is configured for this machine's installed Visual Studio Build Tools 2022, native ARM64 compiler, CMake Tools, and WinDbg. No global PATH changes or developer terminal are required.

1. Open this folder in VS Code and save your solution.
2. Run CMake: Select Configure Preset and choose windows-debug.
3. Run CMake: Configure.
4. Run CMake: Set Launch/Debug Target and select leetcode_460 or leetcode_1.
5. Run Tasks: Run Task and choose LeetCode: debug selected problem (WinDbg). The selected runner is built automatically, and standalone WinDbg opens and stops at main(), with source-line stepping enabled.
6. In WinDbg, open the submission source and use F9 to set a breakpoint. Press F5 in WinDbg to continue to your breakpoint or the crash.

Use F10 to step over and F11 to step into. Useful WinDbg commands are g (continue), p (step over), t (step into), dv (local variables), and k (stack). At function entry, step past the prologue before inspecting parameters. The task passes the runner PDB directory and workspace source paths explicitly. WinDbg is launched through its installed Windows app alias; if it is not installed on another machine, install WinDbg first.

The installed VS Code extensions do not provide a WinDbg debug adapter, so this is an external-debugger task, not a windbg launch configuration. Set breakpoints and inspect variables in WinDbg; VS Code breakpoints and its Watch pane are not synchronized with WinDbg.

Recover an invalid breakpoint

If g reports that it cannot insert breakpoint 2 at an address such as 0xD0, inspect the list and remove that invalid breakpoint in the current WinDbg window:

bl
bc 2
g

Use the ID reported by the error. This preserves other breakpoints; bc * would delete all of them. .bpcmds shows the breakpoint definitions. The launch task already uses a module-qualified bu entry breakpoint. For function breakpoints that must track changing code addresses, use symbolic bu commands, such as bu leetcode_460!LFUCache::touch, rather than a raw address. Ensure the intended runner and its matching PDB are loaded.

Optional: debug inside VS Code instead

The existing C/C++ debugger remains available as LeetCode: debug selected problem (VS Code C++) in Run and Debug. Set a VS Code breakpoint and press F5 to use that configuration. It builds the selected runner, stops at main(), and exposes variables in the VS Code Run and Debug view and Watch pane. It uses the Visual Studio debugger (cppvsdbg), not WinDbg. Use Shift+F5 to stop it. Ctrl+Shift+B builds the selected problem without starting the debugger.

The preset selects a Debug build with symbols and no optimization. On another machine, adjust the CMake executable in settings and the generator/architecture in CMakePresets.json.

Current runners

• LFU Cache runner: executes the exact reported sequence. It prints each operation before executing it and reports incorrect get results without stopping early, so the original crash remains reproducible. The cache implementation is intentionally not fixed by this setup.
• Two Sum runner: checks the three example cases and provides a working build/test example.

Add another problem

Create local\<problem-id>.main.cpp. For example:

#include "leetcode.hpp"

using namespace std;
#include "42.Trapping Rain Water.cpp"

int main()
{
    vector<int> height{0, 1, 0, 2, 1, 0, 1, 3, 2, 1, 2, 1};
    const int actual = Solution().trap(height);
    if (actual != 6)
    {
        cerr << "Expected 6, got " << actual << '\n';
        return 1;
    }
    cout << "Sample passed.\n";
    return 0;
}

Save it, run CMake: Configure, and select leetcode_42 as the debug target. No CMake or debugger JSON edits are needed for additional runners. New runners are also discovered automatically on the next build.

leetcode.hpp supplies common standard-library headers and the usual ListNode and TreeNode definitions. Problem-specific types such as Node must be supplied in that problem's runner. Do not copy the local runner or helper header into your LeetCode submission.

Use explicit result checks returning a nonzero exit code for failed cases. Avoid stopping at the first incorrect result when trying to reproduce a later crash. For design problems such as caches, write the constructor and method calls directly; this setup does not parse LeetCode JSON automatically.

PowerShell commands

$cmake = 'C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe'
$ctest = Join-Path (Split-Path $cmake) 'ctest.exe'

& $cmake --preset windows-debug
& $cmake --build --preset windows-debug --target leetcode_460
& '.\build\windows-debug\local\Debug\leetcode_460.exe'

# Run the working Two Sum checks.
& $cmake --build --preset windows-debug --target leetcode_1
& $ctest --preset windows-debug -R '^leetcode_1$'

# Run the LFU reproduction, or omit -R to run all runners.
& $ctest --preset windows-debug -R '^leetcode_460$'

The LFU test is expected to fail until its underlying solution is corrected. Build outputs are kept under build\windows-debug.