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

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

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

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.

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.

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

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/

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/

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

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/