[erlang-bugs] Deadlocking application_controller using init:stop/1, 2

[Siri Hansen]

Hi Magnus!

I've started looking at this, and I see that application_controller would
need to handle much more than just load/unload requests in the blocking
receive in order so solve this problem. There are quite a few calls in
application_controller that have the timer set to infinity.

I'm not saying that this can/shall not be done, but I think we need to dig
a bit deeper into the problem before we decide what to do. If it shall be
fixed in the code or if better documentation might be sufficient.

You say that the problem was originally detected while starting the system
and receiving an init:stop via user interaction. Would it be possible to
provide some further details about this? Do you have applications that
load/start/stop other applications?

Regards
/siri@REDACTED



2014-09-05 9:10 GMT+02:00 Magnus Ottenklinger <
magnus.ottenklinger@REDACTED>:

>  Hey List,
>
>
>
> I sent  the following mail yesterday, but it seems that the mail was lost
> in space. Apologies if this reaches you twice.
>
>
>
> Magnus
>
>
>
> -----
>
>
>
> We encountered a deadlock-problem with Erlang’s application mechanism in
> at least R16B01 and OTP 17. Namely, when using init:stop/0,1, a certain
> order of events can deadlock the application_controller, leaving the VM
> running. This can be mitigated using the Kernel application’s
> shutdown_timeout, but we think that this would just be a workaround and not
> a good fix.
>
>
>
> Consider the following simple (and contrived) example:
>
>
>
> -module(simple_app).
>
>
>
> -behaviour(application).
>
>
>
> -export([start/2,
>
>          stop/1]).
>
>
>
> start(_Type=normal, _Args) ->
>
>     {ok,self()}.
>
>
>
> stop(_State) ->
>
>     application:load(crypto), %% yes, this is a bad idea.
>
>     ok.
>
>
>
> Compile and run the example:
>
>
>
> 1> make:all([load]).
>
> up_to_date
>
> 2> application:start(simple).
>
> ok
>
> 3> init:stop().
>
> ok
>
> 4>
>
>
>
> After this, application_controller will wait for simple_app to shutdown,
> whereas simple_app waits for the application_controller. Calls like
> application:which_applications/0 will time out.
>
>
>
> Note that we encountered the problem above in a more complicated setting:
> while starting our system, we received init:stop/0,1 from user interaction
> with the shell. As some processes were still starting up (and calling
> application:load/1 in that process), we got stuck in a VM which could not
> stop itself using init:stop/0,1 anymore.
>
>
>
> I propose that application:load/1,2 (and probably application:unload/1,2
> as well) should return {error,shutting_down} if the application_controller
> is currently shutting down. For this, the application_controller should be
> able to reply to application:load_application/1 within its blocking receive
> in application:terminate/2.
>
>
>
> Of course, as mentioned above, using shutdown_timeout would be possible,
> but that might crash applications unnecessarily when they would be able to
> shutdown nicely.
>
>
>
>
>
> Regards, Magnus
>
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140905/0d87e7a4/attachment.htm>