[erlang-questions] gen_fsm crashes
Ken Robinson
kenrobinsonster@REDACTED
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
<kenrobinsonster@REDACTED> 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 <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
>>>
>>>
>>
>
More information about the erlang-questions
mailing list