gen_statem badrecord,trans_opts

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

gen_statem badrecord,trans_opts

getonga
my own gen_statem module crash with this error msg:
```
Context:    child_terminated
Reason:     {{badrecord,trans_opts},[{gen_statem,loop_event_actions_list,10,[{file,"gen_statem.erl"},{line,1210}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]}

```
I recheck my code many times, and not found any error in my return state. And the module runs for a long time, a week or some more, and this error happens for only two times.
My erlang version is 20.3.6, and my production environment is that, could you merge 3ed7d729cab697b9f668dadb563d629de10f593d into branch 20?
erlang 21 is now rc1, I can not put 21 into production now.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: gen_statem badrecord,trans_opts

Raimo Niskanen-2
On Thu, May 10, 2018 at 09:18:29AM +0800, getonga wrote:

> my own gen_statem module crash with this error msg:
> ```
> Context:    child_terminated Reason:
>   {{badrecord,trans_opts},
>    [{gen_statem,loop_event_actions_list,10,
>      [{file,"gen_statem.erl"},{line,1210}]},
>     {proc_lib,init_p_do_apply,3,
>      [{file,"proc_lib.erl"},{line,247}]}]}
> ```
> I recheck my code many times, and not found any error in my return state.
> And the module runs for a long time, a week or some more, and this error happens
> for only two times. My erlang version is 20.3.6, and my production environment
> is that, could you merge 3ed7d729cab697b9f668dadb563d629de10f593d
> into branch 20?erlang 21 is now rc1, I can not put 21 into production now.

What I can read and remember from commit 3ed7d72 is that when gen_statem is
about to terminate due to a parse error of the Actions list it instead
crashes because the TransOpts variable is in this case not a record.  The
commit fixes the crash to become a proper server termination.

But the root cause should be a bad Action in the Actions list.

The rest of the commit tightens parsing of timeout actions so that some
erroneous actions that previously slipped through now fails the argument
parsing.  In particular the first element of a timeout tuple:
    {TimeoutType,Time,Msg} | {TimeoutType,Time,Msg,Opts}
Here TimeoutType may be 'timeout' | 'state_timeout' | {'timeout',_} but
that was not checked before this commit so misspelled timers worked, hence
{AnyTerm,Time,Msg} would before this commit start a timeout.

So I would think there is some erroneous timeout action returned from your
callback module, and that merging this commit into the 20 track will not
really help, just improve the server termination and diagnostics...

Can you apply that commit yourself and tell me what happens?

Best Regards
--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions