Supervision and Magically Reincarnated Processes

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Supervision and Magically Reincarnated Processes

chandru
Do you have sasl running? If so you should get crash reports you can look at
using rb. If you want to find out the reason without changing anything, us
the sys:trace function on your supervisor, you should see the EXIT message
from the supervised child...

Chandru

-----Original Message-----
From: Bruce Fitzsimons [mailto:Bruce]
Sent: 16 December 2002 08:18
To: erlang-questions
Subject: Q: Supervision and Magically Reincarnated Processes


Hi peoples,

A quick OTP question, I'm using supervisors in my Aplio (Internet Phone)
server program and I've carefully inserted a bug somewhere that makes one of
the processes crash. But I don't get any output about why it has crashed in
the error_logger or shell (when I run it that way).

The process that dies is a gen_server (behaviour) and it doesn't execute its
terminate(Reason, State) so I guess its just 'EXIT'ing somewhere.

My question is: how can I trap this (preferably sans debugger)?

The supervisor restarts it happily, and works so fast and well that I wasn't
even aware it was dying until I started running it in the shell this week.

/Bruce




NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.



Reply | Threaded
Open this post in threaded view
|

Supervision and Magically Reincarnated Processes

Bruce Fitzsimons-2
Thanks a lot Chandru, thats exactly what I needed (sys:trace). Now I just
need to wait for it to crash :-(

/Bruce

----- Original Message -----
From: "Chandrashekhar Mullaparthi"
<Chandrashekhar.Mullaparthi>
To: "'Bruce Fitzsimons'" <Bruce>;
<erlang-questions>
Sent: Monday, December 16, 2002 9:38 PM
Subject: RE: Supervision and Magically Reincarnated Processes


> Do you have sasl running? If so you should get crash reports you can look
at

> using rb. If you want to find out the reason without changing anything, us
> the sys:trace function on your supervisor, you should see the EXIT message
> from the supervised child...
>
> Chandru
>
> -----Original Message-----
> From: Bruce Fitzsimons [mailto:Bruce]
> Sent: 16 December 2002 08:18
> To: erlang-questions
> Subject: Q: Supervision and Magically Reincarnated Processes
>
>
> Hi peoples,
>
> A quick OTP question, I'm using supervisors in my Aplio (Internet Phone)
> server program and I've carefully inserted a bug somewhere that makes one
of
> the processes crash. But I don't get any output about why it has crashed
in
> the error_logger or shell (when I run it that way).
>
> The process that dies is a gen_server (behaviour) and it doesn't execute
its
> terminate(Reason, State) so I guess its just 'EXIT'ing somewhere.
>
> My question is: how can I trap this (preferably sans debugger)?
>
> The supervisor restarts it happily, and works so fast and well that I
wasn't

> even aware it was dying until I started running it in the shell this week.
>
> /Bruce
>
>
>
>
> NOTICE AND DISCLAIMER:
> This email (including attachments) is confidential.  If you have received
> this email in error please notify the sender immediately and delete this
> email from your system without copying or disseminating it or placing any
> reliance upon its contents.  We cannot accept liability for any breaches
of
> confidence arising through use of email.  Any opinions expressed in this
> email (including attachments) are those of the author and do not
necessarily
> reflect our opinions.  We will not accept responsibility for any
commitments
> made by our employees outside the scope of our business.  We do not
warrant
> the accuracy or completeness of such information.
>
>