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) almost 5 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) almost 5 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) over 1 year 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) over 1 year ago
I'm going to see if we can fix this.
Updated by ioquatix (Samuel Williams) over 1 year ago
- Assignee set to ioquatix (Samuel Williams)
Updated by ioquatix (Samuel Williams) over 1 year 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) over 1 year 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) over 1 year ago
- Status changed from Open to Closed
Updated by ioquatix (Samuel Williams) over 1 year 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.