From: "kjtsanaktsidis (KJ Tsanaktsidis) via ruby-core" Date: 2024-07-12T05:12:32+00:00 Subject: [ruby-core:118581] [Ruby master Bug#20632] madvise(MADV_FREE) failure should not crash the process Issue #20632 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20632: madvise(MADV_FREE) failure should not crash the process https://bugs.ruby-lang.org/issues/20632 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Assignee: kjtsanaktsidis (KJ Tsanaktsidis) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- 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. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/