[erlang-questions] Differences between erlang:system_profile and erlang:trace

Björn-Egil Dahlberg <>
Tue Jan 17 10:16:01 CET 2012


This seemed to work but the correction had an uncaught lock order violation
(!). A correction of the correction is in opu and will be merged to maint
(r15b01-dev) later this week.

// Björn-Egil

Den 6 januari 2012 00:52 skrev Björn-Egil Dahlberg <
>:

> Hopefully it will now work as intended.
>
> I should probably sent a mail but I forgot. Getting a lot of those these
> days.
>
> Give me a shout if something seems amiss.
>
> // Björn-Egil
>
> Den 5 januari 2012 23:53 skrev Magnus Klaar <>:
>
> Hi!
>>
>> As far as i can tell, this is fixed in
>> https://github.com/erlang/otp/commit/195be9a44f2481b9c575c8ad286f4d2278b831b3,
>> thanks.
>>
>> MVH Magnus
>>
>>
>> 2012/1/3 Björn-Egil Dahlberg <>
>>
>>>  From what I remember (trying to recall something written five years
>>> ago) system_profile used to respect this policy but from looking at the
>>> code it seems like it doesn't now. The tracing and scheduler queues has
>>> been rewritten several times since then and it is possible that something
>>> has been lost.
>>>
>>> I will have a look at it. Thank you for reporting this.
>>>
>>> Regards,
>>> Björn-Egil
>>>
>>>
>>> On 2012-01-03 01:37, Magnus Klaar wrote:
>>>
>>> Hi!
>>>
>>>  I'm seeing a strange behavior when using erlang:system_info/2 to trace
>>> the running processes on an erlang node. I know it's flagged as
>>> experimental so I will assume it's actually a feature even if the
>>> documentation does not agree. When a process is used to receive the profile
>>> messages from erlang:system_info/2 the receiving process is also profiled.
>>> The effect of this is that the process receiving the profile messages will
>>> receive an infinite sequence of 'inactive' ... 'active' ... 'inactive' ....
>>> messages from the runtime system. The manpage states that the "The
>>> receiver is excluded from all profiling.". I've compared this with using
>>> the erlang:trace/3 function to trace running processes, when this function
>>> is used the tracer processes never receives a message when the tracer
>>> process scheduled.
>>>
>>>  Two eunit tests for showing the difference:
>>> https://gist.github.com/1552673
>>>
>>>  Running "erl -noshell -s system_profile test -s init stop" on my
>>> system yields the following result:
>>>
>>>
>>>  system_profile.erl:30:<0.35.0>: Total: 525169, For tracer: 524824, For
>>> others: 345
>>>
>>>  system_profile:13: system_profile_test_...*failed*
>>> ::{assertion_failed,[{module,system_profile},
>>>                    {line,32},
>>>                    {expression,"SelfCount =:= 0"},
>>>                    {expected,true},
>>>                    {value,false}]}
>>>
>>>
>>>  system_profile.erl:58:<0.123.0>: Total: 338, For tracer: 0, For
>>> others: 338
>>>
>>>  =======================================================
>>>   Failed: 1.  Skipped: 0.  Passed: 1.
>>>
>>>
>>>  My questions are: Am I using it wrong? If so, how should it be used?
>>> If not, Is it a bug?
>>>
>>>  MVH Magnus
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing ://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> 
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120117/e76ab2ab/attachment.html>


More information about the erlang-questions mailing list