Project

General

Profile

Bug #13390

MinGW build test-all SEGV, issue in test framework or error recovery?

Added by MSP-Greg (Greg L) over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
ruby -v:
ruby 2.5.0dev (2017-03-31 trunk 58222) [x64-mingw32]
[ruby-core:80506]

Description

Today, while building trunk (64 bit MinGW), I had a 'no output' SEGV during test-all.

I think I've had this before, but I don't recall how recently, 32 or 64, etc.

The problem is in the following test:

File 'test/ruby/test_keyword.rb', line 310

310   def test_required_keyword
311     feature7701 = '[ruby-core:51454] [Feature #7701] required keyword argument'
312     o = Object.new
313     assert_nothing_raised(SyntaxError, feature7701) do
314       eval("def o.foo(a:) a; end", nil, "xyzzy")
315       eval("def o.bar(a:,**b) [a, b]; end")
316     end
317     assert_raise_with_message(ArgumentError, /missing keyword/, feature7701) {o.foo}
318     assert_raise_with_message(ArgumentError, /unknown keyword/, feature7701) {o.foo(a:0, b:1)}
319     begin
320       o.foo(a: 0, b: 1)
321     rescue => e
322       assert_equal('xyzzy', e.backtrace_locations[0].path)
323     end
324     assert_equal(42, o.foo(a: 42), feature7701)
325     assert_equal([[:keyreq, :a]], o.method(:foo).parameters, feature7701)
326   
327     bug8139 = '[ruby-core:53608] [Bug #8139] required keyword argument with rest hash'
328     assert_equal([42, {}], o.bar(a: 42), feature7701)
329     assert_equal([42, {c: feature7701}], o.bar(a: 42, c: feature7701), feature7701)
330     assert_equal([[:keyreq, :a], [:keyrest, :b]], o.method(:bar).parameters, feature7701)
331     assert_raise_with_message(ArgumentError, /missing keyword/, bug8139) {o.bar(c: bug8139)}
332     assert_raise_with_message(ArgumentError, /missing keyword/, bug8139) {o.bar}
333   end

Now, the part where it gets fun is that I originally thought the error was between lines 319-323. I moved out of the build framework, simplified it, and things seemed okay. All errors were raised, backtraces were correct, etc.

As I tested further, here's what I found:

  1. If lines 317 & 318 are commented out, the 319-323 block runs as it should, or line 322 is 'correct'.

  2. If lines 317 & 318 are not commented out, line 320 must be commented out for the method to finish.

  3. Otherwise, a 'no output' SEGV...

History

Updated by MSP-Greg (Greg L) over 2 years ago

Just ran the test file fifty (50) times on ruby 2.5.0dev (2017-03-29 trunk 58201) [x64-mingw32], and it ran fine (no comments required). I'll try to build some intermediate svn's to narrow the issue to fewer commits.

Updated by MSP-Greg (Greg L) over 2 years ago

This patch is no longer needed as of builds around ruby 2.5.0dev (2017-04-17 trunk 58383) [x64-mingw32]. It may return when I get around to building 2.4 and 2.3 stable branches. Please close.

Updated by naruse (Yui NARUSE) over 2 years ago

  • Assignee set to nobu (Nobuyoshi Nakada)
  • Status changed from Open to Assigned

Updated by MSP-Greg (Greg L) over 2 years ago

As mentioned in 13542, I have not had a failure with this for a while, even when using -j3, which is when the issue typically occurred.

Please close, as I cannot.

Updated by Eregon (Benoit Daloze) over 2 years ago

  • Status changed from Assigned to Closed

Closing per OP request

Also available in: Atom PDF