From: ko1@...
Date: 2015-11-25T01:35:07+00:00
Subject: [ruby-core:71670] [Ruby trunk - Bug #11549] Object allocation during garbage collection phase terminates the Ruby process

Issue #11549 has been updated by Koichi Sasada.


* Are you saying there exists a single specific thread, and only that specific single thread will run garbage collection?

Yes.

* Are you saying that if any C extension invokes rb_thread_call_without_gvl(), and that a different thread performs I/O and awaits I/O completion (that permits a yet different thread to run), then there exists the possibility of an interpreter crash (due to the different thread that was switched to allocating an object)?

rb_thread_call_without_gvl() invoke a *C* function. The C function should not run any Ruby code (there are several limitation, but I don't recommend to use it if you can not understand what you do).

Waiting an I/O operation is nice. But the result (read file, or something) should be wrapped *after* the C function invoked by rb_thread_call_without_gvl().

The following code is pseudo-code like C.

```C
char buff[100]; /* example :) */

func()
{
  long_operation(buff);
}

VALUE
ruby_method(self){
  ...
  // release GVL and call func.
  rb_thread_call_without_gvl(func);
  // acquire GVL again, at this point.
  return rb_str_new_cstr(buff);
}
```

More details, see rb_thread_call_without_gvl() document.


----------------------------------------
Bug #11549: Object allocation during garbage collection phase terminates the Ruby process
https://bugs.ruby-lang.org/issues/11549#change-55072

* Author: Charles Leu
* Status: Feedback
* Priority: Normal
* Assignee: Koichi Sasada
* ruby -v: ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
Multi-Threaded Ruby apps are often problematic; especially so when utilizing thread pools, and scheduling work to worker threads.

RE: attached file ruby_2.2.3_obj_alloc_gc_bug.txt

Following is the section of sap_consumer_control.rb that is presented by the Ruby interpreter as being the current execution context when the problem occurs.

408: loop do
409:   @worker_threads.schedule(@work_queue.pop, &@consumer)
410:   @sap_packets_consumed += 1
411: end

Notes:
* @work_queue is a Ruby Queue (allocated within the main thread) into which a producer thread places work requests.
* @worker_threads is a thread pool (allocated within the main thread).
* @worker_threads schedule method simply puts a work request into the thread pool's internal work queue.  One of the worker threads within the thread pool will consume/effect the work request, by executing the specified consumer Proc.
* The main program thread simply loops forever scheduling work to thread pool threads.
* It appears that an object is being allocated by virtue of the @work_queue.pop

Questions:
* Does Ruby garbage collection potentially run within each thread context?
* If answer to prior question is 'Yes', then how can object allocation be prevented when a sibling thread is attempting garbage collection?
* How does one write multi-threaded Ruby apps on multi-core systems that permit multiple-concurrent execution contexts that don't employ a mutex to effectively single thread the entire app? 

---Files--------------------------------
ruby_2.2.3_obj_alloc_gc_bug.txt (49.1 KB)


-- 
https://bugs.ruby-lang.org/