Proposal: User Code Bug Tracking

[Jason House]

My last bug bug was closest to either memory corruption or misuse of druntime API. Mix in that it only happened with concurrency, it involved a poorly understood 3rd party API (C++ code), and awful gdb support, and you have a mix that has soured me on D development to this day!

This was in a project that fully embraced shared. I did not add in the 3rd party library until after it worked with 2 other API's already (one using D and another using C++). It took me over a month to track down, and turned out that the root cause was a bug I had filed months before I hit the issue!

dsimcha Wrote:

> There's been a lot of discussion on this newsgroup about improvements that can
> be made to D to prevent bugs.  The problem is that noone really has stepped
> back and looked at what the biggest causes of bugs in D are.
> 
> I therefore propose that we create a website where people can post a few basic
> details about non-trivial bugs they encountered and fixed in their D2 code.
> (Non-trivial bugs are defined as bugs that took more than a few minutes worth
> of effort to discover, diagnose and fix.)  The simplest version might just be
> something like:
> 
> The root cause of my last D2 bug was closest to:
> 
> Integer overflow
> 
> Signed/unsigned comparison
> 
> Null pointers
> 
> Floating point precision issues
> 
> Unsafe casts
> 
> Memory corruption
> 
> Violation of implicit function preconditions
> 
> Violation of explicit (using contracts) function preconditions
> 
> Violation of implicit struct/class invariants
> 
> Violation of explicit (using contracts) struct/class invariants
> 
> Off-by-one errors
> 
> Misunderstanding of Phobos/druntime API
> 
> Misunderstanding of a third-party library API
> 
> Concurrency issues
> 
> Otherwise incorrect function calls (arguments in wrong order, wrong overload
> called, etc.)
> 
> User input cases I hadn't considered
> 
> Other high-level logic errors not related to any of the above