[erlang-questions] Change in Semantics in dbg:c ?

[Raimo Niskanen]

On Sun, Sep 07, 2008 at 11:02:42AM +0100, Francesco Cesarini wrote:
> I was working through some old training material from 2001, testing the 
> output on R12. I am getting significantly different behaviours 
> in-between the releases which I was not expecting.
> 
> The example I use (Attached to the mail) spawn_links a process which 
> goes into a receive loop. When the child receives a ping message, it 
> spawns a new process which immediately fails with reason undef and loops 
> on itself.
> 
> In the older release (Probably R9), tracing a function which does a 
> spawn_link using dbg:c/4 setting the process trace flags and the set on 
> spawn flags, I get all of the events and set on spawn works. More calls 
> using dbg:c affecting the child process obviously demonstrate that the 
> child inherited the trace flags.
> 
> Using R12, first thing I get is an unlinked trace event. Subsequent 
> messages to the process do not generate any new trace events. In R12 
> (possibly earlier), a quick look confirms my suspicions; an intermediate 
> process has been inserted between the shell and the child, and when this 
> process terminates, the unlink event is generated. Is this the intended 
> behaviour? I would say the old behaviour is the correct one, as the 
> documentation states that dbg:c/4 it is a traced variant of apply/3. If 
> so, the unlink trace message should not be received, and the state (sos 
> and sofl trace flags) should be maintained in-between calls. Either way, 
> either the documentation is incorrect or the intermediary process should 
> be removed. Which version would you like documented in the book?
:

Well, which behaviour do you actually prefer? It changed from R8B to R9B-1
on request from guess who...

You!

Francesco wrote:
> When using c/4, the documentation states that it is useful 
> when running from the shell?. Should all the shell internal 
> messages not be hidden, however? Isn?t it better to spawn a 
> new process and execute it there, stopping the trace flags 
> b4 returning the result?

>From the R9B-1 release notes:
=========
Runtime_tools 1.3
Fixed errors and malfunctions

    * dbg:p/2 always returns error (i.e. does not crash) if faulty flag
      is given. Also dbg:c/4 now executes on a separate process and
      internal messages are no longer traced.
      (Own Id: OTP-4111)
      (Aux Id: Seq7131)
=========



Since the same release all dbg trace is stopped at the end of
dbg:c/4 so no dbg server is running any more. This may seem
drastic, but it was a separate change made just after
your suggested intermediate process change, so I guess
there is a very good reason.

So it seems dbg:c/4 now is designed to only trace exactly
what you give to it and nothing after. This and that
an intermediate process is used should be
clearer in the documentation.



:
> Suggestions?
> 
> Regards,
> Francesco



If you try for example this example:
-module(ping).
-export([run/0]).

run() ->
    Wait = fun() ->
            receive
                {Pid, ping} ->
                    spawn(crash, do_not_exist, []),
                    Pid ! pong
            end
        end,
    Pid = spawn_link(Wait),
    Pid ! {self(), ping},
    receive
        pong ->
            receive after 100 -> ok end,
            pong
    end.



It all looks rather nice...



Erlang (BEAM) emulator version 5.6.4 [source] [64-bit] [smp:4] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.6.4  (abort with ^G)
1> dbg:c(ping, run, [], [p,sos]).
(<0.35.0>) spawn <0.36.0> as erlang:apply(#Fun<ping.0.85678494>,[])
(<0.35.0>) link <0.36.0>
(<0.36.0>) spawn <0.37.0> as crash:do_not_exist()
(<0.36.0>) exit normal
(<0.35.0>) getting_unlinked <0.36.0>
(<0.37.0>) exit {undef,[{crash,do_not_exist,[]}]}

=ERROR REPORT==== 8-Sep-2008::15:59:39 ===
Error in process <0.37.0> with exit value: {undef,[{crash,do_not_exist,[]}]}

pong



-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB