| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* kvakvs/erts/monitor_port/OTP-11384:
erts: Add port monitors
|
|
* erlang:monitor/2 with port argument is added, erlang:demonitor, using port task API and avoiding locking;
* port_info and process_info support for monitored ports (with named port monitors support);
* Exit signals contain type 'process' or 'port';
* Propagation of port exit signals;
* Self-cleaning when origin process dies with monitor on;
* 8 test cases + testcase for port driver crashing;
* Documentation for all of the above (monitor, demonitor, port_info and process_info) updated
|
|
|
|
|
|
* saleyn/uds/PR-612/OTP-13572:
AF_UNIX is more portable
|
|
Fix dialyzer warning for improper list in prim_inet
by not using an improper list.
|
|
* saleyn/uds/PR-612/OTP-13572:
Rewrite inet* for address family 'local'
Rewrite inet_drv for AF_LOCAL
Assign externally open fd to gen_tcp (UDS support)
Conflicts:
erts/preloaded/ebin/prim_inet.beam
lib/kernel/doc/src/gen_tcp.xml
lib/kernel/doc/src/gen_udp.xml
lib/kernel/src/inet6_sctp.erl
lib/kernel/test/inet_SUITE.erl
|
|
|
|
* rickard/rt-dep-erts-kernel-stdlib-sasl:
Bumped runtime dependencies between erts, kernel, stdlib, sasl
|
|
Removed in f9cb80861f169743 when changed impl from C to Erlang.
But seems they are needed to keep dialyzer tests happy.
Also improved bif_SUITE:shadow_comments to include all exported
in module erlang, not just the "snifs".
...which detected that apply/2 was missing Shadowed comment as well.
|
|
|
|
|
|
|
|
* rickard/rm-mqd-mixed/OTP-13366:
Remove the 'message_queue_data' option 'mixed'
|
|
|
|
|
|
as erlang:halt does it for us now
|
|
just to make things simpler.
|
|
The extra trace data has been moved to the opts map in order
for the tracer to be able to distinguish inbetween extra
trace data 'undefined' and no extra trace data. In the same
commit all opts associations have been changed so that if
the tracer should not use them, the key is left unassicated
instead of being sent to undefined. This should be give a
small performance gain and also makes the API easier to work
with.
|
|
|
|
A bad directory in the path would prevent the run-time system
from starting:
$ echo >foobar
$ erl -pa foobar
{"init terminating in do_boot",{load_failed,[supervisor,kernel,gen_server,file_io_server,filename,file,erl_parse,error_logger,code_server,erl_lint,proc_lib,code,application_controller,application_master,gen_event,application,error_handler,lists,heart,gen,file_server,ets,erl_eval]}}
Crash dump is being written to: erl_crash.dump...done
init terminating in do_boot ()
The reason is that when attempting to read each of the BEAM files,
there would be an 'enotdir' error which
erl_prim_load:get_modules/2,3 assumed was a fatal error.
Update erl_prim_load:get_modules/2,3 to ignore any error and try
the next directory in the path.
Reported-by: http://bugs.erlang.org/browse/ERL-142
Reported-by: Michael Truog
|
|
* lukas/trace-fix:
erts: Only allow remove from trace_status callback
|
|
Make it so that it is only possible to remove a tracer via
returning remove from an erl_tracer. This limition is put in
place in order to avoid a lot of lock checking and taking
in various places, especially in regards to trace events
happening on dirty schedulers.
|
|
|
|
The max_heap_size process flag can be used to limit the
growth of a process heap by killing it before it becomes
too large to handle. It is possible to set the maximum
using the `erl +hmax` option, `system_flag(max_heap_size, ...)`,
`spawn_opt(Fun, [{max_heap_size, ...}])` and
`process_flag(max_heap_size, ...)`.
It is possible to configure the behaviour of the process
when the maximum heap size is reached. The process may be
sent an untrappable exit signal with reason kill and/or
send an error_logger message with details on the process
state. A new trace event called gc_max_heap_size is
also triggered for the garbage_collection trace flag
when the heap grows larger than the configured size.
If kill and error_logger are disabled, it is still
possible to see that the maximum has been reached by
doing garbage collection tracing on the process.
The heap size is defined as the sum of the heap memory
that the process is currently using. This includes
all generational heaps, the stack, any messages that
are considered to be part of the heap and any extra
memory the garbage collector may need during collection.
In the current implementation this means that when a process
is set using on_heap message queue data mode, the messages
that are in the internal message queue are counted towards
this value. For off_heap, only matched messages count towards
the size of the heap. For mixed, it depends on race conditions
within the VM whether a message is part of the heap or not.
Below is an example run of the new behaviour:
Eshell V8.0 (abort with ^G)
1> f(P),P = spawn_opt(fun() -> receive ok -> ok end end, [{max_heap_size, 512}]).
<0.60.0>
2> erlang:trace(P, true, [garbage_collection, procs]).
1
3> [P ! lists:duplicate(M,M) || M <- lists:seq(1,15)],ok.
ok
4>
=ERROR REPORT==== 26-Apr-2016::16:25:10 ===
Process: <0.60.0>
Context: maximum heap size reached
Max heap size: 512
Total heap size: 723
Kill: true
Error Logger: true
GC Info: [{old_heap_block_size,0},
{heap_block_size,609},
{mbuf_size,145},
{recent_size,0},
{stack_size,9},
{old_heap_size,0},
{heap_size,211},
{bin_vheap_size,0},
{bin_vheap_block_size,46422},
{bin_old_vheap_size,0},
{bin_old_vheap_block_size,46422}]
flush().
Shell got {trace,<0.60.0>,gc_start,
[{old_heap_block_size,0},
{heap_block_size,233},
{mbuf_size,145},
{recent_size,0},
{stack_size,9},
{old_heap_size,0},
{heap_size,211},
{bin_vheap_size,0},
{bin_vheap_block_size,46422},
{bin_old_vheap_size,0},
{bin_old_vheap_block_size,46422}]}
Shell got {trace,<0.60.0>,gc_max_heap_size,
[{old_heap_block_size,0},
{heap_block_size,609},
{mbuf_size,145},
{recent_size,0},
{stack_size,9},
{old_heap_size,0},
{heap_size,211},
{bin_vheap_size,0},
{bin_vheap_block_size,46422},
{bin_old_vheap_size,0},
{bin_old_vheap_block_size,46422}]}
Shell got {trace,<0.60.0>,exit,killed}
|
|
|
|
to obtain match specs
|
|
|
|
|
|
* egil/erts/tracing-support-lttng/OTP-13532: (28 commits)
runtime_tools: User's guide to LTTng and dyntrace
runtime_tools: Fix Dtrace build
erts: Fix gc messages in tracer_SUITE
erts: Fix gc messages in sensitive_SUITE
erts: Fix gc messages in trace_port_SUITE
tools: Update fprof tests
tools: Update fprof with new gc traces
runtime_tools: Update dyntrace_lttng_SUITE tests
runtime_tools: Add 'return_to' for call tracing
erts: Fix return_to trace callback
erts: Update erl_tracer documentation
erts: Fix erl_tracer documentation typos
Update preloaded erl_tracer.beam
erts: Update erl_tracer type specs
runtime_tools: Add lttng dyntrace tests
runtime_tools: Extend 'trace' and 'enabled' tracer callbacks
erts: Extend 'enabled' and 'trace' tracer callbacks
runtime_tools: Extend 'enabled' tracer callbacks
erts: Extend 'enabled' tracer callbacks
runtime_tools: Update lttng garbage collection trace
...
|
|
|
|
|
|
Using the new type syntax, we can specify which keys are required, and
which are optional in a way Dialyzer could use.
|
|
|
|
Usage: erl -profile_boot ...
|
|
|
|
OTP-13501
|
|
OTP-13497
This trace event is triggered when a process is created from the
process that is created.
|
|
This commit completes the tracing for processes so that
all messages sent by a process (via nifs or otherwise) will
be traced.
The commit also adds tracing of all types of events from ports.
When enabling tracing using erlang:trace, the 'all' flag now also
enables tracing on all ports.
OTP-13496
|
|
Add the possibility to use modules as trace data receivers. The functions
in the module have to be nifs as otherwise complex trace probes will be
very hard to handle (complex means trace probes for ports for example).
This commit changes the way that the ptab->tracer field works from always
being an immediate, to now be NIL if no tracer is present or else be
the tuple {TracerModule, TracerState} where TracerModule is an atom that
is later used to lookup the appropriate tracer callbacks to call and
TracerState is just passed to the tracer callback. The default process and
port tracers have been rewritten to use the new API.
This commit also changes the order which trace messages are delivered to the
potential tracer process. Any enif_send done in a tracer module may be delayed
indefinitely because of lock order issues. If a message is delayed any other
trace message send from that process is also delayed so that order is preserved
for each traced entity. This means that for some trace events (i.e. send/receive)
the events may come in an unintuitive order (receive before send) to the
trace receiver. Timestamps are taken when the trace message is generated so
trace messages from differented processes may arrive with the timestamp
out of order.
Both the erlang:trace and seq_trace:set_system_tracer accept the new tracer
module tracers and also the backwards compatible arguments.
OTP-10267
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
|
|
|
|
|
|
Use erlang:prepare_loading/1 and erlang:finish_loading/1 to load
modules in parallel to potentially decrease start-up times.
|
|
|
|
fetch_loaded/1 returns a list of tuples, not a list of atoms.
|
|
|
|
- The calling process is now suspended while synchronizing
scheduler suspends via erlang:system_flag(schedulers_online, _)
and erlang:system_flag(multi_scheduling, _), instead of blocking
the scheduler thread in the BIF call waiting for the operation
to synchronize. Besides releasing the scheduler for other work
(or immediate suspend) it also makes it possible to abort the
operation by killing the process.
- erlang:system_flag(schedulers_online, _) now only wait for normal
schedulers to complete before it returns. This since it may take
a very long time before all dirty schedulers suspends.
- erlang:system_flag(multi_scheduling, block_normal|unblock_normal)
which only operate on normal schedulers has been introduced. This
since there are use cases where suspend of dirty schedulers are
not of interest (hipe loader).
- erlang:system_flag(multi_scheduling, block) still blocks all
dirty schedulers as well as all normal schedulers except one since
it is hard to redefine what multi scheduling block means.
- The three operations:
- changing amount of schedulers online
- blocking/unblocking normal multi scheduling
- blocking/unblocking full multi scheduling
can now be done in parallel. This is important since otherwise
a full multi scheduling block would potentially delay the other
operations for a very long time.
|
