www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Call Stack Access

reply "teqDruid (formerly DemmeGod)" <me teqdruid.com> writes:
Is there any way to access the call stack?  Under a certain condition, I
want to output the call stack, and then assert, otherwise I can't tell
where the function is being called from.

TIA
John
Jun 21 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <pan.2004.06.21.22.21.33.17920 teqdruid.com>, formerly DemmeGod
says...

Is there any way to access the call stack?  Under a certain condition, I
want to output the call stack, and then assert, otherwise I can't tell
where the function is being called from.


Perhaps write some inline assembly for the purpose, unless you mean you want a
nice formatted version?

Sean
Jun 21 2004
parent "teqDruid (formerly DemmeGod)" <me teqdruid.com> writes:
Unfortunately, I don't know my asm well enough to do that.  I was hoping
there was an easier, yet undocumented way to do it.

Thanks
John

On Mon, 21 Jun 2004 23:45:42 +0000, Sean Kelly wrote:


 In article <pan.2004.06.21.22.21.33.17920 teqdruid.com>, formerly DemmeGod
 says...

Is there any way to access the call stack?  Under a certain condition, I
want to output the call stack, and then assert, otherwise I can't tell
where the function is being called from.


 
 Perhaps write some inline assembly for the purpose, unless you mean you
 want a nice formatted version?
 
 Sean
Jun 21 2004
prev sibling next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
teqDruid (formerly DemmeGod) wrote:


 Is there any way to access the call stack?  Under a certain condition, I
 want to output the call stack, and then assert, otherwise I can't tell
 where the function is being called from.


That really is the job of a debugger. Putting the code for it into the
executable would really mean a lot of bloat.
Jun 21 2004
parent reply "teqDruid (formerly DemmeGod)" <me teqdruid.com> writes:
It's in at out section, not a body section, so it's not included in
release versions.  It's a lot easier to see the stack trace along with the
exception error message (assert) than to go through again with a debugger
(especially since I haven't found a good interface for gdb that will
accept d source) after the error occurred.  It's near impossible if the
bug isn't easy to reproduce.

John

On Tue, 22 Jun 2004 07:52:06 +0200, Norbert Nemec wrote:


 teqDruid (formerly DemmeGod) wrote:
 

 Is there any way to access the call stack?  Under a certain condition, I
 want to output the call stack, and then assert, otherwise I can't tell
 where the function is being called from.


 
 That really is the job of a debugger. Putting the code for it into the
 executable would really mean a lot of bloat.
Jun 22 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
This has come up before. Walters response was that to debug you add 
printfs and reproduce the bug. IIRC.

I work for a company producing mail server software and IMO a good 
stack/back trace is GOLD when it comes to debugging. Failing that our own 
logfiles are used.

Often the bug is not reproducable easily or at all due to the conditions 
that bring about it's existance i.e. heavy load. These are actually the 
most common bugs a customer sees because testing will often find the ones 
that you could reproduce before you release the binary.

So.. we rely on DrWatson and gdb to give us backtraces on crashes. The 
problem is that some systems are not as good as others at this, and some 
systems can be configured to not drop a core or invoke DrWatson.

Writing your own code to stack walk is complex and not cross platform.

So the problems getting a stack trace are:
  - it's not consistent cross platform
  - custom code is complex and not cross platform

A soln in D that solved the above would be simply awesome.

If I were to imagine a solution it would probably look something like...

int main(char[][] args) {
	onassert(bob);
	return 0;
}

bool bob(Stack s) {
	bool continue = false;
	switch(s.type) {
	case Stack.FloatingPointError:
		//log/handle error
		break;
	default:
		continue = true;
		break;
	}
	return continue;
}

where the Stack structure contained all the useful info, like an array of 
threads containing, an array of stack functions containing an array of 
their parameters etc. Complete with file and line numbers.

The current assert handler which prints to stderr? stdout? would not be 
invoked if one of these was specified, but could optionally be invoked 
with super.assert() if desired.

To C programmers the soln above probably looks a bit like signal handling. 
:)

Regan.

On Tue, 22 Jun 2004 17:03:15 -0400, teqDruid (formerly DemmeGod) 
<me teqdruid.com> wrote:

 It's in at out section, not a body section, so it's not included in
 release versions.  It's a lot easier to see the stack trace along with 
 the
 exception error message (assert) than to go through again with a debugger
 (especially since I haven't found a good interface for gdb that will
 accept d source) after the error occurred.  It's near impossible if the
 bug isn't easy to reproduce.

 John

 On Tue, 22 Jun 2004 07:52:06 +0200, Norbert Nemec wrote:


 teqDruid (formerly DemmeGod) wrote:


 Is there any way to access the call stack?  Under a certain condition, 
 I
 want to output the call stack, and then assert, otherwise I can't tell
 where the function is being called from.


 That really is the job of a debugger. Putting the code for it into the
 executable would really mean a lot of bloat.






-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 22 2004
next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
I would also really like to see a stack trace facility, particularly in a
debug build. Large Java projects can make you appreciate their existence <g>

It's one of two pieces missing from the D Log4J clone (mango.log), in
addition to source file/line info. Presumably a stack trace would provide
the latter?

- Kris


"Regan Heath" <regan netwin.co.nz> wrote in message
news:opr90np40r5a2sq9 digitalmars.com...

 This has come up before. Walters response was that to debug you add
 printfs and reproduce the bug. IIRC.

 I work for a company producing mail server software and IMO a good
 stack/back trace is GOLD when it comes to debugging. Failing that our own
 logfiles are used.

 Often the bug is not reproducable easily or at all due to the conditions
 that bring about it's existance i.e. heavy load. These are actually the
 most common bugs a customer sees because testing will often find the ones
 that you could reproduce before you release the binary.

 So.. we rely on DrWatson and gdb to give us backtraces on crashes. The
 problem is that some systems are not as good as others at this, and some
 systems can be configured to not drop a core or invoke DrWatson.

 Writing your own code to stack walk is complex and not cross platform.

 So the problems getting a stack trace are:
   - it's not consistent cross platform
   - custom code is complex and not cross platform

 A soln in D that solved the above would be simply awesome.

 If I were to imagine a solution it would probably look something like...

 int main(char[][] args) {
 onassert(bob);
 return 0;
 }

 bool bob(Stack s) {
 bool continue = false;
 switch(s.type) {
 case Stack.FloatingPointError:
 //log/handle error
 break;
 default:
 continue = true;
 break;
 }
 return continue;
 }

 where the Stack structure contained all the useful info, like an array of
 threads containing, an array of stack functions containing an array of
 their parameters etc. Complete with file and line numbers.

 The current assert handler which prints to stderr? stdout? would not be
 invoked if one of these was specified, but could optionally be invoked
 with super.assert() if desired.

 To C programmers the soln above probably looks a bit like signal handling.
 :)

 Regan.

 On Tue, 22 Jun 2004 17:03:15 -0400, teqDruid (formerly DemmeGod)
 <me teqdruid.com> wrote:

 It's in at out section, not a body section, so it's not included in
 release versions.  It's a lot easier to see the stack trace along with
 the
 exception error message (assert) than to go through again with a




debugger

 (especially since I haven't found a good interface for gdb that will
 accept d source) after the error occurred.  It's near impossible if the
 bug isn't easy to reproduce.

 John

 On Tue, 22 Jun 2004 07:52:06 +0200, Norbert Nemec wrote:


 teqDruid (formerly DemmeGod) wrote:


 Is there any way to access the call stack?  Under a certain condition,
 I
 want to output the call stack, and then assert, otherwise I can't tell
 where the function is being called from.


 That really is the job of a debugger. Putting the code for it into the
 executable would really mean a lot of bloat.






 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 22 2004
prev sibling parent reply Ant <duitoolkit yahoo.ca> writes:
On Wed, 23 Jun 2004 10:07:06 +1200, Regan Heath wrote:


 This has come up before. Walters response was that to debug you add 
 printfs and reproduce the bug. IIRC.
 


does that mean we'll never have it?
It's important to be able to print the call stack
at any moment - and on asserts.

Ant
Jun 27 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Sun, 27 Jun 2004 12:55:07 -0400, Ant <duitoolkit yahoo.ca> wrote:

 On Wed, 23 Jun 2004 10:07:06 +1200, Regan Heath wrote:


 This has come up before. Walters response was that to debug you add
 printfs and reproduce the bug. IIRC.


 does that mean we'll never have it?
 It's important to be able to print the call stack
 at any moment - and on asserts.


I assume it means there will be no specific langauge support for it, which 
means yet again it will be an ugly platform specific library of some sort 
I suspect.

If there was language support for it, I would hope it:
  - was only compiled in Debug builds.
  - allowed access to the stack (of each thread) using simple 
methods/arrays of values.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 27 2004
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
The GC needs to get access to the stack top and bottom so the code in
src/phobos/internal/gc/gcx.d might be helpful. Or check out std/thread.d.
From the stack ends you could probably get the frame boundaries and find out
the addresses of the functions and look up the function names somewhere. It
sounds painful but it should be possible.
In MATLAB we trap exceptions and dump a stack to the command line and that
is very helpful in debugging sporadic hard-to-reproduce errors. I wouldn't
be surprised if there was a generic C or C++ library that does it already.
If you find one or write one let me know since I'd like to use it, too.

"teqDruid (formerly DemmeGod)" <me teqdruid.com> wrote in message
news:pan.2004.06.21.22.21.33.17920 teqdruid.com...

 Is there any way to access the call stack?  Under a certain condition, I
 want to output the call stack, and then assert, otherwise I can't tell
 where the function is being called from.

 TIA
 John
Jun 22 2004