Age | Commit message (Collapse) | Author |
|
* john/erts/fix-set-owner-group/ERL-589:
Fix file:change_group/change_owner
|
|
A get_map_elements instruction that has a literal map operand
would never be translated to a i_get_map_element instruction.
That would be a problem for the following instruction:
get_map_elements Fail #{} {x,0}, {x,1}
Since the key is not a literal, get_map_element must be used,
since get_map_elements requires that a hash value can be
calculated for each element.
When the instruction is translated to i_get_map_element, the
hash value will be set to 0 and an assertion will trigger in
the debug build.
|
|
It wasn't possible to change group/owner separately, and our test
suite lacked coverage for that.
ERL-589
|
|
make erlang:process_info/1 not retrieve messages
|
|
Fix typos in erl_nif.xml
|
|
I was running this code in shell and expected it to take default `self()` meta tracer,
and start tracing `erlang:put/2`.
```
F = fun F() -> timer:sleep(5000), erlang:get(unique_field), erlang:put(unique_field, 123), F() end.
erlang:trace_pattern({erlang, put, 2}, [{['$1', '_'], [{'==', '$1', unique_field}], []}], [global]).
erlang:trace_pattern({erlang, get, 1}, [{['_'], [], [{trace, [], [call, timestamp]}]}], [meta]).
Pid = spawn(F).
```
But tracing didn't start:
```
6> flush().
Shell got {trace_ts,<0.70.0>,call,
{erlang,get,[unique_field]},
{1521,118606,753838}}
Shell got {trace_ts,<0.70.0>,call,
{erlang,get,[unique_field]},
{1521,118611,754798}}
Shell got {trace_ts,<0.70.0>,call,
{erlang,get,[unique_field]},
{1521,118616,755705}}
ok
7> erlang:trace_info(Pid, flags).
{flags,[]}
```
Turns out that I had false expectations, that `{trace, _, _}` would enable tracing on that process, inheriting meta tracer process as consumer of trace messages.
Instead it tried to take tracer from executing process (which is pointed out in docs). But there was none, so no tracing was started and flags were simply ignored (which is not that obvious from docs).
Updated docs to point out that there are cases when flags would be simply ignored, and no tracing would start.
|
|
|
|
Conflicts:
OTP_VERSION
|
|
Remove low memory need for HiPE on x86_64
|
|
* rickard/dirty-work-gone/OTP-14978:
Reschedule on ordinary scheduler if dirty work is gone
|
|
|
|
* rickard/pre-alloc-alignment/OTP-14977:
Force 64-bit alignment for pre-allocators unless x86
|
|
|
|
* rickard/remove-approx-started/OTP-14975:
Remove process start time for crash dumps
|
|
* sverker/dict-put-immed-opt:
erts: Optimize erlang:put/2 for hash collision lists
erts: Optimize erlang:put/2 for immed values
erts: Refactor erlang:put/2
|
|
|
|
|
|
|
|
|
|
|
|
* john/erts/tuple-arityval-fixes/OTP-14963/ERL-577:
Make doc entry for maximum tuple size reflect reality
Assert that sz <= MAX_ARITYVAL in make_arityval(sz)
|
|
* john/erts/assert-on-memcpy-memset-etc:
Always use sys_memcpy/cmp/etc instead of plain memcpy/cmp/etc
Check the arguments to sys_memcpy and friends
|
|
|
|
process_info/1 retrieves a number of properties related to a process,
including the list of messages in its mailbox. This is potentially
unsafe if the target process has a large number of queued messages:
- there is no a priori upper bound on the amount of memory being
allocated to hold that list, and
- the loop to retrieve the messages is uninterruptible, so the
Erlang scheduler where this executes blocks for the duration
We've seen process_info/1 bring down heavily loaded nodes on more
than one occasion. At least once it appeared to have blocked the
Erlang heart process from executing, causing the external heart to
kill the VM.
Consequently this removes 'messages' from the list of process_info
tags to retrieve for process_info/1. Note that process_info/1 still
retrieves 'message_queue_len', and process_info/2 can still retrieve
'messages' when asked to.
A few places in the OTP libraries need minor adjustments, since they
want 'message_queue_len' but compute it from the length of the list
of messages.
|
|
|
|
|
|
|
|
|
|
Passing NULL is undefined behavior and unconditionally executing these
may result in the compiler optimizing away a later NULL check. It can
often work since the pointer isn't touched when the length is 0, but
it's a major footgun. See ERL-573.
|
|
|
|
Bug introduced in commit fbb10ebc4a37555c7ea7f99e14286d862993976a
|
|
* lukas/erts/erl_child_setup_ignore_SIGTERM/OTP-14943:
erts: Ignore SIGTERM in erl_child_setup
|
|
Cleanup erlang:system_info docs
|
|
* rickard/psflgs/OTP-14948:
Replace usage of ERTS_PSFLG_BOUND
Remove ERTS_PSFLG_ON_HEAP_MSGQ
|
|
* raimo/stop-encouraging-v4-mapped/ERL-503/OTP-13716:
Stop translating V4MAPPED addresses
Stop returning V4MAPPED addresses
Implement function for IPv4-mapped IPv6 addresses
|
|
Instead of rebuilding all cons cells before key,
just unlink key cell from list with a destructive heap write op.
This is safe as these lists never leak out and any new-to-old-heap-refs
are preserved.
|
|
No longer need for super carrier allocating executable memory.
|
|
|
|
|
|
|
|
|
|
* john/erts/efile_SUITE-iter-max-files-stability:
Make efile_SUITE:iter_max_files more stable
|
|
with link to ! operator
and clarify ugly badarg for unregistered atom argument.
|
|
|
|
Just to simplify and get 4 distinctive states
IDLE, PENDING, CONNECTED and EXITING.
The old possible flag combos were:
0
PENDING
CONNECTED
CONNECTED|EXITING
EXITING
The two EXITING states did not serve any purpose
other then as a slight optimization in monitor_node(_,false,_)
to shortcut EXITING when there can be no monitors.
|
|
to only transcode if output buffer actually contains
unsupported BIT_BINARY_EXT or EXPORT_EXT.
|
|
to replace DFLAGS_STRICT_ORDER_DELIVERY
and remove that compile time dependency.
|
|
for kernel to ask erts about distribution flags
and keep this info in one place.
|
|
Attempt to make the system_info docs easier to navigate
by grouping items of similar themes together in the documentation.
|
|
This is a fix for a bug introduced in 22cde2bda
|