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.
