OCaml 4.13 memory leak in caml_setup_stack_overflow_detection

[rwmjones]

Run any ocamlopt-compiled program under valgrind --leak-check=full and you will see:

==2560078== 8,192 bytes in 1 blocks are definitely lost in loss record 25 of 33
==2560078==    at 0x484086F: malloc (vg_replace_malloc.c:380)
==2560078==    by 0x13C969: caml_setup_stack_overflow_detection (in /var/tmp/test)
==2560078==    by 0x13C9E3: caml_init_signals (in /var/tmp/test)
==2560078==    by 0x13B684: caml_startup_common (in /var/tmp/test)
==2560078==    by 0x13B76E: caml_main (in /var/tmp/test)
==2560078==    by 0x11C6D1: main (in /var/tmp/test)

This leak seems to be new in OCaml 4.13.1.

In nbdkit we maintain a set of valgrind suppressions for OCaml, and the only ones we expect are functions matching caml_stat_alloc*: https://gitlab.com/nbdkit/nbdkit/-/blob/master/valgrind/ocaml.suppressions

[xavierleroy]

Following an unhelpful change in glibc (#10250), there was an emergency fix in #10266, in particular to unblock the Rawhide builds.

The emergency fix allocates the alternate signal stack dynamically, but does not free it because it's not entirely obvious how to do so safely (#10250 (comment)).

Until this is addressed, your temporary fix (adding caml_setup_stack_overflow to the valgrind suppressions) should work. Make sure to thank the glibc developers for this mess.

[rwmjones]

I don't disagree! That change has caused a huge amount of churn everywhere.

Back to this bug though, since the alternate stack is not intended to be freed, would it make sense to rename the function caml_stat_alloc_stack_overflow (or anything beginning caml_stat_alloc_) as that appears to be the convention for static allocations?

[xavierleroy]

Tentative fix in #10726. Needs testing.