rebar3_hex 7.3.0 leaves HEX_API_KEY to rebar3, which reads it from
3.27.1 on; with the 3.25.1 the workflow installed, publishing crashed.

Install rebar3 3.27.1 and pin the plugin to 7.3.0, so that a plugin
release cannot change what a tag runs.

Signed-off-by: Davide Bettio <davide@uninstall.it>

Update CHANGELOG.md, bump version number in version.cmake.

Signed-off-by: Davide Bettio <davide@uninstall.it>

Prepare next development cycle

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

Maps are expected to hold their keys in term order, but MAP_EXT
decoding kept them in the encoder's order. OTP writes maps of more
than 32 keys in hash order, and since OTP 26 smaller maps with atom
keys in atom index order, so such maps arriving through
binary_to_term or distribution compared unequal to the same map
built at runtime, and a `=>` update of an existing key produced
duplicate keys. Sending that map back to an OTP node is then rejected
as a corrupted external term and the distribution connection is
dropped.

Sort the entries once decoded, and reject a map with duplicate keys
with badarg, as OTP does.

Fixes: #2408
Fixes: #2412
Signed-off-by: Matt Beanland <beanland@live.com.au>

Fix key order of maps decoded from MAP_EXT

Fixes #2408
Fixes #2412

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

send_after/3 returned a fresh reference while the timer it spawned was
registered under another one, so cancel_timer/1 never found it and the
message was delivered anyway. erlang:send_after/3 and
timer:send_after/2,3 delegate to it and were affected too.

Route send_after/3 through the same gen_server path as start_timer/3,
with a delivery mode that sends the bare message instead of the
{timeout, Ref, Msg} tuple.

Originally submitted by Qata in PR #2358, squashed and rebased onto
release-0.7 as requested in review.

These changes are made under both the "Apache 2.0" and the "GNU Lesser
General Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

See also: #2358
Signed-off-by: Davide Bettio <davide@uninstall.it>

Fix cancellation of send_after/3 timers

mailbox_crashdump moved the normal messages of the outer list to the
inner list and then stored the remaining signals back with a plain
assignment to outer_first. Two things went wrong with that:

- a signal enqueued by another scheduler between the detach and the
  store was overwritten and lost. With a process monitored twice by a
  process that is killed while the monitored one crashes, one of the
  two DemonitorSignals could be lost this way, and context_destroy
  then aborted in context_monitors_handle_terminate on
  `assert(target != NULL)`;
- the signals were stored back oldest first while the outer list is
  newest first, so context_destroy processed them in reverse order.

Store the signals back newest first with a compare and exchange,
chaining anything enqueued in the meantime in front of them.

Fixes: #2415
Signed-off-by: Zhaoqi Xu <lzy00419@outlook.com>

globalcontext_send_message_from_task pushes onto the head of the global
message queue when it cannot enqueue directly, and
globalcontext_process_message_queue drained it from the head, so the
messages a task sent in a row reached the mailbox in reverse order.
Without SMP every message from a task goes through this queue: on the
ESP32-C3 the network driver's eth_connected arrived before eth_started.
With SMP it happens when the process table or spinlock is busy.

Reverse the queue before enqueuing. test-mailbox sends two batches with
the spinlock held, which forces the queued path with SMP too, and checks
they arrive in order; it is built only with AVM_TASK_DRIVER_ENABLED.

Signed-off-by: Gabriel Mancini <gabriel.mancini@gmail.com>

…als-2415

Keep pending signals in order when dumping a crashed process

Fixes #2415

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

Fix order of messages sent from tasks

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

enif_select sets read/write on a select event while holding the
select_events lock, but marks select_events_poll_count dirty only after
releasing it (sys_register_select_event). If another scheduler rebuilds
the pollfd array in between because the listeners are dirty, it reuses
the cached select event count and then writes one entry for every
select event with read or write set: one more than it allocated.

AddressSanitizer reports it as a heap-buffer-overflow in
sys_poll_events_with_poll; without it, glibc aborts later with
"realloc(): invalid next size". Counting the select events on every
rebuild, under the lock the loop already holds, keeps the count and the
loop in agreement.

Signed-off-by: Gabriel Mancini <gabriel.mancini@gmail.com>

Arm a select event the way enif_select does under the select_events
lock, but before sys_register_select_event marks the cached count
dirty, then run a listener-only rebuild. On the parent commit the
pollfd array is sized from the stale count and ASan reports a heap
buffer overflow; with the fix the event is polled and notified.

Not built on kqueue: an fd armed this way never reaches the kqueue.

Co-authored-by: Davide Bettio <davide.bettio@ispirata.com>
Signed-off-by: Gabriel Mancini <gabriel.mancini@gmail.com>

generic_unix: Fix poll set overflow on select

.github: Use rebar3 3.27.1 to publish the atomvm Hex package

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

A read that finds data takes every buffered byte, including the bytes
of UART_DATA events still queued. When the listener then handles one
of those events, uart_read_bytes waits forever for bytes that were
already delivered, blocking the scheduler: with a peer that then goes
quiet (a modem after ATH), the task watchdog resets the chip.

Read only what the buffer holds, without waiting, and skip an event
that finds it empty.

Signed-off-by: Gabriel Mancini <gabriel.mancini@gmail.com>

With a 0 tick timeout uart_read_bytes can return -1 (rx mutex busy) or
fewer bytes than counted (the other scheduler drained the buffer), and
the result was dropped: {ok, Bin} went out with uninitialized bytes.

uart:read/2 had the same race with portMAX_DELAY: after counting the
buffered bytes, the listener on the other scheduler could take some,
and the read then waited for the peer to send more.

Both paths now read into a temporary buffer without waiting, build the
binary from the returned length, and keep the reader registered when
nothing was read. The UART and USB-Serial/JTAG branches share it.

Signed-off-by: Gabriel Mancini <gabriel.mancini@gmail.com>

esp32 uart: Fix read blocking on a stale event