Bug #9454: The define_method(:class) segfault

[Kyrylo Silin]

Ruby 2.1.0p0 segfaults when I invoke the following code.

define_method(:class) { self.class }
self.class #=> segfault :(

It affects exclusively Ruby 2.1.0p0 (I also tested on the most recent 2.0.0, 1.9.3 and 1.8.7).

By the way, on the contrary, the following code does not segfault.

def self.class; self.class end
self.class #=> SystemStackError

Viva la Ucraino revolución!

[Kyrylo Silin]

• File bug9454.txt added

Here's the log with the segfault.

[Nobuyoshi Nakada]

Seems an infinite recursion, obviously.

[Kyrylo Silin]

Sure. As far as I understand it should raise a SystemStackError instead of segfaulting (that's how it worked before v2.1.0p0). If you could give me a hint, which file is relevant, I would probably come up with a patch (I don't promise anything, because I'm not very good at C and Ruby internals).

[Nobuyoshi Nakada]

At first glan.ce, it occurred in INSNS_DISPATCH() macro.
Considering that the second case works fine, maybe recovery jump fails.

[Nobuyoshi Nakada]

• Status changed from Open to Closed
• % Done changed from 0 to 100

Applied in changeset r44712.

---

thread_pthread.c: get current main thread stack size

• thread_pthread.c: get current main thread stack size, which may be expanded than allocated size at initialization, by rlimit(). [Bug #9454]

[Eric Wong]

Btw, TestException#test_machine_stackoverflow_by_define_method fails
on an ancient glibc 2.5-42.el5_4.3 (CentOS 5.4 x86_64).

I think this is a bug in pthread_getattr_np when it is run on the main
thread. I'm not sure how many people care about a platform this old,
though; and I've been meaning to upgrade that anyways.

[Rei Odaira]

FYI, TestException#test_machine_stackoverflow_by_define_method fails on my environment, too: Linux 2.6.32-71.el6.x86_64 and glibc 2.12-1.7.el6.

$ ruby -v
ruby 2.2.0dev (2014-04-01 trunk 45498) [x86_64-linux]

The problem is that pthread_attr_getstack() and even getrlimit() return 0xa00000 (= 10 MB) as a max stack size, but the actual stack size at the time of the stack overflow seems bigger by about 2 MB, according to /proc/PID/maps.

7fe1f7664000-7fe1f7afe000 rw-p 00000000 00:00 0                          [heap]
7fffc0836000-7fffc1435000 rw-p 00000000 00:00 0                          [stack]
7fffc15d4000-7fffc15d5000 r-xp 00000000 00:00 0                          [vdso]

0x7fffc1435000 - 0x7fffc1435000 = 0xbff000 (= ~12 MB). As a result, the address causing SIGSEGV is not considered as part of the stack.

[Nobuyoshi Nakada]

• Duplicated by Backport #9828: Segfault instead of stack overflow added

[Nobuyoshi Nakada]

• Duplicated by Bug #9945: Segmentation fault when defining recursive method added

[Nobuyoshi Nakada]

• Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN to 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: REQUIRED

[Tomoyuki Chikanaga]

• Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: REQUIRED to 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: DONE

r44712, r44715, r44716, r44722, r44725, r44726 and r44753 were backported into ruby_2_1 branch at r46468.

[Usaku NAKAMURA]

• Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: DONE to 1.9.3: UNKNOWN, 2.0.0: DONE, 2.1: DONE

backported into ruby_2_0_0 at r46667 and r46669.

[Usaku NAKAMURA]

• Backport changed from 1.9.3: UNKNOWN, 2.0.0: DONE, 2.1: DONE to 1.9.3: UNKNOWN, 2.0.0: REQUIRED, 2.1: DONE

... but reverted because it introduced SEGV on CentOS.
Maybe somthing is missed, but I wasn't able to find it.

[Tomoyuki Chikanaga]

• Duplicated by Bug #10218: 手続きを再帰するとSegmentation faultが発生する added