Bug #14049: SEGV svn 60401 require_relative

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.5.0dev (2017-10-24 trunk 60401) [x64-mingw32] SEGV fault
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN
• Tags: core, win

[MSP-Greg (Greg L)]

Once again, MinGW builds are passing test-all, but I'm having issues when running the code for my doc site.

I've got a SEGV in an rb file that starts with several require_relative commands. I haven't tried to isolate it, but if that would be helpful, please let me know. SEGV log files attached.

ruby 2.5.0dev (2017-10-24 trunk 60388) [x64-mingw32]   NO fault, works fine
ruby 2.5.0dev (2017-10-24 trunk 60401) [x64-mingw32]   SEGV fault
ruby 2.5.0dev (2017-10-24 trunk 60403) [x64-mingw32]   SEGV fault

It's odd, because (from commit comments) I assume these changes are due to the recent running failures in the Appveyor mswin build. During that time, MinGW trunk builds were still passing tests and working with my doc site update code.

But, test-all was running slower, and also showing fewer assertions. Table of results here.

Thanks, and thanks to everyone who contributed this weekend, Greg

[shevegen (Robert A. Heiler)]

I applaude you for your heroic work on MinGW. I don't think anyone else may have had
the patience - or stubborness. :)

[normalperson (Eric Wong)]

[e-mail] wrote:

ruby 2.5.0dev (2017-10-24 trunk 60388) [x64-mingw32] NO fault, works fine

OK, so r60386 (which affects file.c) did not break things? nobu
spotted a possible bug [ruby-core:83535] which may be fixed in
r60408.

But, test-all was running slower, and also showing fewer
assertions. Table of results
here.

r60386 does hurt single-thread performance if the GVL
implementation is slow.

Is it significantly faster with r60408 and r60386 reverted?
Maybe GVL release can be ignored if only one thread is running.

[MSP-Greg (Greg L)]

Eric,

Well, I did not revert 60386, but I still have the SEGV after building 60408. Of course, test-all, etc all pass...

Right now, I'm more concerned about the SEGV, as my builds are used by other repos in Appveyor CI testing. It also breaks my doc site updates, which I typically do twice a day.

Re single thread, I seem to get more reliable test-all numbers when running 'single', but I may change my build system over to -j2 for the tests.

I'll have more time to look at this tomorrow. I'll see if I can come up with some code to repro the SEGV...

Thanks again, Greg

[MSP-Greg (Greg L)]

I did some more work with this. The SEGV is happening from one particular file being loaded via relative_require, and although the SEGV log seems to indicate that as the 'last' function, the issue seems to be a parsing issue, which I've narrowed down to the statement, but I haven't reduced it to a simple test case.

Re test-all assertions and test-all time, as of ruby 2.5.0dev (2017-10-26 trunk 60450) [x64-mingw32], test run times are lower than I've ever seen them. But, the test and assertion counts have dropped, so I will investigate further.

To match up better with Travis and Appveyor mswin, I'm now running test-all, test-spec, and mspec parallel (-j2 on test-all, -j on specs).

Also, the rolling ruby-loco trunk build is now running three times a day at Noon, 6:00 P and 1:00 A JST.

Finally (with my limited *nix scripting skills) I created a companion to appveyor-ruby on Travis, travis-ruby. It shows info on default and available Ruby builds. I created it mostly to see what library versions were used to compile the various version. I'll update it manually as I notice changes. Some interesting version differences:

           rvm      mingw    
GDBM      1.8.3     1.10
LIBYAML   0.1.4     0.1.7
OpenSSL   1.0.1f    1.1.0f
Readline  6.3       7.0
Zlib      1.2.8     1.2.11

Thanks again. Some info might be helpful for people, otherwise, please close in a few days...

@shevegen - Thank you. Someone has to do it. I've been using and coding on Windows since DOS days, and in traditional corporate America, it's still the standard...

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed