Tricky DMD bug, but I have no idea how to report

[H. S. Teoh]

On Wed, Feb 06, 2019 at 10:37:27PM +0000, JN via Digitalmars-d-learn wrote:
[...]
> I am not sure if it's a pointer bug. What worries me is that it breaks
> at the start of the program, but uncommenting code at the end of the
> program influences it. Unless there's some crazy reordering going on,
> this shouldn't normally have an effect.

As I've said before, this kind of "spooky" action-at-a-distance symptom
is exactly the kind of behaviour you'd expect from a pointer bug.  Of
course, it doesn't mean that it *must* be a pointer bug, but it does
look awfully similar to one.


> I still believe the bug is on the compiler side, but it's a bit of
> code in my case, and if I try to minimize the case, the issue
> disappears. Oh well.

That's another typical symptom of a pointer bug.  It seems less likely
to be a codegen bug, because I'd expect a codegen bug to exhibit more
consistent symptoms: if a particular code is triggering a compiler
codegen bug, then it shouldn't matter what other code is being compiled,
the bug should show up in all cases.  This kind of sensitivity to
minute, unrelated changes is closer to how pointer bugs tend to behave.

Of course, it's possible that there's a pointer bug in the *compiler*,
so there's that.  It's hard to tell either way at this point.  Though
given how much the compiler is used by so many people on a daily basis,
it's also less likely though not impossible. Unless your code just
happens to contain a particularly rare combination of language features
that causes the compiler to go down a rarely-tested code path that
contains the bug.

Anyway, given what you said about how moving (or minimizing)
seemingly-unrelated code around seems to affect the symptoms, we could
do a little educated guesswork to try to narrow it down a little more.
You said commenting out code at the end of the program affects whether
it crashes at the beginning.  Is this in the same function (presumably
main()), or is it in different functions?

If it's in the same function, one possibility is that you have some
local variables that are being overrun by a buffer overflow or some bad
pointer.  Commenting out code at the end of the function changes the
layout of variables on the stack, so it would change what gets
overwritten.  Possibly, the bug gets hidden by the bad pointer being
redirected to some innocuous variable whose value is no longer used, or
some such, so the presence of the bug is masked.

If the commented-out code is in a different function from the location
of the crash, and you're sure that the commented out code is not being
run before the crash, then it would appear to be something related to
the layout of global variables.  Perhaps there's some module static ctor
that's being triggered / not triggered, that changes the global state in
some way that affects the code at the beginning of the program?  If
there's a bad pointer that points to some heap location, the action of
module ctors running vs. not running could alter the heap state enough
to mask the bug in some cases.

Another possibility is if you're interfacing with C code and have a non
null-terminated D string that's being cast to char*, and the presence of
more code in the executable may perturb the data/code segment layout
just enough to push the string somewhere that happens to contain a null
shortly afterwards.

Just some guesses based on my experience with pointer bugs.


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.