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

[Magnus Ottenklinger]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140905/99b30486/attachment.htm>