Hard Runtime Diagnostics interview problem
Lock leaked on exception path
Written and reviewed by Sahil Srivastav
This problem is available as the same repository challenge in Python, Java, Node.js, and C++. Open the full problem and choose a language
What this interview round tests
A settlement service processes normally until one poisoned record raises inside a critical section. From that point onward, every request waits forever although the original failing call has already returned.
This is a hard production-debugging exercise because the request that caused the outage is gone from the active queue, while thread dumps mostly show innocent later callers blocked at the same acquisition point. It tests whether you can move from operational evidence to a narrow invariant, then make a repair that survives concurrency, retries, failures, or workload growth instead of merely passing one happy-path example.
The scenario
Settlement mutations are protected by an explicitly acquired lock. Invalid records may raise, but one failed request must not change the synchronization state observed by later work.
The starter releases the lock only on normal completion. An exception exits the operation while leaving ownership behind, converting a data-quality error into a permanent service-wide stall.
What you’ll practice
- Finding lock ownership in thread-dump evidence
- Auditing exceptional exits from critical sections
- Using structured lock release semantics
- Keeping protected state valid when processing fails
- Verifying progress after repeated poisoned records
How to approach it
Separate the triggering thread from the waiting threads. Trace the poisoned-record path from acquisition through the throw site and list every exit that bypasses release.
Make release unconditional while preserving the original error and state invariants. Re-run a valid request immediately after each failure to prove the service remains live, not merely correct before the exception.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
Try it in a real repository
LeetCode teaches algorithms. Gronex teaches backend coding rounds with real repositories, failing tests, service logic, and production-style constraints. Read the diagnostic brief on this page, then open the challenge workspace when you are ready to investigate the repository.
FAQ
What should I inspect first in Lock leaked on exception path?
Begin with the wedged thread dump, lock owner and waiter stacks, poisoned-record trace, and progress counters before and after the exception. The supplied evidence narrows the failure mode before you touch the implementation, which is the same evidence-first habit expected during a production incident or senior backend interview.
What makes this a hard runtime diagnostics problem?
It is hard because the request that caused the outage is gone from the active queue, while thread dumps mostly show innocent later callers blocked at the same acquisition point. The test suite checks the underlying invariant and adverse execution paths, so a local patch or a larger resource limit will not satisfy the challenge.
Which languages can I use for this repository challenge?
The same scenario is implemented in Python, Java, Node.js, and C++. Each language directory includes its own source, evidence or database setup, tests, and verify.sh entry point while preserving the same production invariant.