Bug #14948
closedMinGW Failure - r64072 - test_jit.rb: test_compile_insn_putspecialobject_putiseq
Description
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]```
Updated by k0kubun (Takashi Kokubun) about 6 years ago
- 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.
Updated by MSP-Greg (Greg L) about 6 years ago
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
Updated by k0kubun (Takashi Kokubun) about 6 years ago
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.
Updated by MSP-Greg (Greg L) about 6 years ago
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
Updated by hsbt (Hiroshi SHIBATA) about 6 years ago
- Status changed from Open to Assigned
Updated by MSP-Greg (Greg L) about 6 years ago
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
Updated by k0kubun (Takashi Kokubun) about 6 years ago
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...
Updated by k0kubun (Takashi Kokubun) about 6 years ago
- 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.
Updated by k0kubun (Takashi Kokubun) almost 6 years ago
- Status changed from Assigned to Closed
r64964 solved all issues on MinGW MJIT. Closing.