Project

General

Profile

Actions

Bug #1813

closed

Threading seg fault (1.9.1-p129 Linux/Mac)

Added by charlton (Charlton Wang) over 15 years ago. Updated over 13 years ago.

Status:
Closed
Target version:
ruby -v:
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
Backport:
[ruby-core:24540]

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.class_eval <<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 4 (0 open4 closed)

Related to Ruby master - Bug #2558: r24591 causes SegfaultClosed01/05/2010Actions
Related to Ruby master - Bug #4983: Fiberのガードページの設定が間違ってるClosedkosaki (Motohiro KOSAKI)07/06/2011Actions
Related to Ruby master - Bug #3781: FIBER_USE_NATIVE が有効だと落ちるスクリプトがあるClosedauthorNari (Narihiro Nakamura)09/02/2010Actions
Has duplicate Ruby master - Bug #3286: segfault in method_missing -> method -> method_missing recursive loopClosed05/13/2010Actions
Actions #1

Updated by charlton (Charlton Wang) over 15 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

Actions #2

Updated by naruse (Yui NARUSE) about 15 years ago

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

=begin

=end

Actions #3

Updated by rogerdpack (Roger Pack) almost 15 years ago

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

Actions #4

Updated by naruse (Yui NARUSE) almost 15 years ago

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

=begin

=end

Actions #5

Updated by naruse (Yui NARUSE) almost 15 years ago

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

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

Actions #6

Updated by nobu (Nobuyoshi Nakada) almost 15 years ago

=begin
Seems like a stack overflow.
=end

Actions #7

Updated by mame (Yusuke Endoh) over 14 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

Actions #8

Updated by ivan (Ivan Pirlik) about 14 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

Actions #9

Updated by ibc (Iñaki Baz Castillo) almost 14 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

Actions #10

Updated by kosaki (Motohiro KOSAKI) almost 14 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

Updated by naruse (Yui NARUSE) over 13 years ago

  • Status changed from Open to Assigned
  • Assignee set to kosaki (Motohiro KOSAKI)
  • % Done changed from 100 to 0
Actions #12

Updated by kosaki (Motohiro KOSAKI) over 13 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.


  • thread_pthread.c (get_stack): add to a care of gurad page on Mac
    OS X. [Bug #1813] [ruby-core:24540]
  • 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.

Updated by kosaki (Motohiro KOSAKI) over 13 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.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0