What I recall observing is call traces that made no sense. Not just
extra noise in the stack trace but things like seeing a function that
has exactly one path to it, and not seeing all of the functions on
that path in the call trace.
In my later debugging I have been reasonably able to attribute those
kinds of things to compiler optimizations like inlining and tail call
optimization.
Now I will agree that having fewer or no false positives to weed
through is a good thing, if we can do it reliably.
Hmm. I haven't seen those traces, but I wonder if the size of those
stack traces indicates potential stack overflow problems.
Do you also validate the unwind data?
I don't know. The impression I got was the root cause analysis stopped
when it was observed that the code was unsuitable for solving the problem.
When asked about it, it appeared the developer did not understand the
question. Therefore the root cause was assumed to be the developer.
At least that is how I have read the few little bits I have seen.
Certainly. However if the developer has lost a certain amount of
initial trust, the burden becomes much higher.
Eric
-
