Bug #14948: MinGW Failure - r64072 - test_jit.rb: test_compile_insn_putspecialobject_putiseq

• Status: Closed
• Assignee: k0kubun (Takashi Kokubun)
• Target version: -
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN

[MSP-Greg (Greg L)]

Starting with r64076, every subsequent build has failed, both in parallel & retry, on TestJIT#test_unload_units.

Finally ran it locally, below is the log of running the whole test file/suite.

Thanks again, Greg

  1) Skipped:
TestJIT#test_compile_insn_getblockparamproxy [test/ruby/test_jit.rb:94]:
support this in mjit_compile

  2) Skipped:
TestJIT#test_compile_insn_opt_call_c_function [test/ruby/test_jit.rb:527]:
support this in opt_call_c_function (low priority)

  3) Skipped:
TestJIT#test_compile_insn_reput [test/ruby/test_jit.rb:260]:
write test

  4) Skipped:
TestJIT#test_compile_insn_tracecoverage [test/ruby/test_jit.rb:291]:
write test

  5) Skipped:
TestJIT#test_compile_insn_defineclass [test/ruby/test_jit.rb:295]:
support this in mjit_compile (low priority)

  6) Failure:
TestJIT#test_unload_units [test/ruby/test_jit.rb:830]:
Failed to run script with JIT:
'''

10.times do |i|
  eval(<<-EOS)
    def mjit#{i}
      print #{i}
    end
    mjit#{i}
  EOS
end

'''


stdout:
'''

'''


stderr:
'''
JIT success (1462.4ms): block in <main>@-e:2 -> C:/Greg/temp/jit_test_clean_so_20180728-14960-771wan/_ruby_mjit_p1848u0.c
JIT success (1421.3ms): mjit0@(eval):1 -> C:/Greg/temp/jit_test_clean_so_20180728-14960-771wan/_ruby_mjit_p1848u1.c
-e:3: [BUG] Segmentation fault
ruby 2.6.0dev (2018-07-28 trunk 64082) [x64-mingw32]

-- Control frame information -----------------------------------------------
c:0005 p:---- s:0018 e:000017 CFUNC  :to_s
c:0004 p:0000 s:0014 e:000013 BLOCK  -e:3 [FINISH]
c:0003 p:---- s:0010 e:000009 CFUNC  :times
c:0002 p:0006 s:0006 e:000005 EVAL   -e:2 [FINISH]
c:0001 p:0000 s:0003 E:0008d0 (none) [FINISH]

-- Ruby level backtrace information ----------------------------------------
-e:2:in `<main>'
-e:2:in `times'
-e:3:in `block in <main>'
-e:3:in `to_s'

-- C level backtrace information -------------------------------------------
C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007ffa80979f34]
C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xa2) [0x00007ffa7db29252]
bin\x64-msvcrt-ruby260.dll(rb_print_backtrace+0x36) [0x000000006a5e65a6]
bin\x64-msvcrt-ruby260.dll(rb_vm_bugreport+0x6d) [0x000000006a5e661d]
bin\x64-msvcrt-ruby260.dll(rb_bug_context+0x69) [0x000000006a4a7719]
bin\x64-msvcrt-ruby260.dll(rb_check_safe_obj+0xd20) [0x000000006a578370]
 [0x0000000000402397]
C:\WINDOWS\System32\msvcrt.dll(_C_specific_handler+0x98) [0x00007ffa800c7c58]
C:\WINDOWS\SYSTEM32\ntdll.dll(_chkstk+0x11d) [0x00007ffa8097eced]
C:\WINDOWS\SYSTEM32\ntdll.dll(RtlWalkFrameChain+0x13f6) [0x00007ffa808e6c86]
C:\WINDOWS\SYSTEM32\ntdll.dll(KiUserExceptionDispatcher+0x2e) [0x00007ffa8097dc1e]
bin\x64-msvcrt-ruby260.dll(rb_class_real+0x5) [0x000000006a50ff65]
bin\x64-msvcrt-ruby260.dll(rb_class_name+0x9) [0x000000006a5c4e79]
bin\x64-msvcrt-ruby260.dll(rb_inspect+0x188) [0x000000006a5102f8]
 [0x00000000704c6888]
 [0x00000000704c760e]
 [0x00000000704c9768]
C:\Greg\temp\jit_test_clean_so_20180728-14960-771wan\_ruby_mjit_p1848u0.so(mjit0+0x2a1) [0x00000000704ca231]
bin\x64-msvcrt-ruby260.dll(rb_vm_exec+0x6f7) [0x000000006a5d2c67]
bin\x64-msvcrt-ruby260.dll(rb_yield_1+0x2e5) [0x000000006a5defc5]
bin\x64-msvcrt-ruby260.dll(rb_int_abs+0x3e1) [0x000000006a5025b1]
bin\x64-msvcrt-ruby260.dll(rb_error_arity+0x10b) [0x000000006a5cc1fb]
bin\x64-msvcrt-ruby260.dll(rb_yield_block+0xc48) [0x000000006a5dffb8]
bin\x64-msvcrt-ruby260.dll(rb_check_funcall+0x197b) [0x000000006a5d9d2b]
bin\x64-msvcrt-ruby260.dll(rb_vm_exec+0x9e) [0x000000006a5d260e]
bin\x64-msvcrt-ruby260.dll(rb_call_end_proc+0x189) [0x000000006a4aaf09]
bin\x64-msvcrt-ruby260.dll(ruby_run_node+0x59) [0x000000006a4ae1c9]
 [0x0000000000402ccb]
 [0x00000000004013c7]
 [0x00000000004014fb]
C:\WINDOWS\System32\KERNEL32.DLL(BaseThreadInitThunk+0x14) [0x00007ffa803c3034]

-- Other runtime information -----------------------------------------------

* Loaded script: -e

* Loaded features:

    0 enumerator.so
    1 thread.rb
    2 rational.so
    3 complex.so
    4 lib/ruby/2.6.0/x64-mingw32/enc/encdb.so
    5 lib/ruby/2.6.0/x64-mingw32/enc/trans/transdb.so
    6 lib/ruby/2.6.0/x64-mingw32/enc/windows_1252.so

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html


'''

.
<true> expected but was
<false>.

Finished tests in 236.887729s, 0.3293 tests/s, 1.9967 assertions/s.
78 tests, 473 assertions, 1 failures, 0 errors, 5 skips

ruby -v: ruby 2.6.0dev (2018-07-28 trunk 64082) [x64-mingw32]```

[k0kubun (Takashi Kokubun)]

• Assignee set to k0kubun (Takashi Kokubun)

Starting with r64076, every subsequent build has failed

Does this mean, r64075 passes and r64076 fails? r64076 changes almost no behavior, so I feel it's very unlikely that r64076 is related to the failure.

2 points to notice:

• I fixed memory leak on r64075 but it had a bug of double free. The SEGV-ing bug, which is probably hard to be caught in test_jit.rb, was fixed on r64082 but it seems not related to your failure because your output includes r64082.
• Recently I added a new test to increase test coverage in r64072. I guess the mingw build started to fail on that commit and probably unload_units on mingw has never worked. I'll take a look later.

[MSP-Greg (Greg L)]

@k0kubun (Takashi Kokubun)

I apologize, I should have been clearer. ruby-loco is built three times a day. The list of builds is shown at https://ci.appveyor.com/project/MSP-Greg/ruby-loco/history or https://msp-greg.github.io/file.mingw_test-all.html.

Does this mean, r64075 passes and r64076 fails?

What I meant was that the first build with the failure was r64076, the previous build was r64070, as noted in the above links. Sorry.

I guess the mingw build started to fail on that commit and probably unload_units on mingw has never worked. I'll take a look later.

No problem. Appveyor builds run on two cores, and build times vary quite a bit. So, some issues I may want to see a few builds fail to really know the status. I also try to test locally. If it would be helpful to know whether a particular commit is failing, I can run one locally. It's also very easy to add a patch to ruby-loco.

Anyway, MinGW has had issues with MJIT before, and they've always gotten sorted out. I don't know c, but I know MJIT was/is a lot of work. Thank you. Greg

[k0kubun (Takashi Kokubun)]

I'm investigating this. It looks like a symbol (of rb_mRubyVMFrozenCore) referred from /tmp/_ruby_mjit_pXXXuYYY.so is resolved to an address which is different from the address in ruby.exe. rb_class_of((VALUE)rb_mRubyVMFrozenCore) becomes 0 by that reason, which should return a valid class. So the issue is related to linking or loading the dynamic library for JIT.

[MSP-Greg (Greg L)]

@k0kubun (Takashi Kokubun)

I just built ruby 2.6.0dev (2018-08-01 trunk 64153) [x64-mingw32], and every JIT test is showing stderr as:

Failure in MJIT header file name initialization

The previous build was r64137. If you need an intermediate build or more info, please let me know. FYI, MSYS2/MinGW just updated gcc from 7.3.0 to 8.2.0, r64153 was the first build with it.

Thanks, Greg

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned

[MSP-Greg (Greg L)]

@k0kubun (Takashi Kokubun)

Re above message, after r64161, JIT tests are working again. I tried test_unload_units, and that is still failing. Also, the build was using gcc 8.2.0.

Thanks for the work, and I'll run r64162 soon, Greg

[k0kubun (Takashi Kokubun)]

Yeah, the status is intentional. I checked many things for linking rb_mRubyVMFrozenCore properly but still no luck.

We may be able to avoid referring to rb_mRubyVMFrozenCore, but we have no confidence on performing link and load other things correctly for MinGW...

[k0kubun (Takashi Kokubun)]

• Subject changed from MinGW Failure - r64072 - test_jit.rb: test unload_units to MinGW Failure - r64072 - test_jit.rb: test_compile_insn_putspecialobject_putiseq

I changed the failing test from test_unload_units to test_compile_insn_putspecialobject_putiseq in r64163 because unload_units is actually working fine and the bad one is putiseq.

[k0kubun (Takashi Kokubun)]

• Status changed from Assigned to Closed

r64964 solved all issues on MinGW MJIT. Closing.