From: davidnwelton@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:96343] [Ruby master Bug#16288] Segmentation fault with finalizers, threads
Date: Thu, 19 Dec 2019 19:46:18 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-83251.20191219194616.8fe4a276ee3e4a1e@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16288.20191031230209@ruby-lang.org
Issue #16288 has been updated by davidw (David Welton).
> --- a/thread.c
> +++ b/thread.c
> @@ -682,7 +682,7 @@ thread_do_start(rb_thread_t *th)
> else {
> args_ptr = RARRAY_CONST_PTR(args);
> }
> -
> + rb_funcallv(NULL, idInspect, 0, 0);
> th->value = rb_vm_invoke_proc(th->ec, proc,
> (int)args_len, args_ptr,
> VM_BLOCK_HANDLER_NONE);
>
I replaced the funcall with
RUBY_VM_CHECK_INTS(GET_EC());
And everything seems to work ok.
I realized that even in 'normal' circumstances, Ruby does not wait for threads to finish; the programmer must request that, so I'm not sure that's actually correct.
With the above patch, I don't get the segfault any more.
I don't have nearly enough familiarity with the internals to know if this is actually the best or most correct way of fixing the problem though.
Thank you
----------------------------------------
Bug #16288: Segmentation fault with finalizers, threads
https://bugs.ruby-lang.org/issues/16288#change-83251
* Author: davidw (David Welton)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.6.6p116 (2019-10-02 revision 67825) [x86_64-linux]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
Hi,
This is a tricky one and I am still working on narrowing it down, but I will report what I have so far.
I compiled a version of 2_6_6 from github: ruby 2.6.6p116 (2019-10-02 revision 67825) [x86_64-linux]
I have a minimal Rails project that uses Mongoid. It crashes with a segmentation fault when rspec runs. The concurrent ruby gem is in some way involved, and I have been posting there: https://github.com/ruby-concurrency/concurrent-ruby/issues/808
However, I think there is a deeper problem - I would not expect a user level script to cause a segmentation fault.
I have been putting a lot of debugging statements in, and turned on Thread.DEBUG, and have noticed some things. I am not experienced with Ruby's internals, so some of these bits of data might be normal or irrelevant:
* The concurrent-ruby gem uses ObjectSpace.define_finalizer to set a finalizer
* That finalizer creates a new Thread
* However, it appears as if that thread is running after the main thread is already dead, so code that expects to reference the main thread crashes, because it's a NULL reference.
I tried the following test code:
```
class Foo
def initialize
ObjectSpace.define_finalizer(self, proc do
Foo.foo_finalizer
end)
end
def bar
puts 'bar'
end
def Foo.foo_finalizer
puts "foo_finalizer"
t = Thread.new do
puts "Thread reporting for duty"
end
puts "foo_finalizer thread launched"
sleep 5
end
end
f = Foo.new
f.bar
f = nil
```
While trying to develop a simple test case to demonstrate the problem. It triggers rb_raise(rb_eThreadError, "can't alloc thread"); in thread_s_new, because it looks like the main thread has already been marked as 'killed' in this case. When I check the main thread status in thread_s_new with the above code, it reports 'dead'.
When I run my rspec code in the sample Rails project, thread_s_new shows the main thread's status as 'run' even if it should be dead?
I have seen some debugging things that shows some exceptions and thread_join interrupts and so on.
Is it possible that something like this is happening?
Main thread starts doing a cleanup, and gets an exception or something that generates an interrupt, and its KILLED status gets reset to RUNNABLE
Then, in the finalizer, it starts creating a Thread, but at this point the main thread actually does get killed, and when that finalizer thread tries to run it runs into a null reference?
I can provide the Rails sample project if needs be.
Sorry if any of the above isn't clear; I've been staring at the C code for several hours and am a bit cross-eyed!
Thank you for any insights.
--
https://bugs.ruby-lang.org/
prev parent reply other threads:[~2019-12-19 19:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-16288.20191031230209@ruby-lang.org>
2019-10-31 23:02 ` [ruby-core:95620] [Ruby master Bug#16288] Segmentation fault with finalizers, threads davidnwelton
2019-11-01 16:14 ` [ruby-core:95637] " davidnwelton
2019-11-02 1:22 ` [ruby-core:95650] " mame
2019-11-04 17:11 ` [ruby-core:95672] " davidnwelton
2019-11-04 21:49 ` [ruby-core:95682] " davidnwelton
2019-11-14 3:45 ` [ruby-core:95847] " davidnwelton
2019-12-10 1:16 ` [ruby-core:96182] " davidnwelton
2019-12-19 19:46 ` davidnwelton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-83251.20191219194616.8fe4a276ee3e4a1e@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).