| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
* john/erts/fix-dirty-reschedule-bug/OTP-15154:
Move to a dirty scheduler even when we have pending system tasks
|
|
* john/erts/fix-21.0.2-release-notes:
Fix release notes for OTP-21.0.2
|
|
* rickard/trace-info-bug/OTP-15183:
Fix trace_info/2
|
|
* rickard/corba-build/OTP-15176:
Provide build support for standalone corba repo
|
|
|
|
|
|
The release notes generated in the README and notes.xml were out of
sync, and notes.xml erroneously listed a fixed bug as open.
|
|
|
|
|
|
* john/erts/inet-drv-race/OTP-15158/ERL-654:
Fix a race condition when generating async operation ids
|
|
* john/erts/merge-OTP-15067:
Don't enqueue system tasks if target process is in fail_state
Fix erroneous schedule of freed/exiting processes
Fix deadlock in run queue evacuation
Fix memory leak of processes that died in the run queue
|
|
The counter used for generating async operation ids was a plain int
shared between all ports, which was incorrect but mostly worked
fine since the ids only had to be unique on a per-port basis.
However, some compilers (notably GCC 8.1.1) generated code that
assumed that this value didn't change between reads. Using a
shortened version of enq_async_w_tmo as an example:
int id = async_ref++;
op->id = id; //A
return id; //B
In GCC 7 and earlier, `async_ref` would be read once and assigned
to `id` before being incremented, which kept the values at A and B
consistent. In GCC 8, `async_ref` was read when assigned at A and
read again at B, and then incremented, which made them inconsistent
if we raced with another port.
This commit fixes the issue by removing `async_ref` altogether and
replacing it with a per-port counter which makes it impossible to
race with someone else.
|
|
When a system task was enqueued on a process between being
scheduled and the check altered in this commit, we'd run dirty
code on a normal scheduler as the RUNNING_SYS flag wasn't set
and we wouldn't migrate back.
This change migrates us to a dirty scheduler instead, which will
immediately bounce us back to a normal scheduler where
RUNNING_SYS will be set appropriately.
This is caught fairly reliably by
process_SUITE:system_task_failed_enqueue on machines with a lot of
cores.
|
|
|
|
|
|
|
|
* origin/henrik/Update-copyright:
Update copyright year
|
|
|
|
* lukas/erts/fix_vxworks_configure:
erts: Fix vxworks configure broken by corba removal
|
|
|
|
|
|
* sverker/macos-select-fd-bug:
erts: Fix MacOS pollset bug
|
|
* maint:
Updated OTP version
Prepare release
Add test case
Parse #mc_new_type{}s before definitions_loop/2
erts: Fix race between ets table deletion and auto-unfix
|
|
into john/erts/merge-OTP-15067
|
|
The fail state wasn't re-checked in the state change loop; only
the FREE state was checked. In addition to that, we would leave
the task in the queue when bailing out which could lead to a
double-free.
This commit backports active_sys_enqueue from master to make it
easier to merge onwards.
|
|
When scheduled out, the process was never checked for the FREE state
before rescheduling, which meant that a system task could sneak in
and cause a double-free later on.
|
|
that could cause clearing of fd-bits past allocated bit-vectors.
Bug introduced on master by
988f5f5e8061ce2e135a314ca782788eda478a06
|
|
|
|
|
|
|
|
* sverker/ets-auto-unfix-delete-race/OTP-15109:
erts: Fix race between ets table deletion and auto-unfix
|
|
|
|
to actually run remote on the slave node that it starts.
|
|
* sverker/process-info-exiting:
erts: Fix incoming signal handling for exiting process
|
|
Seen symptom:
handle_process_info() called with is_alive=1 on exiting process,
reading broken Process.u.initial.module atom
overwritten by Process.u.terminate pointer.
Solution:
Let erts_proc_sig_handle_incoming() do nothing if process is
already exiting.
|
|
Fix use-after-free on Windows in escript
|
|
|
|
* lukas/kernel/logger-config/OTP-13295:
erts: Fix emulator log messages to use erlang:system_time
kernel: Add LOGGER_SERVER_TAG to logger_server
|
|
* sverker/ets-auto-unfix-delete-race/OTP-15109:
erts: Fix race between ets table deletion and auto-unfix
|
|
Bug exists since ets-refs were introduced in 20.0
0d6dc895744c34c9c52fd42f4801a8a941864ae3.
Problem:
1. Process A fixates table T.
2. Process B starts deleting table T (either by ets:delete or exit)
and does tid_clear().
3. Process A exits and does proc_cleanup_fixed_table()
and get NULL from btid2tab() and deallocates DbFixation.
4. Process B continues deleting table in free_fixations_locked()
and finds the deallocated DbFixation in the fixing_procs tree.
Solution:
Wait with tid_clear() until after free_fixations_locked()
has traversed the fixing_procs tree.
|
|
* sverker/broken-sig-queue:
erts: Cleanup in proc_queue_signal
erts: Fix broken signal queue
|
|
* Remove 'last' arg to sig_enqueue_trace_cleanup
* Only notify 'rp' if enqueue succeeded
|
|
broken on master by
613cde66c25464121f2f6dace99782bad0e07d9b
Scenario:
proc_queue_signal() fails to send switched pending signal
due to state & ERTS_PSFLG_FREE,
and then calls erts_proc_sig_send_monitor_down() to enqueue to self
followed by sig_enqueue_trace_cleanup() that destroyed 'next' pointer
of enqueued signal.
Solution:
Switch order and do sig_enqueue_trace_cleanup() first.
|
|
* maint:
Updated OTP version
Prepare release
inets: Gracefully handle bad headers
|
|
|
|
* sverker/system-profile-bug/OTP-15085:
erts: Fix bug in system_profile
|
|
* sverker/enif_binary_to_term-bug/OTP-15080:
erts: Fix bug in enif_binary_to_term for immediates
|
|
do not call abort_signal_task() with invalid data
|
