Bug #16265
closedTest (spec) failure using current MSYS2 tools, related to -fstack-protector and possibly D_FORTIFY_SOURCE=2
Description
GH PR https://github.com/ruby/ruby/pull/2573 was a work-around that forced using some non-current MSYS2 packages libraries for building. These libraries are only available on Appveyor because their images are out-of-date, a new MSYS2 install would not have them.
Using current MSYS2 libraries requires adding '-fstack-protector' to LDFLAGS. I also experimented with adding 'D_FORTIFY_SOURCE=2' to CFLAGS.
Ruby build/compiles with those flags added. test-all passes. But spec tests always lock up when running:
C-API Thread function rb_thread_call_without_gvl
- runs a C function with the global lock unlocked
- runs a C function with the global lock unlocked amd unlocks IO with the generic RUBY_UBF_IO
The tests are in spec/ruby/optional/capi/thread_spec.rb, as shown:
and the freeze occurs on line 137.
I've run this once in ruby-loco, twice in my ruby fork, and several times locally. In all runs, test-all passed, and spec stopped at the test above. This uses gcc 9.2.0, and the problem would occur with anyone doing a 'fresh' install of MSYS2.
Not being a c type, this is way beyond what I can fix. Happy to try patches, etc. Thanks, Greg
Updated by MSP-Greg (Greg L) over 3 years ago
I bypassed the spec mentioned above:
C-API Thread function rb_thread_call_without_gvl
- runs a C function with the global lock unlocked and unlocks IO with the generic RUBY_UBF_IO
and with it bypassed, all tests/specs reliably pass on MinGW. Since most of the CI that uses gcc is done on versions older than the current MSYS2 version (9.2.0), I don't know whether it's a general problem or just Windows related.
Either way, anyone doing a fresh MSYS2 install and then building Ruby will have issues without changes to flags and the above test/spec.
Updated by MSP-Greg (Greg L) over 3 years ago
PR https://github.com/ruby/ruby/pull/2718 shows this issue, and also properly updates MSYS2/MinGW gcc.
Updated by ioquatix (Samuel Williams) 15 days ago
For some reason, this also started breaking on Windows in this PR and I had to disable it https://github.com/ruby/ruby/pull/7827/files
I cannot see how anything in my PR would impact the test that was hanging.
It seems like it might relate to the method length, so I might try reworking the PR to move the pread
/pwrite
functionality into a separate function completely.
However, I don't see why it should matter at all.
Updated by ioquatix (Samuel Williams) 14 days ago
I'm going to see if we can fix this.
Updated by ioquatix (Samuel Williams) 14 days ago
- Assignee set to ioquatix (Samuel Williams)
Updated by ioquatix (Samuel Williams) 14 days ago
Okay, the root cause of the hang is because read
in thread_spec.c
is not rb_w32_read
. Something is clobbering the included #define read rb_w32_read
.
Updated by ioquatix (Samuel Williams) 14 days ago
@shyouhei (Shyouhei Urabe) Do you think we should add something like:
#ifdef _WIN32
#include "ruby/win32.h"
#endif
to ruby.h
?
Updated by ioquatix (Samuel Williams) 14 days ago
- Status changed from Open to Closed
Updated by ioquatix (Samuel Williams) 14 days ago
I'm not sure how the ubf_io
can be used as part of the public extension API on Windows, as it's unable to interrupt non-Ruby IO methods, i.e. it only works when using rb_w32_read
and rb_w32_write
.
Maybe the test should use actual IO objects, and invoke the equivalent #read
and #write
methods rather than depending on the native wrappers.