debugger blues

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Fri Mar 25 01:14:15 PDT 2016


On 25 Mar 2016 7:00 am, "cy via Digitalmars-d" <digitalmars-d at puremagic.com>
wrote:
>
> I've been working for 3 days straight on this: the monumental task of
taking these text files and turning them into HTML. Or should I say, FML,
because FML. Why is this so hard?
>
> My code is peppered with writelns and sanity checks, none of which show
anything alarming until long after the document gets a self referential
cycle in it, and apparantly this is happening by "creating a child and
appending it to a node." Obviously that's a rare and obscure operation,
that nobody ever would think of doing.
>
> I can't do any introspection. GDB just goes belly up with DIE errors.
Trying to get non-broken DWARF information by switching to GDC, GDC goes
belly up with "internal error, please submit a bug report" and the reason
for this error is creating a module named "cross.iter" and adding a sixth
exported symbol to it.
>

Have you considered raising a bug report as the compiler asks?

http://bugzilla.gdcproject.org/

It will never get noticed or fixed otherwise.

> In reflection, what would be really nice is:
> * some way to trace function calls, to see the order of calls before the
program died.

It's called stack trace, uncaught exceptions print this information out.

> * a backtrace that displays when you hit ^C, instead of just silent death

This is something that you can do with signal handlers.

> * DWARF debugging symbols that don't scramble the only program on earth
that actually uses them.

There's more than one dwarf reader, but yeah dmd has many small things
lacking that mount up as you get more complex.

> * some way to signal the program to dump the stack frames of its threads
to a log

Again, use OS signal handlers?

> * better ways to report program status besides writeln("we got here
somehow");

I'm afraid to say that only you can improve your own printf messages.

> * catching null pointer errors earlier, instead of waiting until you 1)
call the class function and 2) the function accesses a member.

etc.linux.memoryerror - you can use that for catching SIGSEGV and dumping
stacktrace.

I'd suggest that you do the same for other signals such as SIGKILL and
SIGTERM.

> * ways to ensure that nothing is being copied, if you accidentally write
a wrapper that creates an object instead of referencing it, or moving it.

Use @disable this(this); in your structs.

> * better const support, so can minimize the amount of mutable data
involved here

In the library or in your program?  Last time I checked phobos still has
some way to go on that front.

But granted that const is transitive, you should introduce it in a bottom
up fashion.  First find all leaf functions and make them const, then work
your way up from there.

> * it would be nice to be able to return an iterator whose elements are
either const or not const, using inout, instead of having to write the
function twice.

This should be very possible, but I wouldn't know where you are going wrong.

> * it would also be nice to be able to return references, instead of
copying structs every time, or writing wrappers around them (which also
cannot be used with inout)

ref MyStruct() { return s; }

I've never tried mixing ref and inout before, so won't attempt it here.

> * heap allocated structs, stack allocated classes, it would be nice to
have allocation strategy independent from layout strategy.

Use pointer to structs and scope classes.

> * less people writing complex allocating functions as their struct init
property, and then leaving me wondering how that could possibly be
invariant.

I can not ask the hundreds of contributors to stop the fantastic work they
are doing.

> * a pony

Of all points above, this is one that can actually be arranged.  No joke!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20160325/cdee8132/attachment.html>


More information about the Digitalmars-d mailing list