Semaphore permit leaks

The idea

A counting semaphore guards a limited pool — say four database connections, or four concurrent jobs. It hands out permits. A worker must acquire() a permit before touching the resource and release() it when done. If no permit is free, acquire() blocks and waits in line.

A permit leak is when a path acquires a permit but never releases it — usually because work throws an exception between acquire and release and there's no try/finally, so the release is skipped. Each leak permanently removes one permit. The available count drifts down, and once it hits zero every acquire() blocks forever: exhaustion.

How it works

The whole bug lives in one missing keyword. When work runs between acquire and release, an exception jumps straight past the release. The permit is logically held by a worker that has already unwound and gone away — nobody owns it, nobody will ever give it back.

# BUG — release is skipped when do_work() throws
def handle():
    sem.acquire()                 # take a permit
    do_work()                     # raises -> jumps out of handle()
    sem.release()                 # never runs: the permit is leaked

# FIX — release always runs, even on the error path
def handle():
    sem.acquire()                 # take a permit
    try:
        do_work()                 # raise all you like
    finally:
        sem.release()             # the permit always goes back

The finally block is the contract: the permit returns no matter how the body exits — normal return, early return, or exception. In languages without finally, a guard object that releases in its destructor (RAII) or a with context manager does the same job.

Signals

Watch out for

• Calling acquire() with no try/finally around the work — the classic leak. The happy path returns the permit; the error path keeps it.
• An early return or break between acquire and release. It exits before the release line just as surely as an exception does.
• Releasing in the wrong scope, or double-releasing — a guard freed twice over-counts the pool and lets in more than N concurrent users.
• An exception inside the release path itself. If cleanup can throw, it must not abort the release of the permit it was guarding.
• Reading a gradual hang as a load spike. A slow leak looks like growing traffic until you notice available permits never climb back.
• Blocking on acquire() with no timeout. A bounded wait fails fast and surfaces exhaustion instead of hanging the request thread forever.

Worked example

A connection-pool handler does pool.acquire(), runs a query, then pool.release(). The pool holds four permits. Most requests are fine. But one query path throws on malformed input — and the author wrote acquire(); query(); release() with no try/finally. Every bad request takes a connection and never returns it. After four bad requests the available count is zero; the fifth caller blocks on acquire(), then the sixth, and the service hangs — even though traffic is normal and the database is idle. Wrapping the body in try: query() finally: pool.release() returns the connection on the error path too, and the available count stops drifting — exactly the contrast the visual walks through.

Check yourself