[erlang-questions] gen_fsm crashes

Ken Robinson <>
Thu Jun 17 16:15:35 CEST 2010


Problem solved. It's me :)
The man page of gen_fsm read in part:
...
If  the function returns {next_state,NextStateName,NewStateData},
{next_state,NextStateName,NewStateData,Timeout} or
{next_state,NextStateName,NewStateData,hibernate}
...

What I was doing was providing 4 instead of 3 parameters which meant
it thought I was now providing a timeout value. Because the value is a
nonsense timeout value (an empty list along with the function), it
comes up with "bad receive timeout value".
Ken.


On Thu, Jun 17, 2010 at 12:36 AM, Ken Robinson
<> wrote:
> 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 <> 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 <> 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:
>>>
>>>
>>
>


More information about the erlang-questions mailing list