Obligatory notice: I am the CEO of Drudget Pty Ltd (www.drudget.com.au), and I’m explaining Drudget’s tools here, and comparing them to open source alternatives.
If you aren’t using these tools (whether they’re Drudget’s offerings or open source) and you’re coding in C/C++, then there’s a chance you’re wasting valuable time in debugging.
The table below lists Drudget’s offerings compared to open source alternatives — I have yet to give product names to Drudget’s offerings, so the name may change in the future, but the functionality is given in the table.
| Feature/Bug | Drudget’s offering | Open Source Alternatives |
| Deadlocks | Drudget’s Run-time deadlock detector and resolver (resolves deadlocks and prevents them from forming). | Helgrind (as part of Valgrind), a run-time deadlock detector. (Doesn’t resolve them.) |
| Memory leaks | Drudget’s garbage collector (memory leak detector and garbage collector all-in-one). | Valgrind (detects memory leaks, doesn’t garbage collect them). |
| Heap corruption (heap overflow, use-after-free, double free) | Drudget’s heap protector. Guarantees heap overflows never work (segfaults immediately), use-after-free is never able to re-use freed page (segfaults immediately), and double free causes a segfault. These segfaults are immediate, as they operate on protected page mappings, and guarantees no control is ever given to an attacker. | Open source competitors: For debugging: * ASAN (libasan). * Valgrind. For production: *hardened_malloc. * Scudo. Either: * Electric fence. (Original idea and no longer maintained). |
| Self-healing code (detecting buffer overflows and fixing them on the fly) | Drudget’s prototype self-healing code. Uses state-of-the-art assembly opcode injection, and a WAF (web application firewall) blocks input that exceed that buffer size. | Open source doesn’t exist. |
If you don’t use these tools, here are some typical debug times that a developer might take (whereas if they used the tools above, whether it was Drudget’s or open source, it would be instant time to find the location):
| Bug type | Time to find line of code responsible for bug |
| Deadlock | Anywhere between when you test the code path (if it happens instantly, you are very lucky), otherwise it could happen hours or days or even weeks running — as deadlocks require resources to be in a cyclic graph and locked simultaneously, so there’s a race condition that is required for that. Average time saved really depends on how often you test that code path whilst running the program — which is annoying. Answer: 1 hour+ to several days. |
| Memory leaks | Slow memory leaks are hard to find, and may take running the program for days before anything obvious in memory usage shows up. Answer: within an hour to days, depending on if you know how to reproduce it. |
| Stack buffer overflows | Instant segfault usually (due to violation of canary), but if carefully crafted, the attacker could gain arbitrary code execution instead. (i.e. if they are able to leak and re-use the canary). |
| Heap buffer overflows | Silent memory corruption in some cases, or an attacker could get arbitrary code execution. Otherwise instant segfault. |
| Use-after-free | Silent memory corruption, can lead to segfault eventually or read/write primitives which could alter the program’s data or flow. |
| Double free | Instant segfault usually, depending on allocator. Otherwise could lead to arbitrary code execution. |
As a developer in other companies, I’ve used my Drudget’s tools personally to help me debug these types of bugs instantly, before any open source tool was available — most of the open source alternatives were developed after I developed these tools.
It’s only recently (circa 2023) that I decided to start Drudget as a company to market these tools to the wider developer community. To be honest, I have not made any sales as of this writing, and I’m glad that’s the case — it almost implies that everyone is either using open source tools, or they have some other manner/means of debugging these types of bugs, or they don’t care.
However, if you’re stuck on a bug, and you don’t think the open source tools are adequate, take a look at drudget.com.au and email us.
Leave a Reply
You must be logged in to post a comment.