merge revision(s) 8b0dc77a621ded75f72486c33f55404ce73f00d7: [Backport #17275]

	configure.ac: Bump the size of sigaltstack

	The RubyVM uses C macro defines to feature detect whether
	`backtrace(2)` support is available, and if so it includes C level backtraces
	when the RubyVM itself crashes.

	But on my machine, C level backtraces from `vm_dump.c` didn't work when
	using a version of Ruby buillt on the machine, but worked fine when using a
	version of Ruby built on another machine and copied to my machine.

	The default autoconf test for backtraces uses a sigaltstack size that is
	too small, so the SIGSEGV signal handler itself causes a SIGSEGV).
	I noticed that signal.c uses a larger sigaltstack size:

	https://github.com/ruby/ruby/blob/v2_6_5/signal.c#L568

	The specific variables it looks at:

	- `HAVE_BACKTRACE`

	  this is a macro defined by autoconf because there is a line in the
	  configure script like `AC_CHECK_FUNCS(backtrace)` (see the autoconf
	  docs for more).

	- `BROKEN_BACKTRACE`

	  this comes from a custom program that Ruby's configure script runs to
	  attempt to figure out whether actually using backtrace(2) in a real
	  program works. You can see the autoconf program here.

	  <https://github.com/ruby/ruby/blob/v2_6_5/configure.ac#L2817-L2863>

	It uses sigaltstack and SA_ONSTACK to create a seperate stack for
	handling signals.

	The problem was: SIGSTKSZ (which comes from a system header!) was not
	suggesting a large enough stack size. When checking on an Ubuntu 16.04
	box, we found that SIGSTKSZ was 8192 and MINSIGSTKSZ was 2048.

1 files changed, 1 insertions, 1 deletions

diff --git a/version.h b/version.h
index 7afd8b7d49..c998ef635e 100644
--- a/version.h
+++ b/version.h
@@ -2,7 +2,7 @@
 # define RUBY_VERSION_MINOR RUBY_API_VERSION_MINOR
 #define RUBY_VERSION_TEENY 3
 #define RUBY_RELEASE_DATE RUBY_RELEASE_YEAR_STR"-"RUBY_RELEASE_MONTH_STR"-"RUBY_RELEASE_DAY_STR
-#define RUBY_PATCHLEVEL 143
+#define RUBY_PATCHLEVEL 144
 
 #define RUBY_RELEASE_YEAR 2020
 #define RUBY_RELEASE_MONTH 12