<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>