[DRE-maint] Bug#881773: ruby2.5: FTBFS on hppa: recursive once test fails

[John David Anglin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
On 2018-04-01 10:17 a.m., Antonio Terceiro wrote:
> On Sat, Mar 31, 2018 at 04:42:36PM -0400, John David Anglin wrote: >> Source: ruby2.5 >> Version: 2.5.x >> Followup-For: Bug #881773 >> >> Dear Maintainer, >> >> In the 2.5.1 build, test #361 fails as follows:
>> >> #361 test_insns.rb:389:in `block in <top (required)>' F 0.090 >> stderr output is not empty >> bootstraptest.tmp.rb:3:in `once': stack
level too deep (SystemStackError) >> from bootstraptest.tmp.rb:7:in `block in once' >> from bootstraptest.tmp.rb:3:in `once' >> from
bootstraptest.tmp.rb:7:in `block in once' >> from bootstraptest.tmp.rb:3:in `once' >> from bootstraptest.tmp.rb:7:in `block in once' >> from
bootstraptest.tmp.rb:3:in `once' >> from bootstraptest.tmp.rb:7:in `block in once' >> from bootstraptest.tmp.rb:3:in `once' >> ... 97 levels...
>> from bootstraptest.tmp.rb:3:in `once' >> from bootstraptest.tmp.rb:7:in `block in once' >> from bootstraptest.tmp.rb:3:in `once' >> from
bootstraptest.tmp.rb:11:in `<main>' >> >> So, it appears the test causes a stack overflow on hppa. >> >> It is not uncommon for hppa to require
twice the stack space x86 needs. >> Is there a way to increase the stack allocation for hppa (e.g., using ulimit)? >> Otherwise, I would say the
test needs to be skipped on hppa. > > I don't think working around this in the tests is the correct solution > to the issue. There was a similar
problem on ppc64el recently, maybe you > can find a similar solution for hppa: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881772 > >
I don't have the cycles to go after this myself, but I'll be happy to > take a patch (but please also send it upstream). After considerable
investigation, Helge Deller and I find that the technique used in ruby
to determine the main stack address and size do not yield a sufficiently large default stack
size for ruby on hppa.  The issue is the main stack is growable, so the initial allocation is
somewhat arbitrary.  The size of the main stack can be changed with ulimit, but the initial
allocated size doesn't change.

This copy&pasted patch fixes recursive test:

- --- ./thread_pthread.c.org      2019-08-10 23:12:48.767979850 +0200
+++ ./thread_pthread.c  2019-08-10 23:12:19.608159449 +0200
@@ -579,6 +579,11 @@ get_stack(void **addr, size_t *size)
 # endif
     CHECK_ERR(pthread_attr_getguardsize(&attr, &guard));
     *size -= guard;
+#if defined(__hppa__)
+    /* parisc requires bigger stacks than other arches */
+    *size *= 4; // HELGE
+    fprintf(stderr, "SIZE is now HELGE 0x%x\n", *size);
+#endif
     pthread_attr_destroy(&attr);
 #elif defined HAVE_PTHREAD_ATTR_GET_NP /* FreeBSD, DragonFly BSD, NetBSD */
     pthread_attr_t attr;

The patch demonstrates the issue.  I tend to think get_main_stack should be modified to
reflect that the main stack is growable.  Possibly, the size obtained by get_main_stack should
be modified based on the setting of one of the RUBY_THREAD_VM_STACK_SIZE defines.

Regards,
Dave Anglin

- -- 
John David Anglin  dave.anglin at bell.net
-----BEGIN PGP SIGNATURE-----
 
iQIzBAEBCAAdFiEEnRzl+6e9+DTrEhyEXb/Nrl8ZTfEFAl1PQmgACgkQXb/Nrl8Z
TfGJvQ/+PmgRZmIGprBbrJ6yrkuZBTjNmDKKCJh/A2gUOYAuE3t3Qd5kOnhArl4A
zRQlP0sDDRqkPDUJzuMY3Jrw58R2hjJfW0MAZM6jrQFj99xl3spfko2wb8qxZ09D
WDPHBIwCGWd4ncwLxRs8UhVmLHILIUokGXlDMXMGvZPYDk+Js2Nbe6awD7EzK/0S
D8dKj2k07noPBaqrfGKM6qEn00T9jPrKxxAhRgiPQ16LWqDeNStEVj96HT1IoCDV
n3HtdAd9bUEhWS7DZt16phAFRAfg0fhVcdJ8/P6FQOLuSLWatt+MiAX3AL1BPMv7
+mKtgDnU+05SxOMIXpPlUv+Kj9AdEJkhkscmMCPPOsYdFwwPYutrt/PuAC6pTbry
5Sb0bz5lHsWR4BgfAaz3kUplDc6npDiDpB0U2KIY+uYnXoUEdXaRkH0Fu53BU6c4
sJvLt86pPbu36hepbFmRObDQX/CwwjUyx8Q84j80wSpEA+XsbX9e5wzIuSN0xK3W
AopaySG00LdRVTtdnQFnbmgID6sUmqwOzG+S5Ls5XMLlRctMuiF/scoU43zRgvvq
XrgBkLIa1rpmBpwXtulG90qGxPWuLP8azHQZIVs3v8NbK6miyUP+DIxDV5anT6Zs
4Xb4HUGquYKxIGV5gzK9+YaWlvNva4BN/ktvG/99sYZD51GO6IM=
=YZn/
-----END PGP SIGNATURE-----