不要忽略任何一个错误提示，更要找到原因linked websocket controlling loop crashed with reason: kille

 

开发程序的时候，好几次都看到后台打出下面的错误日志。 但一直重现不了。

 

=ERROR REPORT==== 20-Feb-2013::14:07:56 ===

        module: misultin_websocket

        line: 243

linked websocket controlling loop crashed with reason: killed

 

 

直到昨天再测试程序时，突然发现页面报出close提示，我以为是timeout关闭的，查看了一下时间戳和日志，发现不是超市引起。但正好看到上面错误 log。也没发现什么直接关系。

这时候我留意到ws_session(用来存储用户与ws之间的关系)中的记录也没有清除，这就证明是进程意外退出引起的。

反复实验发现，不论建立了多少个websocket连接。只要执行两次http请求所有的连接都会报出close错误。同时日志记录linked websocket controlling loop crashed with reason: killed。这下重现了此错误。回想了一下，以前的token超时，丢失用户消息都很可能与此有着间接的关系。

这个问题比较严重，花了几个小时。一步步跟踪代码才发现。 每次http请求都会执行下面两句话。

 63             Result = code:purge(Module1),  

 65             case code:load_binary(Module1, File, Bin) of

 

OK，找到问题了

purge(Module) -> boolean()

Types:

Module = module()

 

 

Purges the code for Module, that is, removes code marked as old. If some processes still linger in the old code, these processes are killed before the code is removed.

            Returns true if successful and any process needed to be killed, otherwise false.

 

 

load_binary(Module, Filename, Binary) ->
               {module, Module} | {error, What}

Types:

Module = module()

Filename = loaded_filename()

Binary = binary()

What = badarg | load_error_rsn()

loaded_filename() = (Filename :: file:filename())
                  | loaded_ret_atoms()

loaded_ret_atoms() = cover_compiled | preloaded

 

 

This function can be used to load object code on remote Erlang nodes. The argument Binary must contain object code for Module. Filename is only used by the code server to keep a record of from which file the object code for Module comes. Accordingly, Filename is not opened and read by the code server.

Returns {module, Module} if successful, or {error, sticky_directory} if the object code resides in a sticky directory, or {error, badarg} if any argument is invalid. Also if the loading fails, an error tuple is returned. See erlang:load_module/2 for possible values of What.