DebugTracker is a Visual Studio Code extension that records lightweight debugging-process evidence for classroom tasks that captures process evidence through standard VS Code mechanisms rather than language-specific tooling, although debugger evidence depends on the relevant VS Code language extension.
Abstract
Debugging exercises are often assessed from final code and test outcomes, yet these artifacts hide how students reproduced failures, formed hypotheses, inspected evidence, edited code, and verified fixes. We present DebugTracker, a Visual Studio Code extension that records lightweight debugging-process evidence for classroom tasks. DebugTracker separates uncoached Evaluation Mode traces from coached Training Mode traces, stores append-only JSONL events, and exports timeline and Markdown reports for human review. The prototype records test commands, editor and debugger metadata, student checkpoints, source snapshots, optional image evidence, human labels, and optional AI-assisted practice feedback. DebugTracker is largely language-agnostic: it captures process evidence through standard VS Code mechanisms rather than language-specific tooling, although debugger evidence depends on the relevant VS Code language extension. We validate the prototype with debugging tasks in Python, TypeScript, and Java, 16 automated checks, and an 11-case manual trial matrix spanning packaged VSIX installation and three operating systems.
This course teaches a repeatable, production-oriented method for debugging OpenUSD composition issues by focusing on how artists, technical directors, and pipeline developers can investigate real failures by tracing symptoms back to authored opinions, layer stacks, asset resolution, references, variants, edit targets, and render-facing overrides.
Pallav Sharma, N. Porcino, J. Panis· Proceedings of the Special I...· 0 citations
Overall, TraceGate shows that rethinking debugging through controlled observability, rather than relying solely on stronger models or larger prompts, can make LLM-assisted repair more effective, efficient and controllable.
Nicolas Schuler, †. MateVincenzoScotti, †. RaffaelaMirandola· 0 citations
Interactive debugging is an effective tool for understanding program behavior at the source level, allowing developers to pause execution, navigate the call stack, and inspect runtime state. However, interactive debuggers are designed for single-process execution, and interactive debugging has been widely considered impractical for distributed systems. Call stacks stop at process boundaries, debugging state fails to survive infrastructure dynamics, and, most critically, debugger-induced execution pauses trigger catastrophic timeout cascades that destroy the intended debug flow. Consequently, developers are forced to abandon live hypothesis testing in favor of unwieldy and iterative log-and-redeploy cycles. We present DDB, a source-level interactive debugger that extends interactive debugging capabilities to distributed applications. We show that each of these challenges admits a targeted solution. To bridge disjoint processes, Distributed Backtrace (DBT) embeds compact causality metadata in every RPC and reconstructs a unified call stack across RPC boundaries. To manage the lifecycle of a distributed session, an intent-preserving control plane automatically coordinates and propagates breakpoints across dynamic process sets. To make pausing safe, Pause-Erased Time (PET) virtualizes each process's clock, decoupling logical time from physical pauses and preventing timeout cascades. DDB integrates with an RPC framework in 20-60 lines of code. Evaluated on gRPC, ServiceWeaver, Nu, and Quicksand across up to 122 processes, DDB achieves 30ms median cross-RPC backtrace latency, sub-5 ms time jump under repeated execution pauses, and adds 1-5% throughput overhead, comparable to attaching a single-process debugger. In a controlled user study, DDB achieves a 100% fault localization success rate (compared to 38.5% for baseline tools) with a median localization time of ~8 minutes.
Programming error messages are critical for software development, yet they remain difficult for novice programmers to interpret. While Large Language Models (LLMs) can rewrite these errors into clearer explanations, it remains unclear whether increased readability improves objective debugging performance or how explanation styles should align with programmer skill. We present a multi-stage crowdsourced study N=103 evaluating skill-targeted, LLM-generated Python error messages. Using a custom proficiency assessment, we categorized participants by skill level and tested standard interpreter messages against two LLM-generated styles: pragmatic (action-oriented) and contingent (scaffolded explanations). We measured both objective debugging metrics (fix rate, attempts, time-to-fix) and subjective perceptions (readability, cognitive load, tone). Our results show that while LLM-rewritten messages significantly improved subjective evaluations, with pragmatic messages rated as clearer and less cognitively demanding, these perceived gains did not translate into statistically significant improvements in objective debugging performance. This highlights a critical human-AI complementarity gap: explanations that feel better to users do not necessarily make them more effective debuggers. We discuss design implications for adaptive AI feedback systems, arguing that future tools should pivot from static skill-targeted rewriting toward dynamic adjustments based on a user's real-time repair trajectory.
Alexandru-Radu Moraru, Shreyan Biswas, U. Gadiraju· 0 citations
Self-supervised automated program repair (APR) leverages project-specific perturbations to generate training data and uses test execution diagnostics to guide patch generation. In practice, however, diagnostics are heterogeneous (e.g., exception messages, stack traces, assertion diffs, and dynamic execution signals) and must fit within a strict context budget. Naive concatenation either truncates critical evidence or amplifies noisy artifacts, especially for deep bugs where the failure symptom is far from the root cause. We present TraceStructRepair, a diagnostic structuring and budgeting approach for execution-aware self-supervised APR. TraceStructRepair (1) extracts a compact set of execution diagnostics from a single failing test, including exception type and message, stack trace frames, assertion diffs, and optionally dynamically loaded classes; (2) normalizes and ranks diagnostic elements to reduce redundancy and framework noise; and (3) assembles a field-aware representation under a fixed token budget with per-field caps and lexicographic priority rules. We implement TraceStructRepair on top of the SelfAPR pipeline and evaluate it on Defects4J using a project-wise heldout protocol. Beyond end-to-end repair outcomes, we analyze robustness under noisy fault localization and component ablations. We release artifacts to facilitate replication and future work on execution-aware, budget-constrained APR.
Pan Lu, Dongcheng Li, W. E. Wong· Annual International Compute...· 0 citations
This paper introduces SpecCoder, a verification-guided CodeLLM training framework that learns from validated reference programs, behavior-changing mutants, and multi-turn specification-refinement traces, and improves checkpoint-specification quality over base CodeLLMs, and introduces HumanExec, a benchmark built from recent Codeforces competitive programming problems.
Minh Le-Anh, Cuong Chi Le, Tien N. Nguyen· 0 citations