Created attachment 979163 [details]
File: backtrace

Created attachment 979164 [details]
File: cgroup

Created attachment 979165 [details]
File: core_backtrace

Created attachment 979166 [details]
File: dso_list

Created attachment 979167 [details]
File: environ

Created attachment 979168 [details]
File: limits

Created attachment 979169 [details]
File: maps

Created attachment 979170 [details]
File: open_fds

Created attachment 979171 [details]
File: proc_pid_status

Created attachment 979172 [details]
File: var_log_messages

(In reply to Richard Z. from comment #0)
> Description of problem:
> running a ruby-tcltk program, very simple graphical GUI.

Could you please provide it?

Created attachment 979344 [details]
reduced test case demonstarting the problem

reduced test case causing coredump, original program had complicated data dependency

Another user experienced a similar problem:

Just upgraded to fc21, from fc20.

This is a modified version of sshmenu I made, but it could never SIGABRT!

reporter:       libreport-2.3.0
backtrace_rating: 4
cmdline:        /usr/bin/ruby-mri /home/jonny/git-external/sshmenu/bin/sshmenu-gnome
crash_function: rb_bug
executable:     /usr/bin/ruby-mri
kernel:         3.19.4-200.fc21.x86_64
package:        ruby-2.1.5-26.fc21
reason:         ruby-mri killed by SIGABRT
runlevel:       N 5
type:           CCpp
uid:            40024

Created attachment 1018187 [details]
File: backtrace

(In reply to Richard Z. from comment #12)
> Created attachment 979344 [details]
> reduced test case demonstarting the problem
> 
> reduced test case causing coredump, original program had complicated data
> dependency

Are there any particular steps to reproduce this?




(In reply to Joao Carlos Mendes Luis from comment #13)
> Another user experienced a similar problem:
> 
> Just upgraded to fc21, from fc20.
> 
> This is a modified version of sshmenu I made, but it could never SIGABRT!

I doubt this is the same issue. The original issue was reported as a Tcl/Tk related issue while sshmenu is using GTK2. If you can reproduce the issue with official package, I'd suggest to report this against sshmenu. If it fails just in your modified version, then I would suspect ruby-gconf2, which appears to be latest in the backtrace. So that would be probably the right component to report this issue against.

Another user experienced a similar problem:

sudo yum install sshmenu
sudo gem install ftools
/usr/bin/sshmenu-gnome

reporter:       libreport-2.3.0
backtrace_rating: 4
cmdline:        /usr/bin/ruby-mri -W2 /usr/bin/sshmenu-gnome
crash_function: rb_bug
executable:     /usr/bin/ruby-mri
kernel:         3.19.4-200.fc21.x86_64
package:        ruby-2.1.6-27.fc21
reason:         ruby-mri killed by SIGABRT
runlevel:       N 5
type:           CCpp
uid:            40024

This bug was found not by me, but by abrt.


I was using my own version of sshmenu because the official version is very old (compared to the github version) and does not work at all (see bug 1215811).

If you manually install ftools in the root system, the bug can be reproduced running /usr/bin/sshmenu-gnome


$ /usr/bin/sshmenu-gnome 
/usr/share/ruby/vendor_ruby/sshmenu.rb:459: warning: assigned but unused variable - x
/usr/share/ruby/vendor_ruby/sshmenu.rb:459: warning: assigned but unused variable - y
/usr/share/ruby/vendor_ruby/sshmenu.rb:459: warning: assigned but unused variable - h
/usr/share/ruby/vendor_ruby/sshmenu.rb:978: warning: assigned but unused variable - w
/usr/share/ruby/vendor_ruby/sshmenu.rb:1022: warning: assigned but unused variable - keylist
/usr/share/ruby/vendor_ruby/sshmenu.rb:1706: warning: shadowing outer local variable - h
/usr/share/ruby/vendor_ruby/sshmenu.rb:2037: warning: shadowing outer local variable - renderer
/usr/share/ruby/vendor_ruby/sshmenu.rb:2295: warning: assigned but unused variable - result
/usr/share/ruby/vendor_ruby/sshmenu.rb:2314: warning: assigned but unused variable - result
/usr/share/ruby/vendor_ruby/sshmenu.rb:2355: warning: assigned but unused variable - item
/usr/share/ruby/vendor_ruby/sshmenu.rb:2981: warning: mismatched indentations at 'end' with 'def' at 2955
/usr/local/share/gems/gems/ftools-0.0.0/lib/ftools.rb:42: warning: shadowing outer local variable - file
/usr/share/ruby/vendor_ruby/sshmenu.rb:1628: warning: optional boolean argument is obsoleted
/usr/share/ruby/vendor_ruby/sshmenu.rb:1628: warning: optional boolean argument is obsoleted
/usr/share/ruby/vendor_ruby/sshmenu.rb:1628: warning: optional boolean argument is obsoleted
/usr/share/ruby/vendor_ruby/sshmenu.rb:1628: warning: optional boolean argument is obsoleted
/usr/lib64/ruby/vendor_ruby/gconf2.so: line 0
   GLib-GObject-WARNING **:cannot retrieve class for invalid (unclassed) type 'GInterface'
/usr/lib64/ruby/vendor_ruby/gconf2.so: [BUG] Segmentation fault at 0x00000000000010
ruby 2.1.6p336 (2015-04-13 revision 50298) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0011 p:-7309104 s:0053 e:000052 TOP    [FINISH]
c:0010 p:---- s:0051 e:000050 CFUNC  :require
c:0009 p:0115 s:0047 e:000046 METHOD /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55
c:0008 p:0015 s:0037 e:000036 TOP    /usr/share/ruby/vendor_ruby/gconf2.rb:2 [FINISH]
c:0007 p:---- s:0035 e:000034 CFUNC  :require
...




This traps abrt, as you can see from the previous comment.

BTW, ruby has just been upgraded to ruby-2.1.6-27.fc21.x86_64

The last too comments were running this binary (and a full yum upgrade).

(In reply to Vít Ondruch from comment #15)
> (In reply to Richard Z. from comment #12)
> > Created attachment 979344 [details]
> > reduced test case demonstarting the problem
> > 
> > reduced test case causing coredump, original program had complicated data
> > dependency
> 
> Are there any particular steps to reproduce this?

no, just run it. Needs F21 and 32 bit to reproduce reliably. The problem
is not 32 bit dependent but may trigger in different circumstances on
different architectures.

> 
> 
> 
> 
> (In reply to Joao Carlos Mendes Luis from comment #13)
> > Another user experienced a similar problem:
> > 
> > Just upgraded to fc21, from fc20.
> > 
> > This is a modified version of sshmenu I made, but it could never SIGABRT!
> 
> I doubt this is the same issue. The original issue was reported as a Tcl/Tk
> related issue while sshmenu is using GTK2. If you can reproduce the issue
> with official package, I'd suggest to report this against sshmenu. If it
> fails just in your modified version, then I would suspect ruby-gconf2, which
> appears to be latest in the backtrace. So that would be probably the right
> component to report this issue against.

we still have the problem that ABRT fails to get backtrace of the ruby process
and all segfaults end up under this bug as they have identical faulty stacktrace - #979344

https://bugzilla.redhat.com/show_bug.cgi?id=1191586

Note that my system is 64 bits!

sshmenu issue is different from this bug.

(In reply to Mamoru TASAKA from comment #22)
> sshmenu issue is different from this bug.

For sshmenu, see bug 1215811

(In reply to João Carlos Mendes Luís from comment #17)
Could you please check bug 1213627, i.e. ruby-gnome2-0.90.4-5.fc21.

(In reply to Richard Z. from comment #19)
> (In reply to Vít Ondruch from comment #15)
> > (In reply to Richard Z. from comment #12)
> > > Created attachment 979344 [details]
> > > reduced test case demonstarting the problem
> > > 
> > > reduced test case causing coredump, original program had complicated data
> > > dependency
> > 
> > Are there any particular steps to reproduce this?
> 
> no, just run it. Needs F21 and 32 bit to reproduce reliably. The problem
> is not 32 bit dependent but may trigger in different circumstances on
> different architectures.

The thing is I can't reproduce this. But I found upstream ticket [1], which talks specifically about 32b. So this might help. Would you mind to test Ruby 2.2 which should already include the patches?


[1] https://bugs.ruby-lang.org/issues/8000


> > (In reply to Joao Carlos Mendes Luis from comment #13)
> > > Another user experienced a similar problem:
> > > 
> > > Just upgraded to fc21, from fc20.
> > > 
> > > This is a modified version of sshmenu I made, but it could never SIGABRT!
> > 
> > I doubt this is the same issue. The original issue was reported as a Tcl/Tk
> > related issue while sshmenu is using GTK2. If you can reproduce the issue
> > with official package, I'd suggest to report this against sshmenu. If it
> > fails just in your modified version, then I would suspect ruby-gconf2, which
> > appears to be latest in the backtrace. So that would be probably the right
> > component to report this issue against.
> 
> we still have the problem that ABRT fails to get backtrace of the ruby
> process
> and all segfaults end up under this bug as they have identical faulty
> stacktrace - #979344

Yes, that is unfortunate. I was suggested by ABRT team to disable the custom SIGSEV signal handling in Ruby, but I am a bit reluctant to do so. Especially since there is no official way to do so.

(In reply to Vít Ondruch from comment #25)
> (In reply to Richard Z. from comment #19)
> > (In reply to Vít Ondruch from comment #15)
> > > (In reply to Richard Z. from comment #12)
> > > > Created attachment 979344 [details]
> > > > reduced test case demonstarting the problem
> > > > 
> > > > reduced test case causing coredump, original program had complicated data
> > > > dependency
> > > 
> > > Are there any particular steps to reproduce this?
> > 
> > no, just run it. Needs F21 and 32 bit to reproduce reliably. The problem
> > is not 32 bit dependent but may trigger in different circumstances on
> > different architectures.
> 
> The thing is I can't reproduce this. But I found upstream ticket [1], which
> talks specifically about 32b. So this might help. Would you mind to test
> Ruby 2.2 which should already include the patches?
> 
> 
> [1] https://bugs.ruby-lang.org/issues/8000

I have tried to rebuild  ruby-2.1.6-27.fc21.src.rpm with tk-diff-ruby-2.1.3-p242
but it does not build cleanly:
rpmbuild -ba SPECS/ruby.spec
...
...
...
+ mkdir -p /home/rz/rpmbuild/BUILDROOT/ruby-2.1.6-28.fc21.i386/usr/lib/rpm/fileattrs
+ install -m 644 /home/rz/rpmbuild/SOURCES/rubygems.attr /home/rz/rpmbuild/BUILDROOT/ruby-2.1.6-28.fc21.i386/usr/lib/rpm/fileattrs
+ install -m 755 /home/rz/rpmbuild/SOURCES/rubygems.req /home/rz/rpmbuild/BUILDROOT/ruby-2.1.6-28.fc21.i386/usr/lib/rpm
+ install -m 755 /home/rz/rpmbuild/SOURCES/rubygems.prov /home/rz/rpmbuild/BUILDROOT/ruby-2.1.6-28.fc21.i386/usr/lib/rpm
+ mkdir -p /home/rz/rpmbuild/BUILDROOT/ruby-2.1.6-28.fc21.i386/usr/share/rubygems/rubygems/defaults
+ cp /home/rz/rpmbuild/SOURCES/operating_system.rb /home/rz/rpmbuild/BUILDROOT/ruby-2.1.6-28.fc21.i386/usr/share/rubygems/rubygems/defaults
+ mv /home/rz/rpmbuild/BUILDROOT/ruby-2.1.6-28.fc21.i386/usr/share/ruby/gems /home/rz/rpmbuild/BUILDROOT/ruby-2.1.6-28.fc21.i386/usr/share/gems
mv: cannot stat '/home/rz/rpmbuild/BUILDROOT/ruby-2.1.6-28.fc21.i386/usr/share/ruby/gems': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.Kayt0k (%install)

Do we have ruby-2.2 packaged?

> > we still have the problem that ABRT fails to get backtrace of the ruby
> > process
> > and all segfaults end up under this bug as they have identical faulty
> > stacktrace - #979344
> 
> Yes, that is unfortunate. I was suggested by ABRT team to disable the custom
> SIGSEV signal handling in Ruby, but I am a bit reluctant to do so.
> Especially since there is no official way to do so.

The custom SIGSEGV handling was never useful to me in any way, more often it did make it harder to find important diagnostic messages so it may not be a big loss.

(In reply to Richard Z. from comment #26)
> I have tried to rebuild  ruby-2.1.6-27.fc21.src.rpm with
> tk-diff-ruby-2.1.3-p242
> but it does not build cleanly:

Please use mock for Ruby builds (or Koji scratch build).

> Do we have ruby-2.2 packaged?

F22+

This does fix it for me
  http://koji.fedoraproject.org/koji/taskinfo?taskID=9667830

(In reply to Richard Z. from comment #28)
> This does fix it for me
>   http://koji.fedoraproject.org/koji/taskinfo?taskID=9667830

Thanks for testing. So you just took the patch [1] from upstream ticket and that is it if I understand it correctly.

Since upstream had some objections about backporting it for 2.1 and older, I  prepared stripped down version of that patch, which might be suitable for upstream. Would you mind to test the scratch build [2] if that works for you as well?


[1] https://bugs.ruby-lang.org/attachments/download/4790/tk-diff-ruby-2.1.3-p242
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=9676324

(In reply to Vít Ondruch from comment #29)

> Thanks for testing. So you just took the patch [1] from upstream ticket and
> that is it if I understand it correctly.

exactly.

> Since upstream had some objections about backporting it for 2.1 and older, I
> prepared stripped down version of that patch, which might be suitable for
> upstream. Would you mind to test the scratch build [2] if that works for you
> as well?

works fine.

ruby-2.1.6-29.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/ruby-2.1.6-29.fc21

(In reply to Richard Z. from comment #30)
> > Since upstream had some objections about backporting it for 2.1 and older, I
> > prepared stripped down version of that patch, which might be suitable for
> > upstream. Would you mind to test the scratch build [2] if that works for you
> > as well?
> 
> works fine.

Thanks for testing. Actually I did not noticed that there is already upstream backport request for Ruby 2.1 with similar patch to mine last one :)

Package ruby-2.1.6-29.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ruby-2.1.6-29.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-8027/ruby-2.1.6-29.fc21
then log in and leave karma (feedback).

ruby-2.1.6-29.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.