summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Import fiddle-1.0.4 (#3860)Kenta Murata2020-12-1123-252/+1816
| | | | | | | | I don't use tool/sync_default_gem.rb because the last sync was incomplete. Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org> Co-authored-by: Alan Wu <XrXr@users.noreply.github.com> Co-authored-by: sinisterchipmunk <sinisterchipmunk@gmail.com> Co-authored-by: Sutou Kouhei <kou@clear-code.com>
* Unfortunately getinstancevariable was still not leafTakashi Kokubun2020-12-101-0/+2
| | | | https://github.com/ruby/ruby/runs/1533401436
* Reintroduce the fix againTakashi Kokubun2020-12-101-1/+1
|
* Fix the path properlyTakashi Kokubun2020-12-101-1/+1
| | | | :disappointed:
* Try fixing the -I positionTakashi Kokubun2020-12-101-1/+1
| | | | | https://github.com/ruby/ruby/runs/1532260149 :thinking:
* Make ruby -We the same as ruby -W -eJeremy Evans2020-12-102-2/+4
| | | | | | This changes the behavior, which I'm not sure is acceptable. However, it's odd to allow an option to be combined, but change the behavior of the option when combined.
* Make getinstancevariable a leaf instructionJeremy Evans2020-12-101-2/+0
| | | | It can no longer issue a warning.
* Remove the uninitialized instance variable verbose mode warningJeremy Evans2020-12-107-24/+12
| | | | | | | | | This speeds up all instance variable access, even when not in verbose mode. Uninitialized instance variable warnings were rarely helpful, and resulted in slower code if you wanted to avoid warnings when run in verbose mode. Implements [Feature #17055]
* Actions mingw - add tool/test for WEBrick in spec tests (#3882)MSP-Greg2020-12-101-1/+1
| | | Some spec tests require WEBrick, and the spec tests are run from install with the MinGW CI.
* Show C backtrace appropriately at core dump for GCC 8 or laterYusuke Endoh2020-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When ruby is compiled by GCC 8 or later, some frames of C level backtrace information lacks. ``` $ ./miniruby -e '1.times { Process.kill(:SEGV, $$) }' ... -- C level backtrace information ------------------------------------------- /home/mame/work/ruby-gcc-9/miniruby(rb_vm_bugreport+0x611) [0x558a5fdcbc21] ../ruby/vm_dump.c:758 [0x558a5fbc789a] /home/mame/work/ruby-gcc-9/miniruby(sigsegv+0x4d) [0x558a5fd1eaed] ../ruby/signal.c:959 /lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f687e6713c0] /lib/x86_64-linux-gnu/libc.so.6(kill+0xb) [0x7f687e31355b] ../sysdeps/unix/syscall-template.S:78 /home/mame/work/ruby-gcc-9/miniruby(rb_f_kill+0x350) [0x558a5fd1fe60] ../ruby/signal.c:480 [0x558a5fda50d3] [0x558a5fdb085c] [0x558a5fdb0fe7] [0x558a5fdbae1a] [0x558a5fdaf484] /home/mame/work/ruby-gcc-9/miniruby(rb_yield_1+0x29f) [0x558a5fdb2fbf] ../ruby/vm.c:1265 /home/mame/work/ruby-gcc-9/miniruby(int_dotimes+0x5c) [0x558a5fc72f2c] ../ruby/numeric.c:5198 [0x558a5fda50d3] [0x558a5fdb085c] [0x558a5fdb0fe7] [0x558a5fdbaf21] [0x558a5fdaf484] /home/mame/work/ruby-gcc-9/miniruby(rb_ec_exec_node+0xed) [0x558a5fbcc4fd] ../ruby/eval.c:317 /home/mame/work/ruby-gcc-9/miniruby(ruby_run_node+0x4f) [0x558a5fbd110f] ../ruby/eval.c:375 /home/mame/work/ruby-gcc-9/miniruby(main+0x73) [0x558a5fb2c083] ../ruby/main.c:50 ``` By this one-line change, it shows all locations. ``` $ ./miniruby -e '1.times { Process.kill(:SEGV, $$) }' ... -- C level backtrace information ------------------------------------------- /home/mame/work/ruby-gcc-9/miniruby(rb_print_backtrace+0x11) [0x558247adec21] ../ruby/vm_dump.c:758 /home/mame/work/ruby-gcc-9/miniruby(rb_vm_bugreport) ../ruby/vm_dump.c:956 /home/mame/work/ruby-gcc-9/miniruby(rb_bug_for_fatal_signal+0x15a) [0x5582478da89a] ../ruby/error.c:773 /home/mame/work/ruby-gcc-9/miniruby(sigsegv+0x4d) [0x558247a31aed] ../ruby/signal.c:959 /lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f82202f73c0] /lib/x86_64-linux-gnu/libc.so.6(kill+0xb) [0x7f821ff9955b] ../sysdeps/unix/syscall-template.S:78 /home/mame/work/ruby-gcc-9/miniruby(rb_f_kill+0x350) [0x558247a32e60] ../ruby/signal.c:480 /home/mame/work/ruby-gcc-9/miniruby(vm_call_cfunc_with_frame+0x123) [0x558247ab80d3] ../ruby/vm_insnhelper.c:2821 /home/mame/work/ruby-gcc-9/miniruby(vm_call_method_each_type+0x7c) [0x558247ac385c] ../ruby/vm_insnhelper.c:3324 /home/mame/work/ruby-gcc-9/miniruby(vm_call_method+0xc7) [0x558247ac3fe7] ../ruby/vm_insnhelper.c:3428 /home/mame/work/ruby-gcc-9/miniruby(vm_sendish+0x14) [0x558247acde1a] ../ruby/vm_insnhelper.c:4412 /home/mame/work/ruby-gcc-9/miniruby(vm_exec_core) ../ruby/insns.def:789 /home/mame/work/ruby-gcc-9/miniruby(rb_vm_exec+0x1a4) [0x558247ac2484] ../ruby/vm.c:2165 /home/mame/work/ruby-gcc-9/miniruby(rb_yield_1+0x29f) [0x558247ac5fbf] ../ruby/vm.c:1265 /home/mame/work/ruby-gcc-9/miniruby(int_dotimes+0x5c) [0x558247985f2c] ../ruby/numeric.c:5198 /home/mame/work/ruby-gcc-9/miniruby(vm_call_cfunc_with_frame+0x123) [0x558247ab80d3] ../ruby/vm_insnhelper.c:2821 /home/mame/work/ruby-gcc-9/miniruby(vm_call_method_each_type+0x7c) [0x558247ac385c] ../ruby/vm_insnhelper.c:3324 /home/mame/work/ruby-gcc-9/miniruby(vm_call_method+0xc7) [0x558247ac3fe7] ../ruby/vm_insnhelper.c:3428 /home/mame/work/ruby-gcc-9/miniruby(vm_sendish+0x14) [0x558247acdf21] ../ruby/vm_insnhelper.c:4412 /home/mame/work/ruby-gcc-9/miniruby(vm_exec_core) ../ruby/insns.def:770 /home/mame/work/ruby-gcc-9/miniruby(rb_vm_exec+0x1a4) [0x558247ac2484] ../ruby/vm.c:2165 /home/mame/work/ruby-gcc-9/miniruby(rb_ec_exec_node+0xed) [0x5582478df4fd] ../ruby/eval.c:317 /home/mame/work/ruby-gcc-9/miniruby(ruby_run_node+0x4f) [0x5582478e410f] ../ruby/eval.c:375 /home/mame/work/ruby-gcc-9/miniruby(main+0x73) [0x55824783f083] ../ruby/main.c:50 ``` Details: In short, it is an uninitialized variable bug. Until GCC 7, all function locations are represented by a pair of DW_AT_low_pc and DW_AT_high_pc in DWARF information. But since GCC 8, some functions are split to multiple chunks, which are represented by DW_AT_ranges. DW_AT_ranges are represented as offsets from a base address. According to DWARF specification, it is the base address of the compilation unit, but GCC seems to use zero as default. The function "di_read_cu" in addr2line.c had a comment about the fact. However, the base address wasn't initialized as zero.
* * 2020-12-11 [ci skip]git2020-12-111-1/+1
|
* Suppress a "clobbered" warning by gcc on macOSNobuyoshi Nakada2020-12-111-4/+4
|
* Fix a link [ci skip]Kazuhiro NISHIYAMA2020-12-101-0/+1
|
* include/ruby/memory_view.h: fix the return type of ↵Kenta Murata2020-12-101-1/+1
| | | | rb_memory_view_prepare_item_desc
* include/ruby/memory_view.h: fix typoKenta Murata2020-12-101-1/+1
|
* Use `abort(message)` instead of `puts` and `exit`Kazuhiro NISHIYAMA2020-12-104-8/+4
|
* Add connect_timeout to TCPSocketMasaki Matsushita2020-12-1010-20/+48
| | | | | | Add connect_timeout to TCPSocket.new in the same way as Socket.tcp. Closes [Feature #17187]
* Fixed the test failures called WEBrick.new directlyHiroshi SHIBATA2020-12-101-5/+5
|
* ObjectSpace._id2ref should not support unshareableKoichi Sasada2020-12-102-1/+22
| | | | | | ObjectSpace._id2ref(id) can return any objects even if they are unshareable, so this patch raises RangeError if it runs on multi-ractor mode and the found object is unshareable.
* remove bz2NARUSE, Yui2020-12-101-7/+1
|
* Unpoison freelist to chainNobuyoshi Nakada2020-12-101-0/+1
|
* Right size literal regular expression buffers on compileLourens Naudé2020-12-101-0/+20
|
* Added help message for gem i webrick in rdocHiroshi SHIBATA2020-12-102-2/+13
|
* Added help message for gem i webrick in gem server commandHiroshi SHIBATA2020-12-101-1/+7
|
* Completely removed webrickHiroshi SHIBATA2020-12-103-4/+0
|
* Added help message for gem i webrick in un.rbHiroshi SHIBATA2020-12-101-1/+6
|
* webrick was removed from ruby repoHiroshi SHIBATA2020-12-109-196/+0
|
* Promote webrick to bundled gemsHiroshi SHIBATA2020-12-105-7/+4
|
* Added tool/lib into test-spec loadpathHiroshi SHIBATA2020-12-101-1/+1
|
* Move webrick library into internal test toolchainHiroshi SHIBATA2020-12-1061-0/+0
|
* .github: reduce (#3876)卜部昌平2020-12-104-58/+61
| | | | Comment out some 50-ish tests. fix https://bugs.ruby-lang.org/issues/17376
* Revert "Revert some recent JIT changes"Takashi Kokubun2020-12-101-1/+14
| | | | | | This reverts commit b7dc04e51823f9fe8b5355c30a304ecdb11fe5ed. This should be fine, rather necessary, too.
* Revert "Revert "Have list_node at the top of rb_mjit_unit""Takashi Kokubun2020-12-101-1/+1
| | | | | | This reverts commit 73b07c437e24711c23dd2dd01d3ffc5f1012e046. This was, of course, innocent.
* Use list_for_each_safe when list_del is used insideTakashi Kokubun2020-12-101-3/+3
| | | | list_for_each seems to cause all the SEGVs we've seen.
* cache free pages per ractorKoichi Sasada2020-12-102-12/+58
| | | | | | | Per ractor method cache (GH-#3842) only cached 1 page and this patch caches several pages to keep at least 512 free slots if available. If you increase the number of cached free slots, all cached slots will be collected when the GC is invoked.
* set min/maximum free slots relative to ractor cntKoichi Sasada2020-12-101-3/+9
| | | | | | A program with multiple ractors can consume more objects per unit time, so this patch set minimum/maximum free_slots to relative to ractors count (upto 8).
* lazy sweep tries to collect 2048 slotsKoichi Sasada2020-12-101-3/+8
| | | | | | | Lazy sweep tries to collect free (unused) slots incrementally, and it only collect a few pages. This patch makes lazy sweep collects more objects (at least 2048 objects) and GC overhead of multi-ractor execution will be reduced.
* test/ruby/test_arithmetic_sequence.rb: restore test_last_bug17218Kenta Murata2020-12-101-1/+6
| | | | And rename the existing `test_last_bug17218` to `test_to_a_bug17218`.
* memory_view.c: Add rb_memory_view_get_item and ↵Kenta Murata2020-12-104-20/+69
| | | | rb_memory_view_prepare_item_desc (#3871)
* * 2020-12-10 [ci skip]git2020-12-101-1/+1
|
* test/ruby/test_arithmetic_sequence.rb: remove a duplicated testYusuke Endoh2020-12-101-5/+0
| | | | There is another "test_last_bug17218"
* Fix ArithmeticSequence#last and ArithmeticSequence#each for non-integer ↵Kenta Murata2020-12-097-40/+156
| | | | | | sequences (#3870) [Bug #17218] [ruby-core:100312]
* [ruby/matrix] Disable Ractor testMarc-Andre Lafortune2020-12-091-0/+2
|
* [ruby/matrix] v0.3.1Marc-Andre Lafortune2020-12-091-1/+1
|
* [ruby/matrix] Make frozen matrices Ractor shareableMarc-Andre Lafortune2020-12-092-1/+14
|
* [ruby/prime] Fix gemspecMarc-Andre Lafortune2020-12-091-3/+3
|
* need the lock for debug checking.Koichi Sasada2020-12-091-12/+17
| | | | | Checking code (RGENGC_CHECK_MODE > 0) need a VM lock because it refers objspace.
* Update maintainers list [doc] [ci skip]Marc-Andre Lafortune2020-12-091-8/+4
|
* [ruby/prime] v0.1.2Marc-Andre Lafortune2020-12-091-1/+1
|
* [ruby/prime] Optimize `Integer#prime?`Marc-Andre Lafortune2020-12-092-0/+85
| | | | | | | | | | | | | | | | Miller Rabin algorithm can be used to test primality for integers smaller than a max value "MaxMR" (~3e24) It can be much faster than previous implementation: ~100x faster for numbers with 13 digits, at least 5 orders of magnitude for even larger numbers (previous implementation is so slow that it requires more patience than I have for more precise estimate). Miller Rabin test becomes faster than previous implementation at somewhere in the range 1e5-1e6. It seems that the range 62000..66000 is where Miller Rabin starts being always faster, so I picked 0xffff arbitrarily; before that, or above "MaxMR", the previous implementation remains. I compared the `faster_prime` gem too. It is slower than previous implementation up to ~1e4. After that it becomes faster and faster compared to previous implementation, but is still slower than Miller Rabin starting at ~1e5 and up to MaxMR. Thus, after this commit, builtin `Integer#prime?` will be similar or faster than `faster_prime` up to "MaxMR". Adapted from patch of Stephen Blackstone [Feature #16468] Benchmark results and code: https://gist.github.com/marcandre/b263bdae488e76dabdda84daf73733b9 Co-authored-by: Stephen Blackstone <sblackstone@gmail.com>
View Lorry Controller Status