[Feature]: Stochastic Fuzz Testing Engine for Memory Edge-Case Validation

[CodeSparks45]

Problem Description

With the recent additions of complex data structures (Fenwick Trees, Suffix Arrays, Advanced Heaps), relying solely on fixed unit tests might miss rare edge-case segmentation faults or use-after-free errors. We need a way to subject these structures to chaotic, randomized operations to truly validate their memory safety under Valgrind/ASan.

Proposed Solution

Build a lightweight Fuzz Testing module (fuzzer.c).

1. Create a function that generates a massive sequence (e.g., 100,000 operations) of randomized insertions, deletions, and lookups using rand().
2. Apply this stress test to complex structures (like Red-Black Trees or Graphs).
3. The engine should track the operations and, if a segfault occurs, print the exact seed and sequence of operations that caused the crash for easy debugging.
4. Hook this fuzzer into the make test pipeline so CI can catch unstable operations.

Additional Context

Suggested Labels: new feature, Hard, SSoC26

---

Note for Maintainers: I have cleared my previous pending assignments and my queue is empty. I am well aware of the project's strict formatting and memory safety standards. If assigned, I guarantee that I will run make fmt, make test, and make valgrind to ensure zero memory leaks and proper clang-formatting before raising the PR. Could you please assign this to me?

[saidai-bhuvanesh]

/assign

[CodeSparks45]

Hii @saidai-bhuvanesh
Have you not read the SSOC'26 Rules?

[darshan2456]

@CodeSparks45
yo ignore him, just a spammer, BTW can you explain what you mean by fuzzy testing? I didnt get the idea

[saidai-bhuvanesh]

Thanks for asking. The idea is to complement deterministic unit tests with randomized stress testing.

Unit tests verify expected behavior for known inputs, but they often miss rare execution paths. A fuzz testing engine continuously generates randomized and boundary-case operations (such as insert, delete, search, invalid keys, duplicate values, empty structures, and high-volume sequences) to exercise code paths that are difficult to cover manually.

When executed with AddressSanitizer (ASan) or Valgrind, this helps detect memory-safety issues like use-after-free, double-free, invalid memory access, buffer overflows, and other forms of undefined behavior.

To make failures reproducible, the engine should log the random seed and the exact sequence of operations that triggered the crash, allowing developers to replay the scenario and debug it deterministically.

The goal isn't to replace existing unit tests, but to strengthen the validation pipeline by exposing edge cases that traditional tests may never reach.

[saidai-bhuvanesh]

Thanks for asking. The idea is to complement deterministic unit tests with randomized stress testing. Unit tests verify expected behavior for known inputs, but they often miss rare execution paths. A fuzz testing engine continuously generates randomized and boundary-case operations (such as insert, delete, search, invalid keys, duplicate values, empty structures, and high-volume sequences) to exercise code paths that are difficult to cover manually. When executed with AddressSanitizer (ASan) or Valgrind, this helps detect memory-safety issues like use-after-free, double-free, invalid memory access, buffer overflows, and other forms of undefined behavior. To make failures reproducible, the engine should log the random seed and the exact sequence of operations that triggered the crash, allowing developers to replay the scenario and debug it deterministically. The goal isn't to replace existing unit tests, but to strengthen the validation pipeline by exposing edge cases that traditional tests may never reach.

…

On Tue, Jul 7, 2026 at 2:49 PM noobcoder ***@***.***> wrote: *darshan2456* left a comment (darshan2456/C_DSA_interactive_suite#674) <#674 (comment)> @saidai-bhuvanesh <https://github.com/saidai-bhuvanesh> yo ignore him, just a spammer, BTW can you explain what you mean by fuzzy testing? I didnt get the idea — Reply to this email directly, view it on GitHub <#674?email_source=notifications&email_token=BOC4WIEPOQDUIOMXU3URSCD5DS6D7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQGIYTSOJXHE2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4902199794>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BOC4WIB6TXKOQQVUY2BQZMT5DS6D7AVCNFSNUABGKJSXA33TNF2G64TZHMYTCMBTHEYDANBUHE5US43TOVSTWNBYGE4TANRSGU4DHILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BOC4WIGNLR6ECREOCSJRDAD5DS6D7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQGIYTSOJXHE2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/BOC4WID6NYJDNGDQ77OHKL35DS6D7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQGIYTSOJXHE2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[CodeSparks45]

@darshan2456 looks like someone used an LLM to reply on my behalf before I could even open my laptop! 😂
To explain it simply in the context of our C codebase:
Right now, our unit tests are deterministic. We write tests like insert(10), insert(20), delete(10) and check if it works. But this doesn't catch unpredictable edge cases.
A Fuzzer is basically a stress-test loop. It runs a massive for loop (say, 100,000 iterations) and randomly fires insert(), delete(), or search() with random integer values based on a seed.

[CodeSparks45]

We need this because......
Complex structures like Red-Black Trees or Fenwick Trees involve intense pointer manipulation.

[darshan2456]

ohkkk nice addition to the suite I see. But just not trees, extend it to graph traversal algorithms and backtracking algos too

[Akshatshukla-25]

@CodeSparks45 are you working on these issues ??