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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n 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):<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\nFeature\/Bug<\/td> Drudget’s offering<\/td> Open Source Alternatives<\/td><\/tr> Deadlocks<\/td> Drudget’s Run-time deadlock detector and resolver (resolves deadlocks and prevents them from forming).<\/td> Helgrind (as part of Valgrind), a run-time deadlock detector. (Doesn’t resolve them.)<\/td><\/tr> Memory leaks<\/td> Drudget’s garbage collector (memory leak detector and garbage collector all-in-one). <\/td> Valgrind (detects memory leaks, doesn’t garbage collect them).<\/td><\/tr> Heap corruption (heap overflow, use-after-free, double free)<\/td> 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.<\/td>Open source competitors:
For debugging:
* ASAN (libasan).
* Valgrind.
For production:
*hardened_malloc.
* Scudo.
Either:
* Electric fence. (Original idea and no longer maintained).<\/td><\/tr>Self-healing code (detecting buffer overflows and fixing them on the fly)<\/td> 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. <\/td> Open source doesn’t exist.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Bug type<\/td> Time to find line of code responsible for bug<\/td><\/tr> Deadlock<\/td> 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.<\/td><\/tr>Memory leaks<\/td> 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.<\/td><\/tr>Stack buffer overflows<\/td> 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).<\/td><\/tr> Heap buffer overflows<\/td> Silent memory corruption in some cases, or an attacker could get arbitrary code execution. Otherwise instant segfault.<\/td><\/tr> Use-after-free<\/td> Silent memory corruption, can lead to segfault eventually or read\/write primitives which could alter the program’s data or flow.<\/td><\/tr> Double free<\/td> Instant segfault usually, depending on allocator. Otherwise could lead to arbitrary code execution.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n