We do not have working debuggers, ok I can live with logging statements
and code review for most of the time.
If a segmentation fault happens, GDB stopps and shows the position.
Breaking on a throw is also possible with 2 steps:
1.) find the address of the trow function: objdump -x executable | grep
throw
2.) set breakpoint in gdb: break *0x<addr>

But this has 3 problems:
1.) It breaks with every exception.
2.) The GDB backtrace only works for a few frames. Then it complains
about "corrupted stack" or only shows no more. Well this is actually a
problem with the gdb patches I think. With that information I know 'it
is a array bound exception', but the message told that already. I still
don't know from where the function was calls.
3.) The most important: It is not possible to only log the exception
with this information and continue the program.

Then a manual binary search starts. Making certain logging entries to find the statement making the problem. This is so annoying.

Enabling stacktraces will need some performance, but development speed is also important. Please add this. Perhaps with a compiler option to enable/disable this.

Frank Benoit wrote:
> Enabling stacktraces will need some performance, but development speed
> is also important. Please add this. Perhaps with a compiler option to
> enable/disable this.

But the compiler already does generate debugger walkable stack frames if you compile with -g.

Walter Bright schrieb:
> But the compiler already does generate debugger walkable stack frames if you compile with -g.

But it does not work.

GDB says: "Previous frame inner to this frame (corrupt stack?)"

If writefln throws a format error, I can backtrace it to writefln, but not to the writefln caller. So it is not very useful.

And ...
3.) The most important: It is not possible to only log the exception
with this information and continue the program.

Walter Bright schrieb:
> Frank Benoit wrote:
>> Enabling stacktraces will need some performance, but development speed is also important. Please add this. Perhaps with a compiler option to enable/disable this.
> 
> But the compiler already does generate debugger walkable stack frames if you compile with -g.

A additional problem description in the GDB patches forum.

http://www.dsource.org/forums/viewtopic.php?p=10668#10668