v.ondruch / tiscali.cz wrote:
> normalperson (Eric Wong) wrote:
> >  If you have time, can you try to find larger values changed by
> >  r59047 (RUBY_THREAD_MACHINE_STACK_SIZE and
> >  RUBY_FIBER_MACHINE_STACK_SIZE) which do not get stuck/segfault
> >  on PPC?
> 
> Any idea what should be rasonable value? I started naively with 2 and then continued with 5, 10, 100, 1000, 10000 and it is still crashing :/

Oh, check the *_STACK_SIZE #defines in vm_core.h for what the
defaults are, and maybe binary search until you find something
which works/breaks.   I made them all `1' for the tests so it
would automatically pick the *_MIN values.

> >  ppc64le?  I don't know much about PPC and did not know there is
> >  little-endian PPC.
> 
> Yep, LE is available since Power8 if I am not mistaken ...
> 
> >  So it's PPC-specific and not BE-specific...
> >  *scratches head*
> 
> Should I try to get involved somebody from Fedora secondary arches?

Sure!  I'm not sure if we have many PPC folks here and could use
the extra help.

Meanwhile...

Can you also try commenting out parts of test_caller_lev and
narrowing down where in that test it fails?

And give scripts/checkstack.pl in the Linux kernel source a try
to find big stack users:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/scripts/checkstack.pl

Usage:  objdump -d /path/to/ruby | /path/to/checkstack.pl

I've found some big offenders with that over the years, but the
dynamic alloca cases are trickier to find...

Thanks.

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>