require "tempfile"
GC.stress = true
t = Thread.new do
temp = Tempfile.new("tmp")
temp << "something"
temp = nil
h = Hash.new
end
t.join
Our analysis shows that there is a race condition in REE 1.8.7:
- When a thread finishes running, REE/Ruby dequeues it
(rb_thread_remove) from the global thread list and calls
rb_thread_schedule in order to schedule another thread to run.
- rb_thread_schedule invokes rb_gc_finalize_deferred before
scheduling another thread.
- rb_gc_finalize calls finalizer on Ruby Tempfile object. The
finalizer closes a file descriptor by calling rb_thread_fd_close
- rb_thread_fd_close has a loop to iterate over all threads.
- However, the current thread is already dequeued (it points to other
threads, but no threads point back to it), so the loop is actually an
infinite loop.
We believe this issue also exists in regular Ruby 1.8.7, but we cannot
reproduce it. Is this a bug in REE 1.8.7?
Actually, regular Ruby 1.8.7-p330 does not has this issue.
The regular Ruby 1.8.7 finalizes objects every time a node is evaled
if some conditions are met, so the temp file object (temp) is
finalized before the thread exists. Everything should be fine.
Therefore, this is a bug in current REE 1.8.7
On Jan 17, 4:34 pm, WU Chehai <wuche...@gmail.com> wrote:
> require "tempfile"
> GC.stress = true
> t = Thread.new do
> temp = Tempfile.new("tmp")
> temp << "something"
> temp = nil
> h = Hash.new
> end
> t.join
> Our analysis shows that there is a race condition in REE 1.8.7:
> - When a thread finishes running, REE/Ruby dequeues it
> (rb_thread_remove) from the global thread list and calls
> rb_thread_schedule in order to schedule another thread to run.
> - rb_thread_schedule invokes rb_gc_finalize_deferred before
> scheduling another thread.
> - rb_gc_finalize calls finalizer on Ruby Tempfile object. The
> finalizer closes a file descriptor by calling rb_thread_fd_close
> - rb_thread_fd_close has a loop to iterate over all threads.
> - However, the current thread is already dequeued (it points to other
> threads, but no threads point back to it), so the loop is actually an
> infinite loop.
> We believe this issue also exists in regular Ruby 1.8.7, but we cannot
> reproduce it. Is this a bug in REE 1.8.7?
It was causing a horrible fault for us where the readfds for the curr thread would get nulled out; thus you wait on nothing for the full timeout (in Net::HTTP) in this case.
REE also calls rb_gc_finalize_deferred() at the end of a collection, so I think you can apply the same patch.
On Tue, Jan 18, 2011 at 5:45 PM, WU Chehai <wuche...@gmail.com> wrote: > Actually, regular Ruby 1.8.7-p330 does not has this issue.
> The regular Ruby 1.8.7 finalizes objects every time a node is evaled > if some conditions are met, so the temp file object (temp) is > finalized before the thread exists. Everything should be fine.
> Therefore, this is a bug in current REE 1.8.7
> On Jan 17, 4:34 pm, WU Chehai <wuche...@gmail.com> wrote: >> Hi, all
>> The following code ends up an infinite loop
>> require "tempfile" >> GC.stress = true >> t = Thread.new do >> temp = Tempfile.new("tmp") >> temp << "something" >> temp = nil >> h = Hash.new >> end >> t.join
>> Our analysis shows that there is a race condition in REE 1.8.7:
>> - When a thread finishes running, REE/Ruby dequeues it >> (rb_thread_remove) from the global thread list and calls >> rb_thread_schedule in order to schedule another thread to run.
>> - rb_thread_schedule invokes rb_gc_finalize_deferred before >> scheduling another thread.
>> - rb_gc_finalize calls finalizer on Ruby Tempfile object. The >> finalizer closes a file descriptor by calling rb_thread_fd_close
>> - rb_thread_fd_close has a loop to iterate over all threads.
>> - However, the current thread is already dequeued (it points to other >> threads, but no threads point back to it), so the loop is actually an >> infinite loop.
>> We believe this issue also exists in regular Ruby 1.8.7, but we cannot >> reproduce it. Is this a bug in REE 1.8.7?
>> Thanks
> -- > You received this message because you are subscribed to the Google Groups "Ruby Enterprise Edition" group. > To post to this group, send email to emm-ruby@googlegroups.com. > To unsubscribe from this group, send email to emm-ruby+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/emm-ruby?hl=en.
> It was causing a horrible fault for us where the readfds for the curr
> thread would get nulled out; thus you wait on nothing for the full
> timeout (in Net::HTTP) in this case.
> REE also calls rb_gc_finalize_deferred() at the end of a collection,
> so I think you can apply the same patch.
> Evan
> On Tue, Jan 18, 2011 at 5:45 PM, WU Chehai <wuche...@gmail.com> wrote:
> > Actually, regular Ruby 1.8.7-p330 does not has this issue.
> > The regular Ruby 1.8.7 finalizes objects every time a node is evaled
> > if some conditions are met, so the temp file object (temp) is
> > finalized before the thread exists. Everything should be fine.
> > Therefore, this is a bug in current REE 1.8.7
> > On Jan 17, 4:34 pm, WU Chehai <wuche...@gmail.com> wrote:
> >> Hi, all
> >> Our analysis shows that there is a race condition in REE 1.8.7:
> >> - When a thread finishes running, REE/Ruby dequeues it
> >> (rb_thread_remove) from the global thread list and calls
> >> rb_thread_schedule in order to schedule another thread to run.
> >> - rb_thread_schedule invokes rb_gc_finalize_deferred before
> >> scheduling another thread.
> >> - rb_gc_finalize calls finalizer on Ruby Tempfile object. The
> >> finalizer closes a file descriptor by calling rb_thread_fd_close
> >> - rb_thread_fd_close has a loop to iterate over all threads.
> >> - However, the current thread is already dequeued (it points to other
> >> threads, but no threads point back to it), so the loop is actually an
> >> infinite loop.
> >> We believe this issue also exists in regular Ruby 1.8.7, but we cannot
> >> reproduce it. Is this a bug in REE 1.8.7?
> >> Thanks
> > --
> > You received this message because you are subscribed to the Google Groups "Ruby Enterprise Edition" group.
> > To post to this group, send email to emm-ruby@googlegroups.com.
> > To unsubscribe from this group, send email to emm-ruby+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/emm-ruby?hl=en.
> > It was causing a horrible fault for us where the readfds for the curr > > thread would get nulled out; thus you wait on nothing for the full > > timeout (in Net::HTTP) in this case.
> > REE also calls rb_gc_finalize_deferred() at the end of a collection, > > so I think you can apply the same patch.
> > Evan
> > On Tue, Jan 18, 2011 at 5:45 PM, WU Chehai <wuche...@gmail.com> wrote: > > > Actually, regular Ruby 1.8.7-p330 does not has this issue.
> > > The regular Ruby 1.8.7 finalizes objects every time a node is evaled > > > if some conditions are met, so the temp file object (temp) is > > > finalized before the thread exists. Everything should be fine.
> > > Therefore, this is a bug in current REE 1.8.7
> > > On Jan 17, 4:34 pm, WU Chehai <wuche...@gmail.com> wrote: > > >> Hi, all
> > >> The following code ends up an infinite loop
> > >> Our analysis shows that there is a race condition in REE 1.8.7:
> > >> - When a thread finishes running, REE/Ruby dequeues it > > >> (rb_thread_remove) from the global thread list and calls > > >> rb_thread_schedule in order to schedule another thread to run.
> > >> - rb_thread_schedule invokes rb_gc_finalize_deferred before > > >> scheduling another thread.
> > >> - rb_gc_finalize calls finalizer on Ruby Tempfile object. The > > >> finalizer closes a file descriptor by calling rb_thread_fd_close
> > >> - rb_thread_fd_close has a loop to iterate over all threads.
> > >> - However, the current thread is already dequeued (it points to other > > >> threads, but no threads point back to it), so the loop is actually an > > >> infinite loop.
> > >> We believe this issue also exists in regular Ruby 1.8.7, but we > cannot > > >> reproduce it. Is this a bug in REE 1.8.7?
> > >> Thanks
> > > -- > > > You received this message because you are subscribed to the Google > Groups "Ruby Enterprise Edition" group. > > > To post to this group, send email to emm-ruby@googlegroups.com. > > > To unsubscribe from this group, send email to > emm-ruby+unsubscribe@googlegroups.com. > > > For more options, visit this group athttp:// > groups.google.com/group/emm-ruby?hl=en.
>> > It was causing a horrible fault for us where the readfds for the curr >> > thread would get nulled out; thus you wait on nothing for the full >> > timeout (in Net::HTTP) in this case.
>> > REE also calls rb_gc_finalize_deferred() at the end of a collection, >> > so I think you can apply the same patch.
>> > Evan
>> > On Tue, Jan 18, 2011 at 5:45 PM, WU Chehai <wuche...@gmail.com> wrote: >> > > Actually, regular Ruby 1.8.7-p330 does not has this issue.
>> > > The regular Ruby 1.8.7 finalizes objects every time a node is evaled >> > > if some conditions are met, so the temp file object (temp) is >> > > finalized before the thread exists. Everything should be fine.
>> > > Therefore, this is a bug in current REE 1.8.7
>> > > On Jan 17, 4:34 pm, WU Chehai <wuche...@gmail.com> wrote: >> > >> Hi, all
>> > >> The following code ends up an infinite loop
>> > >> Our analysis shows that there is a race condition in REE 1.8.7:
>> > >> - When a thread finishes running, REE/Ruby dequeues it >> > >> (rb_thread_remove) from the global thread list and calls >> > >> rb_thread_schedule in order to schedule another thread to run.
>> > >> - rb_thread_schedule invokes rb_gc_finalize_deferred before >> > >> scheduling another thread.
>> > >> - rb_gc_finalize calls finalizer on Ruby Tempfile object. The >> > >> finalizer closes a file descriptor by calling rb_thread_fd_close
>> > >> - rb_thread_fd_close has a loop to iterate over all threads.
>> > >> - However, the current thread is already dequeued (it points to >> other >> > >> threads, but no threads point back to it), so the loop is actually >> an >> > >> infinite loop.
>> > >> We believe this issue also exists in regular Ruby 1.8.7, but we >> cannot >> > >> reproduce it. Is this a bug in REE 1.8.7?
>> > >> Thanks
>> > > -- >> > > You received this message because you are subscribed to the Google >> Groups "Ruby Enterprise Edition" group. >> > > To post to this group, send email to emm-ruby@googlegroups.com. >> > > To unsubscribe from this group, send email to emm-ruby+unsubscribe@** >> googlegroups.com <emm-ruby%2Bunsubscribe@googlegroups.com>. >> > > For more options, visit this group athttp://groups.google.com/** >> group/emm-ruby?hl=en <http://groups.google.com/group/emm-ruby?hl=en>.
> To post to this group, send email to emm-ruby@googlegroups.com. > To unsubscribe from this group, send email to > emm-ruby+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/emm-ruby?hl=en.
>>> > It was causing a horrible fault for us where the readfds for the curr >>> > thread would get nulled out; thus you wait on nothing for the full >>> > timeout (in Net::HTTP) in this case.
>>> > REE also calls rb_gc_finalize_deferred() at the end of a collection, >>> > so I think you can apply the same patch.
>>> > Evan
>>> > On Tue, Jan 18, 2011 at 5:45 PM, WU Chehai <wuche...@gmail.com> wrote: >>> > > Actually, regular Ruby 1.8.7-p330 does not has this issue.
>>> > > The regular Ruby 1.8.7 finalizes objects every time a node is evaled >>> > > if some conditions are met, so the temp file object (temp) is >>> > > finalized before the thread exists. Everything should be fine.
>>> > > Therefore, this is a bug in current REE 1.8.7
>>> > > On Jan 17, 4:34 pm, WU Chehai <wuche...@gmail.com> wrote: >>> > >> Hi, all
>>> > >> The following code ends up an infinite loop
>>> > >> Our analysis shows that there is a race condition in REE 1.8.7:
>>> > >> - When a thread finishes running, REE/Ruby dequeues it >>> > >> (rb_thread_remove) from the global thread list and calls >>> > >> rb_thread_schedule in order to schedule another thread to run.
>>> > >> - rb_thread_schedule invokes rb_gc_finalize_deferred before >>> > >> scheduling another thread.
>>> > >> - rb_gc_finalize calls finalizer on Ruby Tempfile object. The >>> > >> finalizer closes a file descriptor by calling rb_thread_fd_close
>>> > >> - rb_thread_fd_close has a loop to iterate over all threads.
>>> > >> - However, the current thread is already dequeued (it points to >>> > >> other >>> > >> threads, but no threads point back to it), so the loop is actually >>> > >> an >>> > >> infinite loop.
>>> > >> We believe this issue also exists in regular Ruby 1.8.7, but we >>> > >> cannot >>> > >> reproduce it. Is this a bug in REE 1.8.7?
>>> > >> Thanks
>>> > > -- >>> > > You received this message because you are subscribed to the Google >>> > > Groups "Ruby Enterprise Edition" group. >>> > > To post to this group, send email to emm-ruby@googlegroups.com. >>> > > To unsubscribe from this group, send email to >>> > > emm-ruby+unsubscribe@googlegroups.com. >>> > > For more options, visit this group >>> > > athttp://groups.google.com/group/emm-ruby?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby Enterprise Edition" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/emm-ruby/-/bbyHMt0GSDkJ.
>> To post to this group, send email to emm-ruby@googlegroups.com. >> To unsubscribe from this group, send email to >> emm-ruby+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/emm-ruby?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Ruby Enterprise Edition" group. > To post to this group, send email to emm-ruby@googlegroups.com. > To unsubscribe from this group, send email to > emm-ruby+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/emm-ruby?hl=en.
> >>> > It was causing a horrible fault for us where the readfds for the curr > >>> > thread would get nulled out; thus you wait on nothing for the full > >>> > timeout (in Net::HTTP) in this case.
> >>> > REE also calls rb_gc_finalize_deferred() at the end of a collection, > >>> > so I think you can apply the same patch.
> >>> > Evan
> >>> > On Tue, Jan 18, 2011 at 5:45 PM, WU Chehai <wuche...@gmail.com> > wrote: > >>> > > Actually, regular Ruby 1.8.7-p330 does not has this issue.
> >>> > > The regular Ruby 1.8.7 finalizes objects every time a node is > evaled > >>> > > if some conditions are met, so the temp file object (temp) is > >>> > > finalized before the thread exists. Everything should be fine.
> >>> > > Therefore, this is a bug in current REE 1.8.7
> >>> > > On Jan 17, 4:34 pm, WU Chehai <wuche...@gmail.com> wrote: > >>> > >> Hi, all
> >>> > >> The following code ends up an infinite loop
> >>> > >> Our analysis shows that there is a race condition in REE 1.8.7:
> >>> > >> - When a thread finishes running, REE/Ruby dequeues it > >>> > >> (rb_thread_remove) from the global thread list and calls > >>> > >> rb_thread_schedule in order to schedule another thread to run.
> >>> > >> - rb_thread_schedule invokes rb_gc_finalize_deferred before > >>> > >> scheduling another thread.
> >>> > >> - rb_gc_finalize calls finalizer on Ruby Tempfile object. The > >>> > >> finalizer closes a file descriptor by calling rb_thread_fd_close
> >>> > >> - rb_thread_fd_close has a loop to iterate over all threads.
> >>> > >> - However, the current thread is already dequeued (it points to > >>> > >> other > >>> > >> threads, but no threads point back to it), so the loop is actually > >>> > >> an > >>> > >> infinite loop.
> >>> > >> We believe this issue also exists in regular Ruby 1.8.7, but we > >>> > >> cannot > >>> > >> reproduce it. Is this a bug in REE 1.8.7?
> >>> > >> Thanks
> >>> > > -- > >>> > > You received this message because you are subscribed to the Google > >>> > > Groups "Ruby Enterprise Edition" group. > >>> > > To post to this group, send email to emm-ruby@googlegroups.com. > >>> > > To unsubscribe from this group, send email to > >>> > > emm-ruby+unsubscribe@googlegroups.com. > >>> > > For more options, visit this group > >>> > > athttp://groups.google.com/group/emm-ruby?hl=en.
> >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Ruby Enterprise Edition" group. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msg/emm-ruby/-/bbyHMt0GSDkJ.
> >> To post to this group, send email to emm-ruby@googlegroups.com. > >> To unsubscribe from this group, send email to > >> emm-ruby+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/emm-ruby?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby Enterprise Edition" group. > > To post to this group, send email to emm-ruby@googlegroups.com. > > To unsubscribe from this group, send email to > > emm-ruby+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/emm-ruby?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Ruby Enterprise Edition" group. > To post to this group, send email to emm-ruby@googlegroups.com. > To unsubscribe from this group, send email to > emm-ruby+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/emm-ruby?hl=en.
