<div dir="ltr"><div>Hi Raimo,</div><div><br></div><div>That was indeed the case. Was missing a From in a reply tuple.<br></div><div><br></div><div>I wonder what can be done to make all of this more approachable.</div><div>My memory of working with the gen_fsm is a much more pleasant one when you did errors.</div><div>I can appreciate that stuffing things into the callback return tuples makes things harder, but it goes against one of the best things about OTP: it has always been super easy to find the place in the code where you have messed up.</div><div>With gen_statem I'm not getting the same kind of tranquility as with gen_server and gen_statem.</div><div><br></div><div>I'm wondering if the replies and next_event's should be made explicit calls in the code.</div><div>That way you'd get a line number in your face if you did it wrong.</div><div>And it would simplify the callback return structures quite a bit.</div><div><br></div><div>So {reply, From, Msg} would have to be done with gen_statem:reply/1,2 exclusively and {next_event, Type, EventContent} would need new functions gen_statem:next_event/1,2.</div><div><br></div><div>If the gen_statem:next_event/1,2 was a thing one could do this without removing the complex callback return values.</div><div>Now that I know what pain error in the callback return values cause when debugging I would switch to using them exclusively, if the next_event/1,2 functions were available. I value ease of debugging that much.<br></div><div><br></div><div>Cheers,</div><div>Torben<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 13, 2018 at 3:09 PM Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erix.ericsson.se">raimo+erlang-questions@erix.ericsson.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Jun 13, 2018 at 11:51:31AM +0200, Torben Hoffmann wrote:<br>
> Hi,<br>
> <br>
> I have a crashing gen_statem, but to the best of my knowledge I cannot see<br>
> from the stock error messages which line my gen_statem dies on.<br>
> <br>
> I have searched high and low in my console output, but this is the only<br>
> thing that I could find:<br>
> <br>
> =CRASH REPORT==== 13-Jun-2018::11:17:28 ===<br>
> crasher:<br>
> initial call: eee_sched_shard:init/1<br>
> pid: <0.3149.0><br>
> registered_name: []<br>
> exception error: {badrecord,trans_opts}<br>
> in function gen_statem:loop_event_actions_list/10 (gen_statem.erl,<br>
> line 1210)<br>
<br>
This is an internal crash in gen_statem - I think i recognize this<br>
badrecord at line 1210. Your callback module returns a bad action in the<br>
actions list, and when gen_statem terminates there is a bug that causes it<br>
to crash instead, hiding the informative reason.<br>
<br>
It might be so that you return an action that is not allowed from a state<br>
enter call, or simply a not recognized action.<br>
<br>
Since the error is "cosmetic" or rather "not in the function", I did not<br>
patch this in the 20.3 track. The bad diagnostics error was introduced in<br>
20.3 and is corrected in 21.0-rc1 and forwards.<br>
<br>
<br>
> ancestors: [<0.3148.0>,<0.3114.0>,<0.3107.0>,eee_sched_streams_sup,<br>
> eee_sched_task_sup,eee_sched_sup,<0.2867.0>]<br>
> message_queue_len: 0<br>
> messages: []<br>
> links: [<0.3148.0>]<br>
> dictionary: []<br>
> trap_exit: false<br>
> status: running<br>
> heap_size: 6772<br>
> stack_size: 27<br>
> reductions: 58869<br>
> neighbours:<br>
> <br>
> I'm about to turn on debug mode, but I don't think that that should be the<br>
> answer to this kind of problem. Line numbers should come out by default.<br>
<br>
In this case no line number can be presented since the callback module<br>
returned a bad term, and it is when processing the return value that the<br>
error is discovered. In this case the bad action term should be presented<br>
in the exception error (which it is from 21.0-rc1).<br>
<br>
<br>
> <br>
> Cheers,<br>
> Torben<br>
> -- <br>
> <a href="https://www.linkedin.com/in/torbenhoffmann/" rel="noreferrer" target="_blank">https://www.linkedin.com/in/torbenhoffmann/</a><br>
<br>
<br>
-- <br>
<br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><a href="https://www.linkedin.com/in/torbenhoffmann/">https://www.linkedin.com/in/torbenhoffmann/</a><br></div></div>