From: shyouhei@... Date: 2017-04-20T03:20:26+00:00 Subject: [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: