Alyssa Ross, FreeAgent
I’m struggling to run our website on my computer. Middleman keeps crashing with this error (happened 6 times in the last 30minutes). Does anyone know how to fix it? Thank you!
[NOTE] You may have encountered a bug in the Ruby interpreter or extension libraries. Bug reports are welcome. For details: http://www.ruby-lang.org/bugreport.html
ab -n 1000 -c 10 http://localhost:4567
[NOTE] You may have encountered a bug in the Ruby interpreter or extension libraries.
FastImage finds the size or type of an image given its uri by fetching as little as needed
require "fastimage"
Array.new(500) {
Thread.new {
FastImage.size("source/components/images/homepage/opengraph/empathy.png")
}
}.each(&:join)
[NOTE] You may have encountered a bug in the Ruby interpreter or extension libraries.
git clone https://github.com/ruby/ruby
git bisect good v2_3_7
git bisect bad v2_4_0
git bisect run sh -c './configure && make && ./ruby test.rb'
thread_pthread.c: enable thread cache by default
diff --git a/thread_pthread.c b/thread_pthread.c
index 775c32a6a7..91d7215914 100644
--- a/thread_pthread.c
+++ b/thread_pthread.c
@@ -432,7 +432,7 @@ native_thread_destroy(rb_thread_t *th)
}
#ifndef USE_THREAD_CACHE
-#define USE_THREAD_CACHE 0
+#define USE_THREAD_CACHE 1
#endif
#if USE_THREAD_CACHE
Revision 60440
Use rb_execution_context_t instead of rb_thread_t to represent execution context [Feature #14038]
Bug #15250
Getting the segfault doesn’t require nearly that many iterations or threads, I just made sure to do it a lot so I could reproduce it consistently. I’ve seen it fail with as few as 20 threads.
The IO isn’t necessary either. The Fiber just needs to have some work to do. I got it to break once by just yielding “hello world”. The IO is more consistent, though.
I came across this bug in the wild when using the fastimage gem in a few threads (from middleman), which uses a Fiber to wrap IO operations.
I’ve been able to reproduce on macOS 10.13, and SmartOS 2017Q4 (Solaris). I have not been able to reproduce on Linux.
As best I can tell, the crash was introduced by r60440. It is present in Ruby 2.5.x when compiled with the default configuration. It is not present in 2.4.x. It’s also present in trunk, but only if USE_THREAD_CACHE is disabled. (Or at least, I can’t reproduce it with thread caching enabled.)
Sounds like a duplicate of #14561. It should be fixed on trunk already.
Yes! I can confirm that this now appears to be fixed on trunk.
Join us in Dev Platform at FreeAgent!
https://www.freeagent.com/careers/
7573 56D7 79BB B888 773E
415E 736C CDF9 EF51 BD97