Issue #11549 has been updated by Koichi Sasada.


Koichi Sasada wrote:
> Charles Leu wrote:
> > * Per the C level backtrace information (and my potentially flawed interpretation) it appears that a string is being allocated and gc is being invoked within the context of io_getpartial:
> 
> Yes. But it seems no problem.
> 
> Can you insert a probe by GDB and show all machine level (C level) stack trace for all threads?
> [BUG] back trace only shows the current thread back trace.
> 
> ```
> gdb --args [ruby command]
> (gdb) run
> ... (running)
> (gdb) info threads
> (gdb) thread [n] (where n is available threads)
> (gdb) bt
> ...
> ```
> 
> Maybe there is shell like macro to do it automatically, but I don't know how.



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

* 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)
ruby_bug_redis_connection.txt (53.3 KB)


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