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.
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
=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
- Category set to core
- Status changed from Open to Assigned
- Assignee set to ko1 (Koichi Sasada)
=begin
seems to work fine for me with 1.9.1/1.9.2
Is it still a problem?
=end
- Status changed from Assigned to Feedback
- Assignee deleted (
ko1 (Koichi Sasada))
- 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
=begin
Seems like a stack overflow.
=end
- 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
=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
=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
- 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
- Status changed from Open to Assigned
- Assignee set to kosaki (Motohiro KOSAKI)
- % Done changed from 100 to 0
- 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.
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
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0