Fix process_info that can hang waiting for reply

[max-au]

With multiple reusable receive markers, marker that is marked
to remove may be followed by process_info signal, which will
also be handled within the loop in erts_proc_sig_handle_incoming.

It is possible that process_info moves messages up to the next
non-message signal from the middle to inner queue. If there was a
receive marker at the very beginning of the middle queue, it
would set save pointer to sig_qs.cont, which will be overwritten
when linking middle queue head into inner queue. This would make
save pointer to skip all messages that were in between of removed
receive marker and process_info request.

To observe this behaviour using a debugger, run the test case
provided with a breakpoint set to handle_process_info part where
it reassigns c_p->sig_qs.cont to the next non-message signal
(**next_nm_sig)

Test case runs a process that triggers receive marker to enter
its middle queue. Currently it's done with process_info BIF, but
can also be triggered with erlang:cancel_timer (which also
places receive marker). Additional processes are sending
process_info requesting to move messages into inner queue, which
eventually makes middle queue to contain:

• receive marker that is set to be removed but set_save
• reply tuple ({Ref, Dictionary})
• process_info request moving previous message into inner queue

Receive marker gets removed from the middle queue after setting
save pointer to sig_qs.cont, then erts_proc_sig_handle_incoming
proceeds to process_info. Which moves reply tuple into the
inner queue, but save pointer is left untouched pointing to the
head of the middle queue, which is beyond the reply. This
way reply never gets matched (as save pointer has already
moved past it), and process_info hangs forever.

[kjellwinblad]

Thanks for the PR and for finding the bug! I think the commit looks good but I think we can wait a few days until @jhogberg or @rickard-green (they are much more familiar with the receive marker optimization than I am) have had time to look at it before we merge and release a patch.

[rickard-green]

Great catch! Thanks for the PR!

Please rebase your branch onto the tag OTP-24.0.5, so that it is possible to release this in the next emergency patch package that we release.

[max-au]

Rebased to OTP-24.0.5 (base branch has to stay "maint").