Memory Leak in C++

Sujeet Pandey — Wed, 31 Dec 2025 17:18:42 +0000

Definition

A memory leak occurs when a program allocates memory dynamically (using operators like new or functions such as malloc) but fails to release it back to the system after use. As a result, the reserved block of memory remains inaccessible to the program yet unavailable for future allocations. Over time, this wasted memory can accumulate, leading to reduced performance or even program crashes.

In C++, there is no automatic garbage collection. It means that any memory that is dynamically allocated by the programmer needs to be freed after its usage manually by the programmer. If the programmer forgets to free this memory, it will not be deallocated till the program lives and will be unavailable to other processes. This is called memory leak.

How It Happens in C++

1.Dynamic Allocation Without Deallocation
int* ptr = new int(10);
// Forgot to delete ptr

Here, memory is allocated for an integer, but since delete ptr; is missing, the memory remains occupied until the program terminates.

2.Lost References
int* arr = new int[5];
arr = nullptr;
// Original pointer lost

The pointer to the allocated block is overwritten, making it impossible to free the memory later.

Consequences-

1.Gradual increase in memory usage during program execution.
2.Slower performance due to reduced available memory.
3.In severe cases, the operating system may terminate the program for exhausting resources.

Prevention Strategies-

1.Always pair new with delete and new[] with delete[].
2.Use Smart Pointers (std::unique_ptr, std::shared_ptr). These automatically manage memory and reduce the risk of leaks.
3.Adopt RAII (Resource Acquisition Is Initialization). Bind resource management to object lifetime so that memory is released when objects go out of scope.
4.Employ Tools. Utilities like Valgrind or AddressSanitizer can detect leaks during testing.

Deadlock(OS) vs Deadlock(DBMS)

Sujeet Pandey — Sun, 30 Nov 2025 18:33:23 +0000

Deadlock in Operating Systems (OS)

What it means in OS

Processes (or threads) request resources (mutexes, files, devices, memory pages). A deadlock occurs when processes each hold some resources and wait forever for resources others hold.

Simple OS example (classic)

Process P1 locks resource A, then tries to lock resource B.
Process P2 locks resource B, then tries to lock resource A.
Both block waiting for the other → deadlock.

Detection (OS)

Build a resource-allocation graph or wait-for graph and detect cycles.
Cycle detection via DFS. If cycle exists → deadlock.
Complexity: graph traversal O(V+E).

Prevention & Avoidance (OS)

Prevention: disallow one Coffman condition (e.g., enforce ordering of resource acquisition, or disallow hold-and-wait by forcing processes to request all resources at once).

Avoidance: Banker's algorithm (process claims max resources; OS grants only if system stays in a safe state). Works well only with fixed, known maximums.

Recovery (OS)

Preemption: forcibly take resources (if safe) and roll back process.
Kill one or more processes (victim selection: low priority, least work done).
Rollback and restart.

Deadlock in DBMS (databases)

What it means in DBMS

Transactions acquire locks (row/page/table locks) to ensure isolation. Two (or more) transactions can form a cycle waiting for locks the others hold.

DBMSs commonly use lock managers and wait-for graphs to detect deadlocks and resolve them automatically.
DB-specific concepts

Lock modes: Shared (S) vs Exclusive (X).

Granularity: row, page, table — coarser locks increase chance of contention.
Two-Phase Locking (2PL): transactions first acquire, then release only after commit/rollback. Strict 2PL holds exclusive locks until commit to ensure serializability — but increases deadlock chance.
Wait-for graph: DB creates waits-for graph of transactions; cycles mean deadlock.

Detection (DBMS)

DB periodically or on demand builds waits-for graph and detects cycles (pick a victim).
Some systems use timeouts (if a transaction waits too long, abort it).
Many RDBMS (MySQL/InnoDB, PostgreSQL) detect cycles and rollback one transaction.

Prevention & Avoidance (DBMS)

Timeouts: simpler but may abort long legitimate waits.
Ordering: acquire locks in consistent order by key or index (e.g., always acquire locks by primary key order).
Optimistic concurrency: versioning (MVCC) avoids many locks for readers.
Deadlock prevention protocols:
Wait-die and Wound-wait (timestamp-based):
Wait-die: older transaction waits for younger; younger requesting older will die (abort).
Wound-wait: older transaction preempts (wounds) younger (younger aborts); younger waits for older otherwise.
Avoid locking when possible: shorter transactions, proper indexing, accessing rows in deterministic order.

Recovery (DBMS)

On deadlock detection, DB chooses a victim (roll back that transaction). Criteria: minimal work lost, lowest priority, few locks, etc.
After rollback, other transactions continue; victim can retry.

DEV Community: Sujeet Pandey