On Wed, 31 Aug 2011 16:02:56 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
On 8/31/2011 4:46 AM, Steven Schveighoffer wrote:
Seg faults are not as useful as asserts. It's a fact.
You might be surprised, then, that I'll often temporarily replace an
assert with a HLT instruction so I can use a debugger on it :-)
Not at all. If you prefer that mode of debugging, that's fine. But if I
have 150 systems running a program I wrote, and one of them fails every
week (random which one, and length of time), you'd better bet I'm going to
prefer a stack trace to a seg fault. I don't want to wait another week +
install debuggers on each of those systems.
When I said Seg faults are not as useful as asserts, I meant *unplanned*
seg faults. If you plan for a seg fault to occur, (or even an assert) you
can use a debugger to capture it.
If you have a seg fault,
you must reproduce the error while in a debugger, or generate a core
dump.
Reproducing not be possible, or might take considerable time. Any
argument
against this is revisionist history. Yes, if I go back in time and run
it in a
debugger for that execution, it would be useful. Yes, if I go back in
time and
change my shell options to generate a core dump, it would be useful. If
you have
an assert, you get a stack trace, no need to reproduce the assert in a
debugger,
or enable non-default settings in your shell. It just gives you the
information
you need.
It's also possible for the program to have its own seg fault handler
that reads its own symbolic debug info and generates a line number and
stack trace. There was a patch to Phobos that did this a while back.
This would also be a valid option. I have no idea why that wasn't
included. Do you?
Optlink's register dump on a seg fault is not Windows' doing, it
installs a seg fault handler which does this.
I predominantly use Linux, so Optlink/Windows tools really don't help. D
is supposed to support all OSes not just be useful on Windows.
On linux, the shell options are what determine whether the OS generates a
core dump, and by default they are off. It also does not hook seg faults
to start a debugger by default, it just says "Segmentation Fault" on the
command line and gives you a prompt. Useless.
> So 4 instructions per assert of a class reference (which is arguably
not common) is a lot of bloat?
15 bytes. And yes, this stuff adds up surprisingly quickly, especially
if you're the type that wants to leave the asserts on even in release
mode.
How is this possible? I thought release mode removed asserts?
Currently, the empty main() program is 256k. Add in writeln("hello,
world") and it adds 500k. Even if I had 10,000 asserts in there for
objects, that adds 150k.
I think bloat can't possibly be a valid concern here.
Besides, you ignored my comment about how we can eliminate the bloat.
Care to respond?
-Steve
