Avoid `rb_load_protect` as a workaround not to crash #2147

ujihisa · 2017-09-23T15:41:09Z

Short summary: fix a segv for if_ruby.

Problem

Vim with +ruby causes segmentation fault when Ruby throws an exception inside :rubyfile command.

echo 'raise' > /tmp/raise.rb
vim -u NONE -N -c 'rubyfile /tmp/raise.rb'

I tested with Vim 7.3.939, 8.0.0000, latest 8.0.1139, with Ruby 2.3.1, 2.4.2, and latest 2.5.0dev. I don't know when exactly happened, but it must have been happening since pretty old version.

This is likely a Ruby bug, since rb_load_protect is supposed to be used to avoid segmentation fault, according to a third-party doc.a Ruby committer also suggested it may be a Ruby bug.

Solution

I took a workaround. According to existing :h rubyfile, the updated behaviour should be straightforward.

For long-term solution, Ruby should fix the function itself. Vim supports older versions of Ruby, so the above solution should be better.

Acknowledgement

Thanks @pocke to report this issue at vim-jp/issues#1098, and @mattn to help me a lot contributing to vim core for the first time! Also thanks indirectly to @nurse confirming it's likely a Ruby bug.

codecov-io · 2017-09-23T15:59:04Z

Codecov Report

Merging #2147 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2147      +/-   ##
==========================================
+ Coverage   73.96%   73.98%   +0.01%     
==========================================
  Files          90       90              
  Lines      131906   131908       +2     
  Branches    28964    28965       +1     
==========================================
+ Hits        97570    97592      +22     
+ Misses      34313    34297      -16     
+ Partials       23       19       -4

Impacted Files	Coverage Δ
src/if_ruby.c	`60.78% <100%> (+4.32%)`	⬆️
src/term.c	`51.23% <0%> (-0.22%)`	⬇️
src/message.c	`68.26% <0%> (-0.2%)`	⬇️
src/window.c	`81.65% <0%> (-0.1%)`	⬇️
src/gui.c	`46.34% <0%> (ø)`	⬆️
src/evalfunc.c	`82.85% <0%> (+0.03%)`	⬆️
src/channel.c	`82.63% <0%> (+0.08%)`	⬆️
src/gui_gtk_x11.c	`47.86% <0%> (+0.1%)`	⬆️
src/if_py_both.h	`76.23% <0%> (+0.14%)`	⬆️
src/if_xcmdsrv.c	`84.89% <0%> (+1.07%)`	⬆️
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0b05e49...a96452a. Read the comment docs.

nurse · 2017-09-27T21:49:19Z

This issue is fixed by ruby/ruby@d352d0a, and will be backported on next 2.3/2.4 stable release.

brammool · 2017-10-19T19:27:51Z

This works for static linking, but not when using ruby/dynamic

brammool · 2017-10-19T19:42:11Z

Stack trace when Vim crashes:
(gdb) where
#0 0x00007fffed97ab9b in () at /usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3
#1 0x00007fffed97ad10 in () at /usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3
#2 0x00007fffed972f2e in () at /usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3
#3 0x00007fffed973a58 in rb_load ()
at /usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3
#4 0x00007fffed97006b in rb_protect ()
at /usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3
#5 0x00005555557f80e3 in ex_rubyfile (eap=0x7fffffffbb70) at if_ruby.c:837

that is at this command:
rb_protect((VALUE (*)(VALUE))rb_load, rb_str_new2((char *)eap->arg),
&state);

k-takata · 2017-10-30T03:33:28Z

@brammool It looks that this is merged as a part of 8.0.1236.
Is this intended? If so, we can close this PR, and I think @ujihisa's name should be credited in the patch (when you update version8.txt).

nuko8 · 2017-10-30T06:44:24Z

I'd like to definitely decline the proposal of co-authorship.

If things should be settled like that, that is, through my accepting co-authorship, then that must sound as if I stole this PR, smuggled it into master via my own PR #2178, and approved such an terrible allegation against me afterwards.

As clearly shown in the commit log of #2178, I'm not guilty. Accordingly, there's no reason at all for me to accept such a ridiculous proposal. How can I be in favor of the patch of this PR at the cost of my honor? No way.

Furthermore, the proposed patch of this PR has already been labeled "incomplete" via a message to vim_dev. I'm wondering how come it's possible for someone to think the inclusion intended. I would say that must have took place accidentally. Naturally, a decent solution to that is crystal clear to everyone: Remove that Ruby part from 8.0.1236 and make the latter clean.

k-takata · 2017-10-30T07:11:27Z

I agree that this PR is totally unrelated to #2178, so adding his name to 8.0.1236 is confusing and/or misleading.
Creating a separate patch for this would be better if Bram really intended to include this.

I'm not guilty.

Of course I know. So I'm asking to Bram, not to you.

nuko8 · 2017-10-30T08:38:21Z

Comparing the current if_ruby.c with the patch of this PR, I saw the Ruby part of 8.0.1236 including more changes than those proposed here. Rather, they appear to be identical with those found in this message, which I quoted previously.

Seems like there's been another patch different from this PR's. I'm wondering how the former is related to the latter in terms of authorship, though I actually don't care about that.

mattn · 2017-10-30T14:34:40Z

We understand and strongly believe this is simply mistake of commit. And we are thinking contributor's name should be credited in the the patch files. For the contributors, what their name is credited in the patch file is proud things for themselves. :)

chrisbra · 2017-10-30T18:47:01Z

I am sorry, I did not follow the whole conversation. Is there anything to be done here?

k-takata · 2017-10-30T22:43:23Z

It's all up to Bram. Possible choices might be:

If Bram didn't intend to include the change to if_ruby.c:
Create a new commit to revert the change and,
- Create a new patch file (on the ftp server), or
- Modify the patch 8.0.1236 and remove the change from it.
If the change is intended, make the change clearer and give a proper credit:
- For the patch files:
  - Modify the patch 8.0.1236 and move the change into a new patch, or
  - Keep 8.0.1236 as it is, create a new patch to revert the change, and create another patch to include the change again.
- For the git repository:
  - Keep as it is, or
  - Create a new commit to revert the change, and create another commit to include the change again.

brammool · 2017-10-31T22:12:00Z

Ken Takata wrote:

@brammool It looks that this is merged as a part of [8.0.1236](d057301). Is this intended? If so, we can close this PR, and I think @ujihisa's name should be credited in the patch (when you update version8.txt).

That was by accident. That change was pending, since the test still fails. So not the test part is still pending: *** ../vim-8.0.1241/src/testdir/test_ruby.vim 2017-01-29 23:11:21.172512839 +0100 --- src/testdir/test_ruby.vim 2017-10-21 19:17:06.040153912 +0200 *************** *** 49,51 **** --- 49,59 ---- bwipe! bwipe! endfunc + + func Test_rubyfile() + " Check :rubyfile does not SEGV with Ruby level exception but just fails + let tempfile = tempname() . '.rb' + call writefile(['raise "vim!"'], tempfile) + call assert_fails('rubyfile ' . tempfile) + call delete(tempfile) + endfunc

…

-- [Another hideous roar.] BEDEVERE: That's it! ARTHUR: What? BEDEVERE: It's The Legendary Black Beast of Aaaaarrrrrrggghhh! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

brammool · 2017-10-31T22:12:00Z

Ken Takata wrote:

It's all up to Bram. Possible choices might be: * If Bram didn't intend to include the change to if_ruby.c: Create a new commit to revert the change and, * Create a new patch file (on the ftp server), or * Modify the patch 8.0.1236 and remove the change from it. * If the change is intended, make the change clearer and give a proper credit: * For the patch files: * Modify the patch 8.0.1236 and move the change into a new patch, or * Keep 8.0.1236 as it is, create a new patch to revert the change, and create another patch to include the change again. * For the git repository: * Keep as it is, or * Create a new commit to revert the change, and create another commit to include the change again.

The problem with git (or any version control system) is that it doesn't allow for rewriting history. If I was sending out patches only, I could edit that patch and correct the mistake. But now that's impossible. I'll add a note in the patch message: Solution: Make feature names more consistent, add "osxdarwin". Rename feature flags, cleanup Mac code. (Kazunobu Kuriyama, closes #2178) Also includes a fix for when Ruby throws an exception inside :rubyfile.(ujihisa)

…

-- Dreams are free, but there's a small charge for alterations. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

ujihisa · 2017-11-28T13:10:10Z

Thanks for Bram to merge, and nurse, k-takata, and mattn for catching that up. As Bram mentioned that I confirmed that it still crashes with --enable-rubyinterp=dynamic. I didn't find any solutions for that yet.

# sorry for extremely late reply. I was focusing on VimConf last month and I forgot replying at all..

ujihisa · 2018-01-31T23:31:23Z

Thanks a lot!

Problem: Segmentation fault when Ruby throws an exception inside :rubyfile command. Solution: Use rb_protect() instead of rb_load_protect(). (ujihisa, closes vim#2147, greywolf, closes vim#2512, vim#2511)

Problem: Segmentation fault when Ruby throws an exception inside :rubyfile command. Solution: Use rb_protect() instead of rb_load_protect(). (ujihisa, closes vim/vim#2147, greywolf, closes vim/vim#2512, vim/vim#2511) vim/vim@37badc8

Avoid rb_load_protect as a workaround not to crash

a96452a

ujihisa force-pushed the master branch from 96674bd to a96452a Compare September 25, 2017 14:43

k-takata added the if_ruby label Oct 16, 2017

brammool closed this in 37badc8 Jan 31, 2018

janlazo mentioned this pull request Nov 17, 2018

[WIP] vim-patch:8.0.1448 neovim/neovim#9245

Closed

Uh oh!

Uh oh!

Avoid rb_load_protect as a workaround not to crash #2147

Avoid rb_load_protect as a workaround not to crash #2147

Uh oh!

Conversation

ujihisa commented Sep 23, 2017

Problem

Solution

Acknowledgement

Uh oh!

codecov-io commented Sep 23, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

nurse commented Sep 27, 2017

Uh oh!

brammool commented Oct 19, 2017

Uh oh!

brammool commented Oct 19, 2017

Uh oh!

k-takata commented Oct 30, 2017

Uh oh!

nuko8 commented Oct 30, 2017

Uh oh!

k-takata commented Oct 30, 2017

Uh oh!

nuko8 commented Oct 30, 2017

Uh oh!

mattn commented Oct 30, 2017

Uh oh!

chrisbra commented Oct 30, 2017

Uh oh!

k-takata commented Oct 30, 2017

Uh oh!

brammool commented Oct 31, 2017 via email

Uh oh!

brammool commented Oct 31, 2017 via email

Uh oh!

ujihisa commented Nov 28, 2017

Uh oh!

ujihisa commented Jan 31, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Avoid `rb_load_protect` as a workaround not to crash #2147

Avoid `rb_load_protect` as a workaround not to crash #2147

codecov-io commented Sep 23, 2017 •

edited

Loading