[ruby-core:80802] [Ruby trunk Bug#13481][Closed] MinGW, test-all SEGV in TestLambdaParameters#test_call_simple

Issue #13481 has been updated by shyouhei (Shyouhei Urabe).

Status changed from Open to Closed

Glad to hear that.  Thank you for your cooperation.

----------------------------------------
Bug #13481: MinGW, test-all SEGV in TestLambdaParameters#test_call_simple
https://bugs.ruby-lang.org/issues/13481#change-64395

* Author: MSP-Greg (Greg L)
* Status: Closed
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.5.0dev (2017-04-18 trunk 58397) [x64-mingw32]
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
A MinGW build of `ruby 2.5.0dev (2017-04-18 trunk 58397) [x64-mingw32]` had a silent SEGV when running  [`TestLambdaParameters#test_call_simple`](https://github.com/ruby/ruby/blob/d939fdc119ce274d50114addbc83aa6ee0bfad9c/test/ruby/test_lambda.rb#L10) in `test/ruby/test_lambda.rb`.

The silent SEGV occurs on the following two commented lines:

```ruby
  def test_call_simple
    assert_equal(1, lambda{|a| a}.call(1))
    assert_equal([1,2], lambda{|a, b| [a,b]}.call(1,2))
    assert_raise(ArgumentError) { lambda{|a|}.call(1,2) }
    assert_raise(ArgumentError) { lambda{|a|}.call() }
    assert_raise(ArgumentError) { lambda{}.call(1) }
#   assert_raise(ArgumentError) { lambda{|a, b|}.call(1,2,3) }

    assert_equal(1, ->(a){ a }.call(1))
    assert_equal([1,2], ->(a,b){ [a,b] }.call(1,2))
    assert_raise(ArgumentError) { ->(a){ }.call(1,2) }
    assert_raise(ArgumentError) { ->(a){ }.call() }
    assert_raise(ArgumentError) { ->(){ }.call(1) }
#   assert_raise(ArgumentError) { ->(a,b){ }.call(1,2,3) }
  end
```

This ocurred when running `make test-all` or in a test framework run directly from ruby.

But, the following runs fine, via either irb or ruby -e:

```ruby
20.times { begin ; lambda{|a, b|}.call(1,2,3) ; rescue => e ; puts e.message ; end }
```

When tested with `ruby 2.5.0dev (2017-04-17 trunk 58383) [x64-mingw32]`, it ran fine regardless of the test type.

This would seem to imply something is odd with the test framework, and not the actual test.

I've been building for while (trying to establish stable results), and many builds have gone fine using `make -j3`.  My main desire was to get stable/repeatable `test-all` results.

The last two days, I had several builds that failed near the end with some form of `rb_sysopen` issue, either `Permission denied` or `Invalid argument`.  When I switched to `make -j1`, I believe almost of all of the builds completed.  I should have kept better logs, but I was getting a bit frustrated...

But now, the current svn 58397 build was done with `make -j3`.  Not sure what changed...

Recently, the `autoclose` issue came up in discussion.  Since I started building, I've need to add `sock.autoclose = false` to the starred line in [` TestSocket#test_closed_read`](https://github.com/ruby/ruby/blob/d939fdc119ce274d50114addbc83aa6ee0bfad9c/test/socket/test_socket.rb#L535) in `ruby/test/socket/test_socket.rb`. Without it, another silent SEGV both inside of `make test-all` and using the ruby framework.

```ruby
  def test_closed_read
    require 'timeout'
    require 'socket'
    bug4390 = '[ruby-core:35203]'
    server = TCPServer.new("localhost", 0)
    serv_thread = Thread.new {server.accept}
    begin sleep(0.1) end until serv_thread.stop?
*   sock = TCPSocket.new("localhost", server.addr[1]) ; sock.autoclose = false
    client_thread = Thread.new do
      sock.readline
    end
    begin sleep(0.1) end until client_thread.stop?
    Timeout.timeout(1) do
      sock.close
      sock = nil
      assert_raise(IOError, bug4390) {client_thread.join}
    end
  ensure
    serv_thread.value.close
    server.close
  end
  ```

Finally, I still require the patch for [`test/ruby/test_enum.rb`](https://github.com/ruby/ruby/blob/d6873af4bdc99914f20f6184966fa840c91bdf10/test/ruby/test_enum.rb#L559-L570), as mentioned in [Bug 13298](https://bugs.ruby-lang.org/issues/13298).  This is odd because simply adding the `to_s` stops the SEGV...

Sorry for mentioning all of these items, but I can't help but believe they may be connected, or at least point to some underlying issue with Windows/MinGW builds...



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>