+++ This bug was initially created as a clone of Bug #845011 +++

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:

--- Additional comment from updates on 2012-08-01 17:58:04 CEST ---

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

--- Additional comment from updates on 2012-08-02 13:22:52 CEST ---

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).

--- Additional comment from updates on 2012-08-11 00:28:13 CEST ---

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.

--- Additional comment from little.owl on 2012-08-12 01:04:25 CEST ---

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.

--- Additional comment from vondruch on 2012-08-13 07:17:15 CEST ---

(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

--- Additional comment from mike on 2012-08-14 03:17:41 CEST ---

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?

--- Additional comment from mtasaka on 2012-08-14 03:52:53 CEST ---

(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?)

--- Additional comment from mtasaka on 2012-08-14 03:53:43 CEST ---

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

--- Additional comment from mtasaka on 2012-08-14 03:56:21 CEST ---

> #8  __longjmp_chk (env=0x0, val=val@entry=6) at ../setjmp/longjmp.c:33

So maybe anyway ruby is doing something wrong??

--- Additional comment from mtasaka on 2012-08-14 04:03:27 CEST ---

So the root of this issue seems to be that ruby is calling longjmp with invalid argument 0.

--- Additional comment from mtasaka on 2012-08-14 04:03:59 CEST ---

(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

--- Additional comment from mtasaka on 2012-08-14 08:16:15 CEST ---

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)

--- Additional comment from mtasaka on 2012-08-14 08:18:56 CEST ---

So it seems that whether rubygems is installed or not vim must be fixed.

--- Additional comment from mtasaka on 2012-08-14 08:58:31 CEST ---

The related discussion:
http://article.gmane.org/gmane.editors.vim.devel/29301

--- Additional comment from mtasaka on 2012-08-14 10:40:17 CEST ---

Also see my comment bug 847482 comment 11

--- Additional comment from vondruch on 2012-08-14 12:29:03 CEST ---

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?

--- Additional comment from updates on 2012-08-14 15:13:25 CEST ---

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