Bug 705425

Created attachment 439666 [details]
modified Kerberos.ycp

Created attachment 439668 [details]
ruby module

Created attachment 439669 [details]
backtrace

We investigate that stack is broken. We expect that ruby bindings somehow break it as it works without ruby bindings.

Please provide a complete description on how to reproduce the bug

1. Download yast-- project from https://github.com/yast/yast--

2. Follow the README to install the project.

3. YaST needs library files under YaST directory and with YaST-like name: link kerberos_client.rb (https://github.com/yast/yast--/blob/master/kerberos-client/kerberos_client.rb) to /usr/share/YaST2/modules/KerberosClient.rb

(btw, there are bugs 705422, 705417 for this)

4. Run this ycp code:

{
    import "KerberosClient";
    y2internal ("read: %1", KerberosClient::read ($[]));
}

I simplify code much more. I extract call from ruby bindings how it does it and reproduce crash. It is at https://github.com/yast/yast-- located in directory testC

well, C code actually works, my fault.

(In reply to comment #6)
> 1. Download yast-- project from https://github.com/yast/yast--
> 
> 2. Follow the README to install the project.

Please fix this. Testing YaST-- and reproducing bugs must not require root privileges.

> 
> 3. YaST needs library files under YaST directory and with YaST-like name: link
> kerberos_client.rb
> (https://github.com/yast/yast--/blob/master/kerberos-client/kerberos_client.rb)
> to /usr/share/YaST2/modules/KerberosClient.rb

See above

> 
> (btw, there are bugs 705422, 705417 for this)
> 
> 4. Run this ycp code:

How does one run this code ?

> 
> {
>     import "KerberosClient";
>     y2internal ("read: %1", KerberosClient::read ($[]));
> }

(In reply to comment #9)
> (In reply to comment #6)
> > 1. Download yast-- project from https://github.com/yast/yast--
> > 
> > 2. Follow the README to install the project.
> 
> Please fix this. Testing YaST-- and reproducing bugs must not require root
> privileges.

You need root privileges for 'sudo rake install', which is usual for any project.
 
> > 3. YaST needs library files under YaST directory and with YaST-like name: link
> > kerberos_client.rb
> > (https://github.com/yast/yast--/blob/master/kerberos-client/kerberos_client.rb)
> > to /usr/share/YaST2/modules/KerberosClient.rb
> 
> See above

This is workaround for another ruby-bindings bugs, as already mentioned:

> > (btw, there are bugs 705422, 705417 for this)


> > 4. Run this ycp code:
> 
> How does one run this code ?

/sbin/yast2 ./this_example.ycp

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #6)
> > > 1. Download yast-- project from https://github.com/yast/yast--
> > > 
> > > 2. Follow the README to install the project.
> > 
> > Please fix this. Testing YaST-- and reproducing bugs must not require root
> > privileges.
> 
> You need root privileges for 'sudo rake install', which is usual for any
> project.

But completely wrong for development and testing IMHO.

(In reply to comment #11)

> > > Please fix this. Testing YaST-- and reproducing bugs must not require root
> > > privileges.
> > 
> > You need root privileges for 'sudo rake install', which is usual for any
> > project.
> 
> But completely wrong for development and testing IMHO.

AFAIK it's for the D-BUS stuff which needs to be in correct directory.

Anyway, it is sure that the project needs improvements on all parts, including configuration. That may be point of bugs against YaST++ project, but not of this one, which shows problems in ruby-bindings.

I discussed this bug with Jiri during the workshop. The reason it happens is because the bindings use Method#arity when it should probably use Method#parameters (as detailed in the ruby-doc).

Method#arity returns negative numbers when there are optional parameters and this causes the crash. So YCP should always call ruby passing _all_ parameters of a ruby method with optional arguments.

Sadly, the advertised Merthod#parameters (http://www.ruby-doc.org/core/classes/Method.html#M001075) does not seem to be available in the interpreter.

(In reply to comment #13)
> I discussed this bug with Jiri during the workshop. The reason it happens is
> because the bindings use Method#arity when it should probably use
> Method#parameters (as detailed in the ruby-doc).

No, you are referring to a different one: bug 705420

Hmm, I don't get a crash but

2011-07-25 10:30:14 <3> heron(19808) [Parser] yast--/bnc705425.ycp:3 Excessive parameter in call to KerberosClient::read(...)
2011-07-25 10:30:14 <3> heron(19808) [Parser] yast--/bnc705425.ycp:3 Bad parameter '<map> $[]'
2011-07-25 10:30:14 <1> heron(19808) [wfm] Y2CCWFM.cc(createInLevel):148 Parsing finished
2011-07-25 10:30:14 <3> heron(19808) [liby2] genericfrontend.cc(print_error):920 Error while creating client module ./bnc705425.ycp

The problem is arity being -1 for a 'varargs'-like parameter list. This is not handled properly by yast2-ruby-bindings.

(In reply to comment #16)
> The problem is arity being -1 for a 'varargs'-like parameter list. This is not
> handled properly by yast2-ruby-bindings.

Which is bug 705420.

As a workaround, it should work to call  KerberosClient::read () from example ycp code (without argument).

Or remove default argument value from read function of 
https://github.com/yast/yast--/blob/master/kerberos-client/kerberos_client.rb

A good fix would require Ruby 1.9 (which has Method#parameters). We could make this a pre-requisite for further YaST++ development ...

We could live (and develop) with arity bug not being fixed. The real pain is this crash bug.

(In reply to comment #17)

> Or remove default argument value from read function of 
> https://github.com/yast/yast--/blob/master/kerberos-client/kerberos_client.rb

I just did it in git.

(In reply to comment #17)
> (In reply to comment #16)
> > The problem is arity being -1 for a 'varargs'-like parameter list. This is not
> > handled properly by yast2-ruby-bindings.
> 
> Which is bug 705420.
> 
> As a workaround, it should work to call  KerberosClient::read () from example
> ycp code (without argument).
> 
> Or remove default argument value from read function of 
> https://github.com/yast/yast--/blob/master/kerberos-client/kerberos_client.rb

Right, now I get a segfault

gdb shows:


#0  0x00007f31dff9896f in jump_tag_but_local_jump (state=6, val=<value optimized out>) at eval.c:1853
1853	    JUMP_TAG(state);

state == 6 means 'TAG_RAISE' ?!

Code is:


#define JUMP_TAG(st) do {               \
    ruby_frame = prot_tag->frame;       \
    ruby_iter = prot_tag->iter;         \
    ruby_longjmp(prot_tag->buf,(st));   \
} while (0)

and

(gdb) print prot_tag
$2 = (struct tag *) 0x0

During the workshop Pepa and I found that it is trying to raise a SystemStackError. Looking into that, we found that there seems to be no particularly deep recursion. Maybe we are omitting some initialization step in the bindings.

(In reply to comment #22)
> During the workshop Pepa and I found that it is trying to raise a
> SystemStackError.
Ah, this would explain the TAG_RAISE

> Looking into that, we found that there seems to be no
> particularly deep recursion. Maybe we are omitting some initialization step in
> the bindings.

I was comparing the initialization with the one from cmpi-bindings-ruby and couldn't find a difference.

The segfault is fixed now. Will checkin in a moment.

This brought me on the right track:
http://objectmix.com/ruby/749825-re-rb_require-causes-segfault.html

(Bottom line: You _have_ to wrap your rb_funcall in rb_protect if the funcall might raise an exception)

Now I get:


2011-07-25 15:20:31 <3> heron(10453) [Y2Ruby] ruby/YRuby.cc(callInner):219 KerberosClient.read failed
stack level too deep
        /usr/lib64/ruby/site_ruby/1.8/dbus/bus.rb:211:in `initialize'
        /usr/lib64/ruby/site_ruby/1.8/dbus/bus.rb:686:in `initialize'
        /usr/lib64/ruby/1.8/singleton.rb:94:in `new'
        /usr/lib64/ruby/1.8/singleton.rb:94:in `instance'
        /usr/lib64/ruby/vendor_ruby/1.8/dbus_clients/file_client.rb:30:in `dbus_object'
        /usr/lib64/ruby/vendor_ruby/1.8/dbus_clients/file_client.rb:14:in `read'
        /abuild/projects/yast/yast--/kerberos-client/kerberos_client.rb:10:in `read'


but thats a different problem.

Cool! Do you we already have a bug report for the new bug?

And the 'different problem' might be this one:

http://stackoverflow.com/questions/4082989/calling-ruby-function-from-c-in-a-loop-results-in-stack-level-too-deep

(In reply to comment #26)
> Cool! Do you we already have a bug report for the new bug?

bnc#708059

This is an autogenerated message for OBS integration:
This bug (705425) was mentioned in
https://build.opensuse.org/request/show/77099 Factory / yast2-ruby-bindings