[erlang-questions] get_stacktrace() question

[Kaiduan Xie]

erlang:get_stacktrace() only returns the list of {Module, Function, Arity} (The Arity field in the first tuple may be the argument list of that function call instead of an arity integer, depending on the exception). Is there any way to return the argument list for ALL functions?

Thanks,

kaiduan

[Richard Carlsson]

No. You could use tracing to get more information about your program,
but the stacktrace functionality does not provide this.

/Richard
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions

[Bjorn Gustavsson]

2009/1/5 Kaiduan Xie <kaid...@gmail.com>:

No. The way the BEAM virtual machine works, the arguments are discarded
as soon as they are no longer needed. Only values that will be used again
will be saved in the stack frame.

/Bjorn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB

[Thomas Lindgren]

--- On Mon, 1/5/09, Richard Carlsson <rich...@it.uu.se> wrote:
> Kaiduan Xie wrote:
> > erlang:get_stacktrace() only returns the list of
> {Module, Function, Arity}
> > (The Arity field in the first tuple may be the
> argument list of that
> > function call instead of an arity integer, depending
> on the exception). Is
> > there any way to return the argument list for ALL
> functions?
>
> No. You could use tracing to get more information about
> your program,
> but the stacktrace functionality does not provide this.

Unfortunately, it seems difficult to get this right -- parameters are normally passed in beam registers x(0)...x(N-1), but these registers are basically reused at each call, with only live parameters (or subterms of parameters) saved in the stack frame. So not all variables may be available. The curse of efficiency, I guess.

One approach might be to add a debug mode where parameters are passed on the stack instead, but that's somewhat nontrivial compiler surgery. Also, doing this introduces space leaks: it hangs on to values after they ought to be dead. And undead values can't be GCd. (Could the erlang interpreter do stacktraces right? I haven't tried using it in ages ...)

Best,
Thomas