<div dir="ltr">Apparently I wasn't clear enough. You want to look at the 'exiting' trace flag, not the 'procs' flags. i.e. see this code:<div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace">go() -><br></font><font face="monospace, monospace">    TFun = fun TFun() -><br></font><font face="monospace, monospace">                   receive<br></font><font face="monospace, monospace">                       Other -><br></font><font face="monospace, monospace">                           io:format("~p~n",[Other]),<br></font><font face="monospace, monospace">                           TFun()<br></font><font face="monospace, monospace">                   end<br></font><font face="monospace, monospace">           end,<br></font><font face="monospace, monospace">    TPid = spawn(TFun),<br></font><font face="monospace, monospace">    erlang:trace(self(), true, [set_on_spawn, procs, exiting, {tracer, TPid}]),<br></font><font face="monospace, monospace">    Pid = spawn(fun loop/0),<br></font><font face="monospace, monospace">    timer:sleep(100),<br></font><font face="monospace, monospace">    exit(Pid, die).</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">loop() -><br></font><font face="monospace, monospace">    [ets:new(hej,[]) || _ <- lists:seq(1,100)],<br></font><font face="monospace, monospace">    receive after infinity -> ok end.</font></blockquote><div><br></div><div>when you run Mod:go() you will get a bunch of printouts:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace">1> trace:go().</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.33.0>,spawn,<0.36.0>,{erlang,apply,[#Fun<trace.1.87118278>,[]]}}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,in_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,exit,die}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">true</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,out_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,in_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,out_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,in_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,out_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,in_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,out_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,in_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,out_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,in_exiting,0}</font><font face="monospace, monospace"><br></font><font face="monospace, monospace">{trace,<0.36.0>,out_exited,0}</font></blockquote><div><br></div><div>as you can see, the 'exit' trace message is sent relatively early, but the heap of the process is not cleaned up until when the 'out_exited' trace message is sent. In my example the process gets all of these extra schedules after it has decided to die in order to clean up the ets tables that is responsible for. There are a bunch of reasons why this may happen, not just ets table cleanup. What the reason is cannot be observed without instrumenting the vm. </div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 9:05 PM, Roger Lipscombe <span dir="ltr"><<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Assuming I'm tracing correctly (see below), that's not the cause. I<br>
see the 'exit' trace events fairly soon after the process dies, but I<br>
don't see the resource destructor being called until later, and<br>
usually in a clump:<br>
<br>
Alloc wrapper resource 0x2b038eb01620<br>
sup <0.2167.0> spawned <0.3013.0><br>
Alloc wrapper resource 0x2b038ec80328<br>
<0.3013.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.3049.0><br>
Alloc wrapper resource 0x2b038ec801e0<br>
Free wrapper resource 0x2b038ec80328<br>
Free wrapper resource 0x2b038eb01620<br>
<0.3049.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.15256.0><br>
Alloc wrapper resource 0x2b038ea80c70<br>
<0.15256.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.17734.0><br>
Alloc wrapper resource 0x2b038eac7de0<br>
<0.17734.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.18825.0><br>
Alloc wrapper resource 0x2b038eb48098<br>
<0.18825.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.19267.0><br>
Alloc wrapper resource 0x2b038eb00260<br>
<0.19267.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.19616.0><br>
Alloc wrapper resource 0x2b038ea80b88<br>
<0.19616.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.20068.0><br>
Alloc wrapper resource 0x2b038eac2930<br>
<0.20068.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.20424.0><br>
Alloc wrapper resource 0x2b038eac1328<br>
<0.20424.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.20649.0><br>
Alloc wrapper resource 0x2b038eac2aa0<br>
<0.20649.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.20663.0><br>
Alloc wrapper resource 0x2b038ea84118<br>
Free wrapper resource 0x2b038eac2aa0<br>
Free wrapper resource 0x2b038eac1328<br>
Free wrapper resource 0x2b038eac2930<br>
Free wrapper resource 0x2b038ea80b88<br>
Free wrapper resource 0x2b038eb00260<br>
Free wrapper resource 0x2b038eb48098<br>
Free wrapper resource 0x2b038eac7de0<br>
Free wrapper resource 0x2b038ea80c70<br>
Free wrapper resource 0x2b038ec801e0<br>
<0.20663.0> exit {timeout,moo}<br>
sup <0.2167.0> spawned <0.20679.0><br>
Alloc wrapper resource 0x2b038ea80b88<br>
<br>
The "... wrapper resource ..." lines are from the NIF; the other lines<br>
are from tracing:<br>
<br>
SupPid = whereis(agents_sup).<br>
<br>
TFun = fun TFun(State) -><br>
        receive<br>
            {trace, ByPid, spawn, Pid, _} when ByPid =:= SupPid -><br>
                io:format("sup ~p spawned ~p~n", [ByPid, Pid]),<br>
                State2 = [Pid | State],<br>
                TFun(State2);<br>
            {trace, Pid, exit, Reason} = M -><br>
                case lists:member(Pid, State) of<br>
                    true -><br>
                        io:format("~p exit ~p~n", [Pid, Reason]);<br>
                    _ -><br>
                        ok<br>
                end,<br>
                TFun(State);<br>
            Other -><br>
                TFun(State)<br>
        end<br>
    end.<br>
TPid = spawn(fun() -> TFun([]) end).<br>
erlang:trace(all, true, [procs, {tracer, TPid}]).<br>
<div class=""><div class="h5"><br>
<br>
On 15 July 2016 at 15:53, Lukas Larsson <<a href="mailto:garazdawi@gmail.com">garazdawi@gmail.com</a>> wrote:<br>
> How do you know when the process dies?<br>
><br>
> If you aren't already you should use the trace flag 'exiting'<br>
> (<a href="http://erlang.org/doc/man/erlang.html#trace-3" rel="noreferrer" target="_blank">http://erlang.org/doc/man/erlang.html#trace-3</a>) to figure out when a process<br>
> actually has died. ERTS will delay process death after you send it a<br>
> termination signal for various reasons.<br>
><br>
> On Fri, Jul 15, 2016 at 4:39 PM, Roger Lipscombe <<a href="mailto:roger@differentpla.net">roger@differentpla.net</a>><br>
> wrote:<br>
>><br>
>> Sorry, let me rephrase: they're not garbage collected *when* that<br>
>> process dies. The destructor is sometimes called immediately, and<br>
>> sometimes at some point in the future. Can I make this deterministic?<br>
>><br>
>> And, no, the resource has not been sent to another process or stored in<br>
>> ETS.<br>
>><br>
>> On 15 July 2016 at 15:10, Sergej Jurečko <<a href="mailto:sergej.jurecko@gmail.com">sergej.jurecko@gmail.com</a>> wrote:<br>
>> ><br>
>> > On 15 Jul 2016, at 15:57, Roger Lipscombe <<a href="mailto:roger@differentpla.net">roger@differentpla.net</a>><br>
>> > wrote:<br>
>> ><br>
>> > because they're not garbage collected when that<br>
>> > process dies.<br>
>> ><br>
>> ><br>
>> > Then there is an outstanding reference to the resource. Has it been sent<br>
>> > to<br>
>> > another process or stored in an ETS?<br>
>> ><br>
>> ><br>
>> > Sergej<br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div></div>