Open manueljacob opened 1 month ago
Apparently caused by https://github.com/rspec/rspec-support/pull/581 Would you like to try a different approach? Maybe stash the original method like we do for mutexes?
Apparently caused by #581
Yes. I had tracked down the issue to 01eb9b2a97f47202daa4947b5dc1c7046065faa0, but I forgot to mention this in the report. Sorry for that!
Would you like to try a different approach? Maybe stash the original method like we do for mutexes?
If I understood correctly, mutexes use a copy of the stdlib code. Because Thread.current.thread_variable_get
is implemented in C, I changed the code to save a reference to the original methods. See #606.
Mocking
Thread.current.thread_variable_get
used to work with rspec-support <= 3.12.0. With rspec-support >= 3.12.1, it causes a stack overflow.Your environment
Analysis
There is infinite recursion between the following steps:
RSpec::Support.thread_local_data
.RSpec::Support.thread_local_data
callsThread.current.thread_variable_get
.Thread.current.thread_variable_get
is mocked, RSpec code is called. See 1.Workaround
Add
allow(Thread.current).to receive(:thread_variable_get).with(:__rspec).and_call_original
.The intention of the original code was to mock only
Thread.current.thread_variable_get(:test)
but notThread.current.thread_variable_get
called with any other arguments. However, I could not find a way to do that.Proposed solution
If some mocked method is called from internal RSpec code, it should do nothing but delegate to the original method.