<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 2011-11-28 14:25, Michal Ptaszek wrote:
    <blockquote
      cite="mid:798666B5-95B9-4777-B150-F4683EE979D6@erlang-solutions.com"
      type="cite">So there is a chance to get it into official
      Erlang/OTP release? :)</blockquote>
    I would say there is a chance ... a small one perhaps. =) <br>
    <br>
    I agree with Kostis. It can be a very handy tool to inspect data in
    a process heap. At OTP (erts-team) we use gdb with plugins to
    inspect erlang process heaps when something goes horribly wrong. So
    it can be very useful.<br>
    <br>
    I am not sure I would allow it in a production beam. If I had my way
    I would remove all tracing as well and only have it in a
    instrumented beam. I've seen production code use tracing to all
    sorts of interesting stuff. Bad practice (tm). It is too powerful. <br>
    <br>
    (That said, I wouldn't really like to debug a live system without
    those tools)<br>
    <br>
    I don't have a decisive opinion atm.<br>
    <br>
    // Björn-Egil<br>
    <br>
    <blockquote
      cite="mid:798666B5-95B9-4777-B150-F4683EE979D6@erlang-solutions.com"
      type="cite">
      <div><br>
        <div>
          <div>On Nov 28, 2011, at 2:05 PM, Björn-Egil Dahlberg wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <div bgcolor="#FFFFFF" text="#000000"> On 2011-11-28 12:11,
              Ahmed Omar wrote:
              <blockquote
cite="mid:CALxv_xZQRM0RGsmCD0pxULmz_yP=2kBgqaKmp0-iEQbTUixPXg@mail.gmail.com"
                type="cite">I like the idea but i'm HORRIFIED about
                people misusing that and actually try to read internal
                states within their programs :D<br>
              </blockquote>
              <br>
              I would put such a function in erts_debug:inspect_heap/1
              instead.<br>
              <br>
              // Björn-Egil<br>
              <br>
              <br>
              <blockquote
cite="mid:CALxv_xZQRM0RGsmCD0pxULmz_yP=2kBgqaKmp0-iEQbTUixPXg@mail.gmail.com"
                type="cite"><br>
                <div class="gmail_quote">On Mon, Nov 28, 2011 at 12:02
                  PM, Michal Ptaszek <span dir="ltr"><<a
                      moz-do-not-send="true"
                      href="mailto:michal.ptaszek@erlang-solutions.com">michal.ptaszek@erlang-solutions.com</a>></span>
                  wrote:<br>
                  <blockquote class="gmail_quote" style="margin:0 0 0
                    .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hey,<br>
                    <br>
                    good point, I knew I forgot about something - will
                    add support for that<br>
                    really soon.<br>
                    <br>
                    Kind regards,<br>
                    <span class="HOEnZb"><font color="#888888">Michal
                        Ptaszek<br>
                      </font></span>
                    <div class="HOEnZb">
                      <div class="h5"><br>
                        On Nov 28, 2011, at 11:02 AM, Attila Rajmund
                        Nohl wrote:<br>
                        <br>
                        > Hello!<br>
                        ><br>
                        > I really like the idea. But shouldn't this
                        list include the message queue too?<br>
                        ><br>
                        > 2011/11/28 Michal Ptaszek <<a
                          moz-do-not-send="true"
                          href="mailto:michal.ptaszek@erlang-solutions.com">michal.ptaszek@erlang-solutions.com</a>>:<br>
                        >> Hi everyone,<br>
                        >><br>
                        >> This idea was born in my mind when
                        debugging some complex, live system<br>
                        >> and trying to figure out where did all
                        my memory go.<br>
                        >><br>
                        >> So, when debugging live
                        system/investigating suspicious memory
                        consumption patterns<br>
                        >> or simply trying to understand better
                        what's going on with our processes, it might be
                        useful<br>
                        >> to take a peep at the data given
                        process operates on.<br>
                        >><br>
                        >> Right now it is possible to fetch
                        internal gen_* processes state via
                        sys:get_status, we can do<br>
                        >> some tracing (even using DTrace), we
                        can also check erlang:process_info output and
                        analyze<br>
                        >> it to become more or less familiar with
                        what is the heap size of our suspect. Still, not
                        all processes<br>
                        >> are OTP-compatible, and even if: we are
                        going to get only "alive" data coming from
                        process' state<br>
                        >> (not counting the outdated, not yet
                        garbage collected terms). Also, process_info
                        informs us only<br>
                        >> about allocated size of the heap, not
                        about the actual usage (although the
                        pre-allocated chunks<br>
                        >> are not available to the system, yet we
                        might see how far we are from growing/shrinking
                        it).<br>
                        >><br>
                        >> Enough with introduction, let's focus
                        on the actual meat: my idea was to create a new
                        BIF,<br>
                        >> namely erlang:inspect_heap(Pid) that
                        allows us to take a look at any process' heap,
                        fetch the<br>
                        >> terms residing there and check their
                        actual size. So, for instance:<br>
                        >><br>
                        >>> (ejabberd@localhost)12> S =
                        erlang:inspect_heap(pid(0, 358, 0)).<br>
                        >>> [{[[<<"5">>]|<br>
                        >>>  
 284735200226724471091958640173737944785062822211005333957298336375301959844499896296764925551414319236776784],<br>
                        >>>   20},<br>
                        >>>  {{'$internal_queue_len',0},3},<br>
                        >>>
                         {{random_seed,{8236,26623,17360}},7},<br>
                        >>>
                         {{'$ancestors',[ejabberd_c2s_sup,ejabberd_sup,<0.40.0>]},9},<br>
                        >>>
                         {{'$initial_call',{gen,init_it,6}},7},<br>
                        >>>  {{state,{socket_state,tls,<br>
                        >>>                      
                         {tlssock,#Port<0.3936>,#Port<0.3938>},<br>
                        >>>                      
                         <0.357.0>},<br>
                        >>>        
 ejabberd_socket,#Ref<0.0.0.10120>,false,<<"2855118401">>,<br>
                        >>>        
                         {sasl_state,"jabber",<<"<a
                          moz-do-not-send="true" href="http://pvp.net/"
                          target="_blank">pvp.net</a>">>,[],<br>
                        >>>                    
 #Fun<ejabberd_c2s.0.67315917>,#Fun<ejabberd_c2s.1.67315917>,<br>
                        >>>                    
                         #Fun<ejabberd_c2s.2.67315917>,cyrsasl_digest,<br>
                        >>>                    
                         {state,5,<<"3598825873">>,<br>
                        >>>                            
                        {<<"dupa">>,<<...>>},<br>
                        >>>                            
                        <<>>,#Fun<ejabberd_c2s.0.67315917>,...}},<br>
                        >>>          true,<br>
                        >>>        
                         {jid,<<"dupa">>,<<"<a
                          moz-do-not-send="true" href="http://pvp.net/"
                          target="_blank">pvp.net</a>">>,<<"hubbard">>,<<"dupa">>,<br>
                        >>>               <<"<a
                          moz-do-not-send="true" href="http://pvp.net/"
                          target="_blank">pvp.net</a>">>,<<"hubbard">>},<br>
                        >>>        
                         <<"Nicknamedupa">>,<br>
                        >>>        
                         {{1322,217197,749816},<0.358.0>},<br>
                        >>>        
                         {1,{<<"dupa">>,nil,nil}},<br>
                        >>>        
                         {1,{<<"dupa">>,nil,nil}},<br>
                        >>>        
                         {1,{<<"dupa">>,nil,nil}},<br>
                        >>>        
                         {xmlelement,<<"presence">>,[],<br>
                        >>>                    
                         [{xmlcdata,<<...>>},{xmlelement,...},{...}|...]},<br>
                        >>>          {userlist,none,[],false}},<br>
                        >>>   564},<br>
                        >>>  {{limits,undefined},3},<br>
                        >>>  {{[],[]},3}]<br>
                        >><br>
                        >> gives us a pretty good knowledge on
                        <0.358.0>:<br>
                        >> • '$_' - OTP + gen_fsm2 process
                        dictionary stuff, 3, 9, 7 words each<br>
                        >> • random_seed - obvious<br>
                        >> • {{limits,undefined},3} - internal
                        limits for gen_fsm2 message queue, 3 words<br>
                        >> • {[], []} - most probably leftovers
                        after fetching user's presence lists<br>
                        >> • {state, _} - gen_fsm2 state record -
                        564 words<br>
                        >> • {[[<<"5">>]|, ...} -
                        sequential tracing tokens? (I'm not very
                        familiar with that, I would<br>
                        >> say that's something from our rootset<br>
                        >><br>
                        >> The implementation is rather simple: if
                        the process we probe is not the caller one (we
                        are not doing<br>
                        >> erlang:inspect_heap(self()), the data
                        is copied from the callee heap to caller heap
                        (to prevent from having<br>
                        >> cross-process references in variables),
                        then we compute flat size of the each term we
                        moved. Also, rootset<br>
                        >> is also included in the summary (i.e.
                        process dict, seq tokens, etc.).<br>
                        >><br>
                        >> Code is included in my inspect_heap OTP
                        branch on:<br>
                        >>  github: <a moz-do-not-send="true"
                          href="https://github.com/paulgray/otp/tree/inspect_heap"
                          target="_blank">https://github.com/paulgray/otp/tree/inspect_heap</a><br>
                        >><br>
                        >> I am still a little bit hesitant about
                        suspending process we probe: can anyone tell<br>
                        >> me if acquiring main process lock would
                        be enough to keep its heap untouched during<br>
                        >> the call?<br>
                        >><br>
                        >> Please, do point any bugs and tell me
                        what do you think about the idea.<br>
                        >><br>
                        >> Best regards,<br>
                        >> Michal Ptaszek<br>
                        >>
                        _______________________________________________<br>
                        >> erlang-questions mailing list<br>
                        >> <a moz-do-not-send="true"
                          href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
                        >> <a moz-do-not-send="true"
                          href="http://erlang.org/mailman/listinfo/erlang-questions"
                          target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
                        >><br>
                        <br>
                        _______________________________________________<br>
                        erlang-questions mailing list<br>
                        <a moz-do-not-send="true"
                          href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
                        <a moz-do-not-send="true"
                          href="http://erlang.org/mailman/listinfo/erlang-questions"
                          target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
                      </div>
                    </div>
                  </blockquote>
                </div>
                <br>
                <br clear="all">
                <div><br>
                </div>
                -- <br>
                Best Regards,<br>
                - Ahmed Omar
                <div><a moz-do-not-send="true"
                    href="http://nl.linkedin.com/in/adiaa"
                    target="_blank">http://nl.linkedin.com/in/adiaa</a></div>
                <div>Follow me on twitter</div>
                <div><a moz-do-not-send="true"
                    href="http://twitter.com/#%21/spawn_think"
                    target="_blank">@spawn_think</a></div>
                <br>
                <br>
                <fieldset class="mimeAttachmentHeader"></fieldset>
                <br>
                <pre wrap="">_______________________________________________
erlang-questions mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
              </blockquote>
              <br>
            </div>
            _______________________________________________<br>
            erlang-questions mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
            <a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>