Bug #1813

Threading seg fault (1.9.1-p129 Linux/Mac)

Added by Charlton Wang over 4 years ago. Updated almost 3 years ago.

[ruby-core:24540]
Status:Closed
Priority:Normal
Assignee:Motohiro KOSAKI
Category:core
Target version:2.0.0
ruby -v:ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux] Backport:

Description

=begin
I'm not sure if there is a thread stack limitation change that is new to 1.9.1 but the following code now causes a segfault on Linux and Illegal Instruction on the Mac. I know this code is somewhat ridiculous (call stack is attempting to go 1001 levels deep) but this seems to work fine in 1.8.6. If the code is executed outside of a thread, everything works fine as well.

t = Thread.new do
n = 1000
n.times do |i|
Object.classeval <<EOF
define
method "foo#{i}" do
if i < n-1
puts i
self.send("foo#{i+1}")
else
puts "done"
end
end
EOF
end
foo0
end
t.join

Thanks,
Charlton
=end


Related issues

Related to ruby-trunk - Bug #2558: r24591 causes Segfault Closed 01/05/2010
Related to ruby-trunk - Bug #4983: Fiberのガードページの設定が間違ってる Closed 07/06/2011
Related to ruby-trunk - Bug #3781: FIBER_USE_NATIVE が有効だと落ちるスクリプトがある Closed 09/02/2010
Duplicated by ruby-trunk - Bug #3286: segfault in method_missing -> method -> method_missing re... Closed 05/13/2010

Associated revisions

Revision 32369
Added by Motohiro KOSAKI almost 3 years ago

  • threadpthread.c (getstack): add to a care of gurad page on Mac OS X. [Bug #1813]
  • signal.c (ruby_signal): SIGBUS use alternative stack too.
  • signal.c (sigbus): On Mac, thread stack overflow makes SIGBUS instead of SIGSEGV. thus, added stackoverflow check.
  • signal.c (default_handler): get rid of compilation warning.
  • signal.c (Init_signal): ditto.

Revision 32371
Added by Motohiro KOSAKI almost 3 years ago

  • threadpthread.c (getstack): pthreadattrgetstack() doesn't return stack start addres, but stack base address. Thus, we need to add stack size for getting stack start address. And, we don't have to decrease guard size twice.
  • threadpthread.c (threadstartfunc1): don't use inaccurate stack start guess if nativethreadinit_stack() can be used. [Bug #1813]

Revision 32511
Added by Yutaka Kanemoto almost 3 years ago

  • threadpthread.c (getstack): need to adjust stack addr for [Bug #1813] on AIX.

History

#1 Updated by Charlton Wang over 4 years ago

=begin
I should have realized that the 1.9 series uses native threads and I suspect that's likely the cause (presumably a stack size limitation?).
=end

#2 Updated by Yui NARUSE over 4 years ago

  • Category set to core
  • Status changed from Open to Assigned
  • Assignee set to Koichi Sasada

=begin

=end

#3 Updated by Roger Pack about 4 years ago

=begin
seems to work fine for me with 1.9.1/1.9.2
Is it still a problem?
=end

#4 Updated by Yui NARUSE about 4 years ago

  • Status changed from Assigned to Feedback
  • Assignee deleted (Koichi Sasada)

=begin

=end

#5 Updated by Yui NARUSE about 4 years ago

  • Category set to core
  • Status changed from Feedback to Open

=begin
reproduced on both Ubuntu 8.04 x8664 and FreeBSD 8.0 x8664.
=end

#6 Updated by Nobuyoshi Nakada about 4 years ago

=begin
Seems like a stack overflow.
=end

#7 Updated by Yusuke Endoh almost 4 years ago

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

=begin
This issue was solved with changeset r27789.
Charlton, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end

#8 Updated by Ivan Pirlik over 3 years ago

=begin
I am still getting "Illegal Instruction" in 1.9.2-p0 on OSX 10.5.7 (on Ubuntu 9.10 x86_64 I get a SystemStackError, as expected).
=end

#9 Updated by Iñaki Baz Castillo over 3 years ago

=begin
The given code produces a segmentation fault under ruby 1.9.2-p0 and 1.9.2-p136 (tested in Ubuntu 64 bits). In 1.8 it doesn't crash:

(eval):3: [BUG] Segmentation fault
ruby 1.9.2p136 (2010-12-25 revision 30365) [x86_64-linux]

-- control frame ----------
c:0917 p:---- s:1837 b:1837 l:001836 d:001836 CFUNC :puts
c:0916 p:---- s:1835 b:1835 l:001834 d:001834 CFUNC :puts
c:0915 p:0028 s:1831 b:1831 l:000978 d:001830 LAMBDA (eval):3
c:0914 p:---- s:1829 b:1829 l:001828 d:001828 FINISH
c:0913 p:0040 s:1827 b:1827 l:000978 d:001826 LAMBDA (eval):4
c:0912 p:---- s:1825 b:1825 l:001824 d:001824 FINISH
c:0911 p:0040 s:1823 b:1823 l:000978 d:001822 LAMBDA (eval):4
c:0910 p:---- s:1821 b:1821 l:001820 d:001820 FINISH
c:0909 p:0040 s:1819 b:1819 l:000978 d:001818 LAMBDA (eval):4
c:0908 p:---- s:1817 b:1817 l:001816 d:001816 FINISH
c:0907 p:0040 s:1815 b:1815 l:000978 d:001814 LAMBDA (eval):4
c:0906 p:---- s:1813 b:1813 l:001812 d:001812 FINISH
c:0905 p:0040 s:1811 b:1811 l:000978 d:001810 LAMBDA (eval):4
c:0904 p:---- s:1809 b:1809 l:001808 d:001808 FINISH
c:0903 p:0040 s:1807 b:1807 l:000978 d:001806 LAMBDA (eval):4
c:0902 p:---- s:1805 b:1805 l:001804 d:001804 FINISH
c:0901 p:0040 s:1803 b:1803 l:000978 d:001802 LAMBDA (eval):4

=end

#10 Updated by Motohiro KOSAKI about 3 years ago

  • Status changed from Closed to Open
  • Target version set to 2.0.0

=begin
This issue can be still reproduced on trunk. (ruby 1.9.3dev (2011-02-15 trunk 30882) [x86_64-linux])

reopened.
=end

#11 Updated by Yui NARUSE almost 3 years ago

  • Status changed from Open to Assigned
  • Assignee set to Motohiro KOSAKI
  • % Done changed from 100 to 0

#12 Updated by Motohiro KOSAKI almost 3 years ago

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

This issue was solved with changeset r32369.
Charlton, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • threadpthread.c (getstack): add to a care of gurad page on Mac OS X. [Bug #1813]
  • signal.c (ruby_signal): SIGBUS use alternative stack too.
  • signal.c (sigbus): On Mac, thread stack overflow makes SIGBUS instead of SIGSEGV. thus, added stackoverflow check.
  • signal.c (default_handler): get rid of compilation warning.
  • signal.c (Init_signal): ditto.

#13 Updated by Motohiro KOSAKI almost 3 years ago

Linux and MacOS X had completely different bugs. Thus I've commited two patches, r32369 and 32371.
Now, both platform raise SystemStackError correctly.

thanks.

Also available in: Atom PDF