[erlang-patches] Better printouts from AC in case of errors
Tomas Pihl
tomas@REDACTED
Sun Jan 15 19:38:32 CET 2012
On 15 January 2012 17:18, Tuncer Ayaz <tuncer.ayaz@REDACTED> wrote:
> On Sun, Jan 15, 2012 at 2:16 PM, Tomas Pihl wrote:
>> I got fed up with those pesky little 'Kernel pid terminated' and I
>> couldn't figure out what was going on, so I did some digging in
>> application_master/supervisor and came up with the below patch.
>>
>> As IO for some reason is blocked during these early phases, the use
>> of error_loggger is of no use so instead I send Reason up the chain
>> and let application_controller use it. As can be seen from the below
>> printouts, running with the patch makes it fairly easy to see the
>> problem I'm having here (a missing dependency to SSL).
>>
>> No patch:
>>
>> Erlang R15B (erts-5.9) [source] [smp:8:8] [async-threads:5] [hipe]
>> [kernel-poll:false]
>>
>> =INFO REPORT==== 15-Jan-2012::12:50:15 ===
>> application: topi
>> exited: {shutdown,{topi_app,start,[normal,[]]}}
>> type: permanent
>> {"Kernel pid
>> terminated",application_controller,"{application_start_failure,topi,
>> {shutdown,{topi_app,start,[normal,[]]}}}"}
>>
>> Crash dump was written to: erl_crash.dump
>> Kernel pid terminated (application_controller)
>> ({application_start_failure,topi,{shutdown,{topi_app,start,[normal,[]]}}})
>>
>> And with the patch applied:
>>
>> Erlang R15B (erts-5.9) [source] [smp:8:8] [async-threads:5] [hipe]
>> [kernel-poll:false]
>>
>> =INFO REPORT==== 15-Jan-2012::12:52:34 ===
>> application: topi
>> exited: {{undef,
>> [{ssl,listen,
>> [8043,
>> [inet,
>> .
>> .
>> .
>> type: permanent
>>
>> {"Kernel pid terminated",application_controller,
>> "{application_start_failure,topi,
>> {{undef,[{ssl,listen,[8043,[inet,{ip,{0,0,0,0}},
>> ....
>>
>> Crash dump was written to: erl_crash.dump
>> Kernel pid terminated (application_controller)
>> ({application_start_failure,topi,{{undef,[{ssl,listen,
>> [8043,[inet,{ip,{0,0,0,0}},
>> ...
>
> Looks useful, but what about backward compatibility?
I was a bit worried about that also, but from what I can see, sending
back a {error, term()} to supervisor:start_link/3 is ok and any users
of it handles it just as a Reason which is what they should IMHO. But
I might have overlooked something so your concern is valid but I can't
find anything which might be affected.
/topi
More information about the erlang-patches
mailing list