Bug #1813
Threading seg fault (1.9.1-p129 Linux/Mac)
| Status: | Closed | Start date: | 07/24/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | % Done: | 100% |
||
| Category: | core | |||
| Target version: | 2.0.0 | |||
| ruby -v: | ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux] |
Description
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
Related issues
Associated revisions
* vm_core.c (rb_thread_struct): add a field for sigaltstack.
* thread_pthread.c (thread_start_func_1): initialize machine stack
information.
* thread.c (thread_start_func_2): set sigaltstack for each sub thread.
[ruby-core:24540] [ruby-core:30207]
* 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.
* 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.
* thread_pthread.c (get_stack): pthread_attr_getstack() 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.
* thread_pthread.c (thread_start_func_1): don't use inaccurate
stack start guess if native_thread_init_stack() can be used.
[Bug #1813] [ruby-core:24540]
* thread_pthread.c (get_stack): pthread_attr_getstack() 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.
* thread_pthread.c (thread_start_func_1): don't use inaccurate
stack start guess if native_thread_init_stack() can be used.
[Bug #1813] [ruby-core:24540]
* thread_pthread.c (get_stack): need to adjust stack addr for
[Bug #1813] on AIX.
History
Updated by charlton (Charlton Wang) almost 3 years ago
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?).
Updated by naruse (Yui NARUSE) over 2 years ago
- Category set to core
- Status changed from Open to Assigned
- Assignee set to ko1 (Koichi Sasada)
Updated by rogerdpack (Roger Pack) over 2 years ago
seems to work fine for me with 1.9.1/1.9.2 Is it still a problem?
Updated by naruse (Yui NARUSE) over 2 years ago
- Status changed from Assigned to Feedback
- Assignee deleted (
ko1 (Koichi Sasada))
Updated by naruse (Yui NARUSE) over 2 years ago
- Category set to core
- Status changed from Feedback to Open
reproduced on both Ubuntu 8.04 x86_64 and FreeBSD 8.0 x86_64.
Updated by nobu (Nobuyoshi Nakada) over 2 years ago
Seems like a stack overflow.
Updated by mame (Yusuke Endoh) about 2 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
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.
Updated by ivan (Ivan Pirlik) over 1 year ago
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).
Updated by ibc (Iñaki Baz Castillo) over 1 year ago
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
Updated by kosaki (Motohiro KOSAKI) over 1 year ago
- Status changed from Closed to Open
- Target version set to 2.0.0
This issue can be still reproduced on trunk. (ruby 1.9.3dev (2011-02-15 trunk 30882) [x86_64-linux]) reopened.
Updated by naruse (Yui NARUSE) 11 months ago
- Status changed from Open to Assigned
- Assignee set to kosaki (Motohiro KOSAKI)
- % Done changed from 100 to 0
Updated by kosaki (Motohiro KOSAKI) 11 months 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) 11 months 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.