<div dir="ltr"><div><div><div><div>Hi,<br><br></div><div>We are working on GRiSP (<a href="http://grisp.org">grisp.org</a>) and we are porting the Erlang VM to PowerPC/RTEMS. Everything works fine with 19.3.6 without threading (<span class="gmail-blob-code-inner"><span class="gmail-pl-s">`--disable-threads`</span></span>). But with PLAIN or SMP build of either Erlang 19.3.6 or 20.2 we found a strange scheduling issue. Any hints and ideas on how to debug it would be so greatly appreciated! <br></div><br></div>We have a very simple project to test the issue, it has a single supervisor starting a `proc_lib` worker that stay in a busy loop after calling `proc_lib:init_ack` and a second worker that is a normal `gen_server` doing nothing. The symptom is that the supervisor starts the first worker and never get to start the second one, we never get to the Erlang console. When tracing the supervisor module (with `<span class="gmail-gr_ gmail-gr_2030 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_run_anim gmail-ContextualSpelling" id="gmail-2030">dbg</span>`) we can see it "blocks" on `supervisor:do_start_child`, and when enabling verbose logging with the debug build we can see no processes gets started. This appends all the time, it is 100% reproducible.<br><br></div>What makes us think it is a scheduling issue is that adding `receive after 1 -> ok end` in the busy loop seems to fix the issue and properly start the second process and get us to the Erlang console.<br><br></div><div>Our port of the same code to ARM/RTEMS is working fine, we only have this issue on PowerPC.<br></div><div><br></div><div>We cannot use VM probes because we don't have DTrace on RTEMS, printing debug in `erl_process.c` is probably not a good idea and there is no clear place where to start debugging from with a hardware debugger.<br><br></div><div>Any guidelines, hints or ideas on how to debug this?<br><br></div><div>Thank you very much.<br><br></div><div>Regards,<br></div><div>Sebastien Merle.<br><br></div></div>