• Frank Benoit (21/21) Aug 15 2006 We do not have working debuggers, ok I can live with logging statements
• Walter Bright (3/6) Aug 15 2006 But the compiler already does generate debugger walkable stack frames if...
• Frank Benoit (8/10) Aug 15 2006 But it does not work.
• Frank Benoit (3/10) Aug 16 2006 A additional problem description in the GDB patches forum.

Frank Benoit <keinfarbton nospam.xyz> writes:

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.

Walter Bright <newshound digitalmars.com> writes:

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.

Frank Benoit <keinfarbton nospam.xyz> writes:

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.

Frank Benoit <keinfarbton nospam.xyz> writes:

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.