On Mon, 02 Aug 2010 00:59:42 -0400, Ryan W Sims <[email protected]> wrote:
The following code fails with a "Bus error" (OSX speak for "Segfault,"
if I understand correctly).
// types.d
import std.stdio;
class A {
int x = 42;
}
void fail_sometimes(int n) {
A a;
if (n == 0) {
a = new A; // clearly a contrived example
}
assert(a.x == 42, "Wrong x value");
}
void main() {
fail_sometimes(1);
}
It's even worse if I do a 'dmd -run types.d', it just fails without even
the minimalistic "Bus error." Is this correct behavior? I searched the
archives & looked at the FAQ & found workarounds (registering a signal
handler), but not a justification, and the threads were from a couple
years ago. Wondering if maybe something has changed and there's a
problem with my system?
I'm not familiar with dmd -run, but you should be aware that asserts are
not compiled into release code.
Try changing the assert to this:
if(a.x != 42) writeln("Wrong x value");
FWIW, D does not have null pointer exceptions, even in debug mode. It's
an oft-debated subject, but Walter hasn't ever budged on it. His view is
that you should use a debugger to see where your code is failing. We have
pointed out countless times that often it's not possible to have a
debugger at hand, or even be able to reproduce the issue that caused the
segfault while in a different environment. I don't know if we'll ever see
null pointer exceptions, but I'd love them in debug mode only, or at least
to see a stack trace when it occurs. The latter can be done without
Phobos/dmd help if someone can write such a signal handler function. I
don't know enough about stack traces to understand how to do it.
-Steve
