minor memory leaks fixes

[max-au]

Running "erl -emu_type asan -eval "erlang:halt()." shows several minor issues straight away. First, init_misc_aux_work is called twice (and first allocation is made orphan), second, when shutting down, async threads don't clean up thread progress data, and - an expected leak, even documented - signal stack.

[max-au]

Would it work now, with alloca avoiding sharing signal buffer?

[rickard-green]

Would it work now, with alloca avoiding sharing signal buffer?

No, since the memory allocated by alloca() is free:d as soon as the sys_thread_init_signal_stack() call returns. This memory block needs to be available as long as the thread is alive.

If I read the code correct it is only used by scheduler threads and the main thread. None of these threads terminates unless the whole vm terminates, so it is no actual memory leak malloc:ing this memory and never free:ing it.

[max-au]

I kept the suppression in sys_signal_stack.c, let's address it separately. I think now the PR is ready for review (I also rebased it on top of master branch for merge convenience).

[max-au]

Is there any interest in merging this PR? If not, I'm fine with just closing it.

[rickard-green]

Is there any interest in merging this PR? If not, I'm fine with just closing it.

Yes, there is interest. I just forgot about this one, sorry.

[github-actions]

CT Test Results

       3 files     125 suites   43m 3s ⏱️
1 491 tests 1 442 ✔️ 49 💤 0 ❌
1 802 runs  1 736 ✔️ 66 💤 0 ❌

Results for commit 3d2b7b6.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

[rickard-green]

@max-au

I've added a commit that doesn't remove the wakup callback when unregistering from thread progress as well as making the async threads wakup callback prepared for a NULL argument. This since, otherwise an outstanding wakup request could trigger after the unregistration and cause an emulator crash. An alternative could be to be prepared for NULL wakeup callbacks instead of requiring the wakup callbacks of potentially unregistered threads being prepared for a NULL argument. wakup callbacks are however executed to a much higher degree than the async thread callback; therefore, I don't like such an approach.

Preferably you squash these commits.

[max-au]

Thanks for noticing that, I completely missed the problem (due to lack of async threads usage, I think).
Squashed the commits and rebased to fresh maint branch.