Bug 845011

Summary: ruby-libs must require rubygems
Product: [Fedora] Fedora Reporter: Vít Ondruch <vondruch>
Component: rubyAssignee: Vít Ondruch <vondruch>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: bkabrda, jeremy, mike, mmorsi, mtasaka, next.little.owl, tagoh, vanmeeuwen+fedora, vondruch
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 848058 (view as bug list) Environment:
Last Closed: 2012-08-22 21:01:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 848058    
Attachments:
Description Flags
Proposal patch to prevent this segv none

Description Vít Ondruch 2012-08-01 13:18:53 UTC
Description of problem:
Since RubyGems are now automatically loaded, when ruby interpreter starts, the rubygems package must be required by ruby-libs, otherwise application, which uses ruby-libs (such as vim) may segfault.

Version-Release number of selected component (if applicable):
ruby-libs-1.9.3.194-14.fc18.x86_64


How reproducible:
always


Steps to Reproduce:
1. install vim without rubygems package available on system
2. $vim
3. :ruby puts RUBY_VERSION
  
Actual results:
Vim: Caught deadly signal SEGV
Vim: Finished.
Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen])



Expected results:
1.9.3 

Press ENTER or type command to continue



Additional info:

Comment 1 Fedora Update System 2012-08-01 15:58:04 UTC
ruby-1.9.3.194-14.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/ruby-1.9.3.194-14.fc17

Comment 2 Fedora Update System 2012-08-02 11:22:52 UTC
Package ruby-1.9.3.194-14.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ruby-1.9.3.194-14.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11417/ruby-1.9.3.194-14.fc17
then log in and leave karma (feedback).

Comment 3 Fedora Update System 2012-08-10 22:28:13 UTC
ruby-1.9.3.194-14.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 4 Václav Mocek 2012-08-11 23:04:25 UTC
So, after your patch, if I want to use Vim, I have to install plenty of ruby's packages, not only one as it used to be:

Updating:
 ruby-libs                  x86_64    1.9.3.194-14.fc17       updates     2.5 M
Installing for dependencies:
 ruby                       x86_64    1.9.3.194-14.fc17       updates     1.0 M
 ruby-irb                   noarch    1.9.3.194-14.fc17       updates      72 k
 rubygem-bigdecimal         x86_64    1.1.0-14.fc17           updates      69 k
 rubygem-io-console         x86_64    0.3-14.fc17             updates      42 k
 rubygem-json               x86_64    1.6.5-1.fc17            fedora      468 k
 rubygem-rdoc               noarch    3.12-3.fc17             fedora      218 k
 rubygems                   noarch    1.8.24-1.fc17           fedora      174 k

That's absolutely ridiculous.

Comment 5 Vít Ondruch 2012-08-13 05:17:15 UTC
(In reply to comment #4)
> So, after your patch, if I want to use Vim, I have to install plenty of
> ruby's packages, not only one as it used to be:
> 
> Updating:
>  ruby-libs                  x86_64    1.9.3.194-14.fc17       updates    
> 2.5 M
> Installing for dependencies:
>  ruby                       x86_64    1.9.3.194-14.fc17       updates    
> 1.0 M
>  ruby-irb                   noarch    1.9.3.194-14.fc17       updates     
> 72 k
>  rubygem-bigdecimal         x86_64    1.1.0-14.fc17           updates     
> 69 k
>  rubygem-io-console         x86_64    0.3-14.fc17             updates     
> 42 k
>  rubygem-json               x86_64    1.6.5-1.fc17            fedora     
> 468 k
>  rubygem-rdoc               noarch    3.12-3.fc17             fedora     
> 218 k
>  rubygems                   noarch    1.8.24-1.fc17           fedora     
> 174 k
> 
> That's absolutely ridiculous.

Well, this is wrong issue to complain. This was to fix possible SEGV. Ruby should by loaded dynamically and the relevant discussion is in Bug 752785

Comment 6 Michael Cronenworth 2012-08-14 01:17:41 UTC
It's pointless to have ruby-libs as a sub-package with this change.

Can ruby-libs be fixed to not segfault when rubygems is not installed?

Comment 7 Mamoru TASAKA 2012-08-14 01:52:53 UTC
(In reply to comment #5)
> Well, this is wrong issue to complain. This was to fix possible SEGV. Ruby
> should by loaded dynamically and the relevant discussion is in Bug 752785

By the way can you prove that having rubygems not installed is really the cause of this segv? (i.e. did you really examined the cause of this segv?)

Comment 8 Mamoru TASAKA 2012-08-14 01:53:43 UTC
BT on F-18

(gdb) bt
#0  0xb7783424 in __kernel_vsyscall ()
#1  0x46fb6e66 in kill () at ../sysdeps/unix/syscall-template.S:81
#2  0x08147721 in may_core_dump () at os_unix.c:3166
#3  0x081494c7 in may_core_dump () at os_unix.c:3163
#4  mch_exit (r=1) at os_unix.c:3132
#5  0x081c827e in getout (exitval=<optimized out>, exitval@entry=1) at main.c:1466
#6  0x08114dc0 in preserve_exit () at misc1.c:9042
#7  <signal handler called>
#8  __longjmp_chk (env=0x0, val=val@entry=6) at ../setjmp/longjmp.c:33
#9  0x48764c61 in vm_exec (th=0x9a19b98) at vm.c:1427
#10 0x4876c5fb in rb_iseq_eval (iseqval=161846840) at vm.c:1447
#11 0x4877d33c in prelude_eval (code=<optimized out>, name=<optimized out>, line=3) at prelude.c:67
#12 0x4877d406 in Init_prelude () at prelude.c:81
#13 0x48708c73 in ruby_init_prelude () at ruby.c:1097
#14 process_options (argc=0, argc@entry=2, argv=0xbfb14de0, argv@entry=0xbfb14dd8, opt=opt@entry=0xbfb14d48)
    at ruby.c:1360
#15 0x487094f1 in ruby_process_options (argc=argc@entry=2, argv=argv@entry=0xbfb14dd8) at ruby.c:1806
#16 0x081c02a9 in ensure_ruby_initialized () at if_ruby.c:669
#17 0x081c1905 in ex_ruby (eap=0xbfb14f58) at if_ruby.c:515
#18 0x080c2e92 in do_one_cmd (cookie=0x0, fgetline=0x80d2c10 <getexline>, cstack=0xbfb14fc8, sourcing=0, cmdlinep=
    0xbfb14eec) at ex_docmd.c:2668
#19 do_cmdline (cmdline=cmdline@entry=0x0, fgetline=0x80d2c10 <getexline>, cookie=cookie@entry=0x0, flags=0)
    at ex_docmd.c:1122
#20 0x081274de in nv_colon (cap=0xbfb1534c) at normal.c:5412
#21 0x0812d5a2 in normal_cmd (oap=oap@entry=0xbfb153d0, toplevel=toplevel@entry=1) at normal.c:1193
#22 0x081c8a6c in main_loop (cmdwin=cmdwin@entry=0, noexmode=noexmode@entry=0) at main.c:1294
#23 0x0806962d in main (argc=1, argv=0xbfb155f4) at main.c:998

Comment 9 Mamoru TASAKA 2012-08-14 01:56:21 UTC
> #8  __longjmp_chk (env=0x0, val=val@entry=6) at ../setjmp/longjmp.c:33

So maybe anyway ruby is doing something wrong??

Comment 10 Mamoru TASAKA 2012-08-14 02:03:27 UTC
So the root of this issue seems to be that ruby is calling longjmp with invalid argument 0.

Comment 11 Mamoru TASAKA 2012-08-14 02:03:59 UTC
(In reply to comment #10)
> So the root of this issue seems to be that ruby is calling longjmp with
> invalid argument 0.

Oops... argument 1

Comment 12 Mamoru TASAKA 2012-08-14 06:16:15 UTC
Created attachment 604146 [details]
Proposal patch to prevent this segv

It seems that vim's direct call of ruby_process_options should be prevented and should use ruby_options instead to save root jmpbuf.

For me the attached patch prevents this segv (tested on F18 i686)

Comment 13 Mamoru TASAKA 2012-08-14 06:18:56 UTC
So it seems that whether rubygems is installed or not vim must be fixed.

Comment 14 Mamoru TASAKA 2012-08-14 06:58:31 UTC
The related discussion:
http://article.gmane.org/gmane.editors.vim.devel/29301

Comment 15 Mamoru TASAKA 2012-08-14 08:40:17 UTC
Also see my comment bug 847482 comment 11

Comment 16 Vít Ondruch 2012-08-14 10:29:03 UTC
Ok. I was wrong and I'm going to revert this change, i.e. remove the dependency, since there are two cases:


= 1 ======

This was original justification for this change:

$ cat emb.c
#include "ruby.h"

int main(int argc, char *argv[])
{
	ruby_sysinit(&argc, &argv);
	RUBY_INIT_STACK;
	ruby_init();
	return ruby_run_node(ruby_options(argc, argv));
}
$ gcc -I/usr/include/x86_64-linux/ -lruby emb.c
$ cat test.rb
puts "Hello world"
$ ./a.out test.rb
<internal:gem_prelude>:1:in `require': cannot load such file -- rubygems.rb (LoadError)
	from <internal:gem_prelude>:1:in `<compiled>'

= 2 ======

However there is also another case:

$ cat emb.c
#include "ruby.h"

int main(int argc, char *argv[])
{
	ruby_init();
	rb_eval_string("puts 'hello world'");
	ruby_finalize();
	return 0;
}
$ gcc -I/usr/include/x86_64-linux/ -lruby emb.c
$ ./a.out 
hello world

Since this example works, without RubyGems installed, I am going to revert the change.

Mamoru, could you please open separate ticket for the VIM issue? Or should I?

Comment 17 Fedora Update System 2012-08-14 13:13:25 UTC
ruby-1.9.3.194-15.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/ruby-1.9.3.194-15.fc17

Comment 18 Vít Ondruch 2012-08-14 13:33:15 UTC
I have opened new bug for VIM (Bug 848058).

Comment 19 Mamoru TASAKA 2012-08-14 14:39:53 UTC
Thank you for filing a bug against vim.

Comment 20 Fedora Update System 2012-08-14 21:59:46 UTC
Package ruby-1.9.3.194-15.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ruby-1.9.3.194-15.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11893/ruby-1.9.3.194-15.fc17
then log in and leave karma (feedback).

Comment 21 Fedora Update System 2012-08-22 21:01:07 UTC
ruby-1.9.3.194-15.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.