Bug #20452: Ruby 3.3 on Alpine Linux results in a relatively shallow SystemStackError exception

• Status: Feedback
• Assignee: -
• Target version: -
• ruby -v: 3.3.1
• Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
• Tags: musl, alpine

[Earlopain (A S)]

This is a redo of https://bugs.ruby-lang.org/issues/14387, reported against a non-eol version. The same issue still applies on recent rubies, though I personally only have tested 3.3 and 3.2:

n = 100000
res = {}
1.upto(n).to_a.inject(res) do |r, i|
  r[i] = {}
end

def f(x)
  x.each_value { |v| f(v) }
end

f(res)

The patch from https://bugs.ruby-lang.org/issues/14387#note-13 still works, though as per https://bugs.ruby-lang.org/issues/14387#note-16 it can't be accepted as is.

With the patch applied:

(irb):8:in `block in f': stack level too deep (SystemStackError)
        from (irb):8:in `each_value'
        from (irb):8:in `f'
        from (irb):8:in `block in f'
        from (irb):8:in `each_value'
        from (irb):8:in `f'
        from (irb):8:in `block in f'
        from (irb):8:in `each_value'
        from (irb):8:in `f'
         ... 11549 levels...
        from /usr/local/lib/ruby/gems/3.3.0/gems/irb-1.11.0/exe/irb:9:in `<top (required)>'
        from /usr/local/bin/irb:25:in `load'
        from /usr/local/bin/irb:25:in `<main>'

Without the patch:

(irb):8:in `each_value': stack level too deep (SystemStackError)
        from (irb):8:in `f'
        from (irb):8:in `block in f'
        from (irb):8:in `each_value'
        from (irb):8:in `f'
        from (irb):8:in `block in f'
        from (irb):8:in `each_value'
        from (irb):8:in `f'
        from (irb):8:in `block in f'
         ... 286 levels...
        from /usr/local/lib/ruby/gems/3.3.0/gems/irb-1.11.0/exe/irb:9:in `<top (required)>'
        from /usr/local/bin/irb:25:in `load'
        from /usr/local/bin/irb:25:in `<main>'

To reproduce, I have removed lines 102-105 from https://github.com/docker-library/ruby/blob/f5753434bb23041dd9913bb7b650e7be735e03c0/3.3/alpine3.19/Dockerfile. Check out the previous ticket for more information, there are a few conversations about possible solutions.

[nobu (Nobuyoshi Nakada)]

Does configure with ac_cv_func_pthread_get_stackaddr_np=no change something?

[Earlopain (A S)]

nobu (Nobuyoshi Nakada) wrote in #note-1:

Does configure with ac_cv_func_pthread_get_stackaddr_np=no change something?

Thank you for your reply. I modified export ac_cv_func_isnan=yes ac_cv_func_isinf=yes to export ac_cv_func_pthread_get_stackaddr_np=no ac_cv_func_isnan=yes ac_cv_func_isinf=yes and rebuild but the StackError occured at basically the same depth.

[hsbt (Hiroshi SHIBATA)]

• Tags set to musl, alpine
• Status changed from Open to Feedback

Unfortunately, there is no active maintainer for musl or alpine platform.

I tagged them to musl. We welcome patch for them.

[nobu (Nobuyoshi Nakada)]

make DEFS=-DMAINSTACKADDR_AVAILABLE=0 thread.o seems working.

[nobu (Nobuyoshi Nakada)]

Does this help you?
https://github.com/nobu/ruby/tree/mainstackaddr

[Earlopain (A S)]

nobu (Nobuyoshi Nakada) wrote in #note-5:

Does this help you?
https://github.com/nobu/ruby/tree/mainstackaddr

Thank you. I tried it out with your patch but something is missing still. Building with make DEFS=-DMAINSTACKADDR_AVAILABLE=0 from your comment above works wonderfully though.

I believe HAVE_PTHREAD_GETATTR_NP may be defined? In configure.log I see HAVE_PTHREAD_GETATTR_NP=1 a few times. https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_getattr_np.c