[erlang-questions] gen_fsm crashes

[Ken Robinson]

Hi All,

I decided to do trace on all the calls in gen_fsm with my state
machine code transport_tx_fsm.erl (which goes from state sending to
sending, it's in the standard I'm implementing).
As I do not have a timeout on the gen_fsm it should used inifinity as
the timeout value on the loop.

Early on it does and enters the loop appropriately:
(<0.92.0>) call
gen_fsm:loop(<0.89.0>,transport_tx_fsm,sending,[],transport_tx_fsm,infinity,[{statistics,{{{2010,6,16},{23,31,51}},{reductions,29},0,0}},
 {log,{10,[]}},
 {trace,true}])
ok

I get it to do some work via a test and then it appears to want to go
back into the loop with the timeout value infinity:
(<0.92.0>) call gen_fsm:handle_msg({'$gen_event',{send,{sendrec,<<"à">>,
 ...

<<1,1>>}}},<0.89.0>,transport_tx_fsm,sending,[],transport_tx_fsm,infinity,[{statistics,{{{2010,6,16},{23,31,51}},
 ...
 {trace,true}])

Unfortunately it appears to crash when the code tries to enter the
loop with the timeout value which is is a tuple:
(<0.92.0>) call
gen_fsm:loop(<0.89.0>,transport_tx_fsm,sending,{send,{sendrec,undefined,undefined,undefined,undefined,undefined,undefined,
               undefined,1,undefined}},transport_tx_fsm,{[],#Fun<transport_tx_fsm.3.17302095>},[{statistics,{{{2010,6,16},{23,31,51}},
...
 {trace,true}])

This appears to cause the error:
=CRASH REPORT==== 16-Jun-2010::23:32:09 ===
  crasher:
    initial call: transport_tx_fsm:init/1
    pid: <0.92.0>
    registered_name: transport_tx_fsm
    exception error: bad receive timeout value
      in function  gen_fsm:loop/7
...

It then restarts using my supervisor.

Is this a known bug or should I add some debug info to better track
down this error? Would adding timeout fix this problem.
Ken.



On Wed, Jun 9, 2010 at 12:12 AM, Ken Robinson <kenrobinsonster@REDACTED> wrote:
> Hi All,
> Inspecting the gen_fsm.erl code from std_lib, it has a main
> loop(Parent, Name, StateName, StateData, Mod, Timeout, Debug) method.
> Appears one can have a bad receive timeout value. Need to now see what
> is a good way to track down that value. I see that Debug has options
> like trace and log. I am now trying to start up the application so
> these Debug options are active.
> Ken.
>
> On Tue, Jun 1, 2010 at 11:55 PM, kenrobinson <kenrobinsonster@REDACTED> wrote:
>> Hi All,
>> This being my first post to this list, please feel free to correct any
>> mistakes I make on the group  etiquette on posts.
>>
>> I am running a supervisor which uses the standard restart strategy.
>> Here is a snippet from my .app file covering the gen_fsm which
>> crashes.
>> <snip>
>>  {transport_tx_fsm, %% tag
>>   {transport_tx_fsm, start_link, []},
>>   permanent,
>>   10000,
>>   worker,
>>   [transport_tx_fsm]},
>> </snip>
>>
>> I start up using the following command line:
>> erl -pa test ebin priv -sname ken1 -boot start_sasl
>>
>> I load using application:load(jaus) and application:start(jaus). It
>> starts correctly.
>>
>> I also load some test code using l(transport_tx_fsm_test) and fire off
>> a message to transport_tx_fsm. Test code is sent to it like so:
>>    gen_fsm:send_event(transport_tx_fsm, {send, SR}),
>>
>> After it crashes, it appears to restart and process the message (see
>> below).
>>
>> My question is what does the bad timeout value signify where I haven't
>> started the gen_fsm with a timeout value?
>> regards,
>> Ken
>>
>> =CRASH REPORT==== 30-May-2010::23:54:53 ===
>>  crasher:
>>    initial call: transport_tx_fsm:init/1
>>    pid: <0.103.0>
>>    registered_name: transport_tx_fsm
>>    exception error: bad receive timeout value
>>      in function  gen_fsm:loop/7
>>    ancestors: [jaus_supervisor,<0.53.0>]
>>    messages: []
>>    links: [<0.61.0>]
>>    dictionary: []
>>    trap_exit: false
>>    status: running
>>    heap_size: 377
>>    stack_size: 24
>>    reductions: 476
>>  neighbours:
>>
>> =SUPERVISOR REPORT==== 30-May-2010::23:54:53 ===
>>     Supervisor: {local,jaus_supervisor}
>>     Context:    child_terminated
>>     Reason:     timeout_value
>>     Offender:   [{pid,<0.103.0>},
>>                  {name,transport_tx_fsm},
>>                  {mfa,{transport_tx_fsm,start_link,[]}},
>>                  {restart_type,permanent},
>>                  {shutdown,10000},
>>                  {child_type,worker}]
>>
>> 23:54:53.896740 2010-05-30 [info] Called init message in
>> transport_tx_fsm
>>
>> 23:54:53.896821 2010-05-30 [info] handle_info udp args
>> ClientSocket #Port<0.1353>
>>  Host         {127,0,0,1}
>> Port         47761
>> Data         <<2,0,128,0,192,3,2,1,0,6,5,64,0,1,1,19,0>>
>> State        {state}
>>
>>
>> =PROGRESS REPORT==== 30-May-2010::23:54:53 ===
>>          supervisor: {local,jaus_supervisor}
>>             started: [{pid,<0.105.0>},
>>                       {name,transport_tx_fsm},
>>                       {mfa,{transport_tx_fsm,start_link,[]}},
>>                       {restart_type,permanent},
>>                       {shutdown,10000},
>>                       {child_type,worker}]
>> 23:54:53.901490 2010-05-30 [info] unwrap arg
>> <<2,0,128,0,192,3,2,1,0,6,5,64,0,1,1,19,0>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>>
>