On Wed, 31 Aug 2011 16:54:50 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
On 8/31/2011 1:19 PM, Steven Schveighoffer wrote:
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?
Nobody spent the time to do it, mainly because it takes a fairly
advanced low level Windows programmer to understand and do it correctly.
You said there was a patch...? Was it not complete?
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.
Sure. It's just that since debuggers work on Linux, there should be no
technical reason why this cannot be made to work. Of course it will be
very different code than for Windows, but the user wouldn't see that.
Again, starting a debugger because you *know* an assert/segfault is about
to occur is vastly different than diagnosing an *unexpected* assert in the
field or on a machine that has no debugger. Not all seg faults occur in
tightly controlled scenarios. Please stop suggesting debuggers are the
only tool we should be using, it's just not always possible in the real
world. Otherwise, why have logging, stack traces, etc.
> 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?
I misspoke. -release does remove the asserts, but some developers do not
use -release because they wish to leave the asserts on in their release
builds.
And that leaves in all bounds checking and every method call on any object
calls the invariant (whether the derived object defines an invariant or
not) without inlining. Let me know who these people are so I never use
their products!
There are much better tools for this, e.g. enforce.
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.
You'd be surprised. I was surprised to discover that all the asserts in
std.datetime caused the unittest build of phobos to exceed all available
memory on my (old) FreeBSD box. (Jonathan used his own version of assert
that uses more runtime memory, he's got like 7500 in there.) Minimizing
the footprint of assert's reduces the resistance people have to using
them.
I think that:
1. this is likely a combination of code generation issues in dmd and
proliferation of asserts with templates/inlining as you say (I still feel
there is something wrong with dmd, but I have no evidence).
2. Are more than 10% of those 7500 asserts of object references? I'd be
surprised if that were true.
Bloat can get to be a big problem if you're using templates, the
templates contain asserts, and those templates get inlined.
People have regularly complained about the size of D binaries.
Bloat is something to be combated, yes. I am still of the school of
thought that smaller exes are much better than bloatier ones, even when we
have oodles of memory at our disposal.
But we are talking about *debug* builds. I don't think your "people like
to ship code compiled in non-release mode" argument holds water like a
strainer. And I think people *expect* bloat when they enable debugging
information. 15 extra bytes per assert is nothing.
writeln adds 500k of "bloat". Do people who use console output debugging
(a.k.a. printf debugging) complain about bloat because they added in
writeln? I know I don't, and that's my main form of debugging.
-Steve
