| Author |
Message |
|
| e.blood at citr.com |
 Posted: Wed Apr 21, 1999 6:00 am |
 |
|
|
Guest
|
Ok, I've flamed up the debugger, set a break point, and did one step
down into the wtour stuff, and the return of etk:start() is <0.55.0>.
In the "monitor" window of the debugger window, it shows:
{undef, {etk, start, []}}
So, it looks like a build problem. However, why does <0.55.0> show up
on the terminal instead of the atoms shown in the monitor window?
Meanwhile I'll look to see why etk didn't get in there.
Eric
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| tobbe at serc.rmit.edu.au |
| Posted: Wed Apr 21, 1999 6:22 am |
|
|
|
Guest
|
> {undef, {etk, start, []}}
>
> So, it looks like a build problem. However, why does <0.55.0> show up
> on the terminal instead of the atoms shown in the monitor window?
Yes, looks like your build didn't work out properly.
The pid is shown because the spawn/3 BIF creates a
process returning a Pid to it. The returned Pid only
indicates that a process was created, the process may
very well crash right away, as in your case.
You can check all living processes with the i() command
from the shell prompt.
Try this from the shell prompt:
spawn(silly,example,[])
and:
spawn_link(silly,example,[])
in both case you'll get a pid returned.
In the second case however, the shell will
also die (and be restarted again). This
is caused by the link and the exit signal
being sent.
/Tobbe
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| ulf.wiger at etxb.ericsso |
| Posted: Wed Apr 21, 1999 7:55 am |
|
|
|
Guest
|
Eric Blood wrote:
>
> Ok, I've flamed up the debugger, set a break point, and did one step
> down into the wtour stuff, and the return of etk:start() is <0.55.0>.
> In the "monitor" window of the debugger window, it shows:
>
> {undef, {etk, start, []}}
>
> So, it looks like a build problem. However, why does <0.55.0> show up
> on the terminal instead of the atoms shown in the monitor window?
>
> Meanwhile I'll look to see why etk didn't get in there.
>
> Eric
The reason why the error indication is so poor is that spawn/3 was used
instead of e.g. spawn_link/3 or - better yet - proc_lib:spawn_link/3.
spawn/3 doesn't care what happens to the process it created. It will
always just return the pid and move on.
With spawn_link/3:
------------------
etxuwig_at_avc343 > erl -boot start_clean
Erlang (BEAM) emulator version 4.8.2
Eshell V4.8.2 (abort with ^G)
1> wtour:start().
<0.30.0>
** exited: {undef,{etk,start,[]}} **
With proc_lib:spawn_link/3 and the SASL application started:
------------------------------------------------------------
etxuwig_at_avc343 > erl -boot start_sasl
Erlang (BEAM) emulator version 4.8.2
Eshell V4.8.2 (abort with ^G)
1>
...
=PROGRESS REPORT==== 21-Apr-1999::09:50:55 ===
application: sasl
started_at: nonode_at_nohost
1> wtour:start().
<0.39.0>
** exited: {undef,{etk,start,[]}} **
2>
=CRASH REPORT==== 21-Apr-1999::09:50:59 ===
crasher:
pid: <0.39.0>
registered_name: []
error_info: {undef,{etk,start,[]}}
initial_call: {wtour,start1,[]}
ancestors: [<0.25.0>]
messages: []
links: [<0.25.0>]
dictionary: []
trap_exit: false
status: running
heap_size: 233
stack_size: 0
reductions: 76
neighbours:
neighbour: [{pid,<0.25.0>},
{registered_name,[]},
{initial_call,{shell,evaluator,3}},
{current_function,{shell,eval_loop,2}},
{ancestors,[]},
{messages,[]},
{links,[<0.22.0>,<0.39.0>]},
{dictionary,[]},
{trap_exit,false},
{status,waiting},
{heap_size,233},
{stack_size,0},
{reductions,40}]
--
Ulf Wiger, Chief Designer AXD 301 <ulf.wiger_at_etxb.ericsson.se>
Ericsson Telecom AB tfn: +46 8 719 81 95
Varuv |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
