[erlang-questions] spawn_link - zombie

[tom kelly]

Hi List,

I'm debugging a weird problem here on a customer site. We have an
application that accepts tcp connections then kicks off a gen_server
to implement some session logic, part of which is starting up a socket
handler, which is also a gen_server, that provides a customised
interface to the tcp connection. So after the init stage we have two
linked processes.

In my test environment both processes get tidied up correctly, when we
get a tcp_closed from the connection or when we tell the session
process to shut down. But on this customer site I'm seeing thousands
of zombie socket_handlers, and they're causing us to hit a
system_limit when we get new connections. I haven't managed to
reproduce this state in my test environment yet but suspect it's
happening in the init phase.

Not sure if I've reproduced the cause of my problem here but I have
this simple testcase that might help me if I can understand it. This
spawns a process that spawns a process, if the parent process lives a
while (comment in the 2nd sleep) then everything's as expected with
two linked processes, with the parent linked to the shell process. But
in this case if the parent terminates straight away the child will
survive as an unlinked zombie, even though it was started with
spawn_link, where I'd expect it to terminate too.

Is this a bug or are my expectations incorrect? And any explanation
much appreciated!


70>
70> self().
<0.126.0>
71>
71>
71> spawn_link(fun() -> io:format("~n~nP1: ~p~n~n",[self()]),
                        spawn_link(fun() -> io:format("~n~nP2:
~p~n~n",[self()]),
                                            timer:sleep(300000)
                                   end)%,
                        %timer:sleep(300000)
               end).


P1: <0.137.0>

<0.137.0>


P2: <0.138.0>

72>
72>
72> process_info(erlang:list_to_pid("<0.137.0>"),links).
                           undefined
73>
73>
73> process_info(erlang:list_to_pid("<0.138.0>"),links).
{links,[]}
74>
74>
74>


//TTom.