Bug #9198: Segfault in TestException#test_machine_stackoverflow

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.1.0dev (2013-11-23 trunk 43807) [x86_64-linux]
• Backport: 2.0.0: UNKNOWN

[vo.x (Vit Ondruch)]

I observe segfault in TestException#test_machine_stackoverflow test case for -preview2. Please see attached log.

[vo.x (Vit Ondruch)]

Forgot to mention that I am testing of Fedora Rawhide.

[vo.x (Vit Ondruch)]

Still observe the issue with ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-linux]

[normalperson (Eric Wong)]

Does it go away if you wrap the test with Thread.new?
Likely the same problem I describe in [ruby-core:60248]

--- a/test/ruby/test_exception.rb
+++ b/test/ruby/test_exception.rb
@@ -480,10 +480,12 @@ def test_stackoverflow
def test_machine_stackoverflow
bug9109 = '[ruby-dev:47804] [Bug #9109]'
assert_separately([], <<-SRC)

• Thread.new do
  assert_raise(SystemStackError, #{bug9109.dump}) {
  h = {a: ->{h[:a].call}}
  h[:a].call
  }
• end
  SRC
  rescue SystemStackError
  end

[vo.x (Vit Ondruch)]

Eric Wong wrote:

Does it go away if you wrap the test with Thread.new?

Yes, this patch helps.

[vo.x (Vit Ondruch)]

BTW I am not using some old glibc (as you say in ruby-core:60248), but the most recent version (glibc-2.18.90-26.fc21.x86_64).

[normalperson (Eric Wong)]

Interesting. Can you poke the Red Hat glibc/kernel folks to see if the
problem is specific to RH/Fedora systems?

Regardless, the current method of getting the address of the main thread
stack seems error prone and fragile on Linux. Perhaps we should avoid
pthread_getattr_np in the main thread.

[vo.x (Vit Ondruch)]

Since this happens with recent glibc more often then it used to be, I reported this issue to glibc maintainers in Fedora [1]. I hope they can provide some help.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1195206

[vo.x (Vit Ondruch)]

• Status changed from Open to Closed
• Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN to 2.0.0: UNKNOWN

This test was disabled by r49550 => closing this issue.