Bug #20632: madvise(MADV_FREE) failure should not crash the process

• Status: Closed
• Assignee: kjtsanaktsidis (KJ Tsanaktsidis)
• Target version: -
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN

[kjtsanaktsidis (KJ Tsanaktsidis)]

The M:N threading stack cleanup machinery here tries to call MADV_FREE on the native thread's stack, and calls rb_bug if it fails: https://github.com/ruby/ruby/blob/371055979f4e367e90d7af4140e92fd3824bce2a/thread_pthread_mn.c#L369

Unfortunately, there's no way to distinguish between "You passed bad parameters to madvise" and "MADV_FREE is not supported on the kernel you are running on"; both cases just return EINVAL. This means that if you have a Ruby on a system that was built on a system with MADV_FREE and run it on a system without it, you get a crash in nt_free_stack.

I ran into this because rr actually emulates MADV_FREE by just returning EINVAL and pretending it's not supported (since it can otherwise introduce nondeterministic behaviour). So if you run bootstraptest/test_ractor.rb under rr, you get this crash.

I think we should just get rid of the error handling here; freeing memory like this is strictly optional anyway.

• Status changed from Open to Closed

Applied in changeset git|ca0dae25ed51627c411dfdbe9dec3901a321bff9.

---

Don't crash if madvise(MADV_FREE or MADV_DONTNEED) fails

The M:N threading stack cleanup machinery tries to call MADV_FREE on the native
thread's stack, and calls rb_bug if it fails. Unfortunately, there's no way to
distinguish between "You passed bad parameters to madvise" and "MADV_FREE is
not supported on the kernel you are running on"; both cases just return EINVAL.
This means that if you have a Ruby on a system that was built on a system with
MADV_FREE and run it on a system without it, you get a crash in nt_free_stack.

I ran into this because rr actually emulates MADV_FREE by just returning EINVAL
and pretending it's not supported (since it can otherwise introduce
nondeterministic behaviour). So if you run bootstraptest/test_ractor.rb under
rr, you get this crash.

I think we should just get rid of the error handling here; freeing memory like
this is strictly optional anyway.

[Bug #20632]