Line numbers in stack traces

[Richard Cameron]

I think this would ordinarily qualify as being a silly question, but  
it seems quite valid here:

Is there any way to extract enough information from a standard erlang  
stack trace to be able to work out at which line the exception was  
thrown? To illustrate this with a convoluted example, we have:

> -module(test).
>
> -export([crasher/0]).
>
> crasher() ->
>     {ok, _Value1} = function_which_mysteriously_fails(),
>     {ok, _Value2} = function_which_mysteriously_fails().
>
> function_which_mysteriously_fails() ->
>     U = random:uniform(),
>     if
>         U > 0.5 ->
>             {ok, U};
>         true ->
>             error
>     end.
>

when I run this on R10B-6 (along with a bit of bad luck on my side),  
I see this:

> home:/tmp rcameron$ erl
> Erlang (BEAM) emulator version 5.4.8 [source] [hipe]
>
> Eshell V5.4.8  (abort with ^G)
> 1> test:crasher().
> ** exited: {{badmatch,error},
>             [{test,crasher,0},
>              {erl_eval,do_apply,5},
>              {shell,exprs,6},
>              {shell,eval_loop,3}]} **
>
> =ERROR REPORT==== 8-Aug-2005::16:13:31 ===
> Error in process <0.30.0> with exit value: {{badmatch,error}, 
> [{test,crasher,0},{erl_eval,do_apply,5},{shell,exprs,6}, 
> {shell,eval_loop,3}]}
>

Now this is all very true, but it's not too helpful. At which line  
was the error? Will the runtime tell me where it crashed without me  
having to go and re-run the process with tracing, or with a bunch of  
io:format statements temporarily inserted into the code?

I'm aware of jungerl's smart_exceptions, but this does seem the sort  
of thing which really ought to be in the core of the language. Python/ 
Tcl/Ruby/Perl will all give you a stack trace traces with line  
numbers, and C will give you a core file which will tell you the  
exact position of failure. Won't Erlang?

Have I missed the command line option which does this, or is there  
some good reason why it's difficult for the virtual machine to report  
on this information (some obscure consequence of the way it compiles  
tail-recursive functions?)

Richard.