Bug 457582 - Ruby is aborting on PPC
Ruby is aborting on PPC
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: ruby (Show other bugs)
10
All Linux
medium Severity high
: ---
: ---
Assigned To: Jeroen van Meeuwen
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-01 12:15 EDT by Mike McGrath
Modified: 2009-12-18 01:16 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:16:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace from running facter (311.32 KB, text/plain)
2008-08-05 21:49 EDT, Mike McGrath
no flags Details
GDB debug info (7.68 KB, text/plain)
2008-08-06 10:40 EDT, Mike McGrath
no flags Details

  None (edit)
Description Mike McGrath 2008-08-01 12:15:29 EDT
$ ruby -nosuchmodule -e 'puts "Hello"'
Aborted

I'm not quite sure what the problem is but if I install, for example, facter and
try to run it I get:

$ facter
Aborted

Seems to happen with lots if not all of the ruby packages.
Comment 1 Akira TAGOH 2008-08-05 04:42:46 EDT
Can you provide the backtrace and more info about this problem? I have no access to ppc machine here. it's hard to investigate the kind of the architecture specific issue.
Comment 2 Mike McGrath 2008-08-05 21:49:34 EDT
Created attachment 313511 [details]
strace from running facter

(In reply to comment #1)
> Can you provide the backtrace and more info about this problem? I have no

There's really no backtrace.  Just the "Aborted" setup.  I've attached an strace from running facter (a ruby app)


Right now the run does:

# facter
Aborted
Comment 3 Akira TAGOH 2008-08-05 23:13:58 EDT
(In reply to comment #2)
> There's really no backtrace.  Just the "Aborted" setup.  I've attached an
> strace from running facter (a ruby app)

I meant the backtrace on gdb. gdb should catches up SIGABRT.
Comment 4 Mike McGrath 2008-08-06 09:50:28 EDT
I've not used gdb before so I'm not sure if this is exactly what you're looking for but after installing all the debuginfo packages, etc:

This GDB was configured as "ppc-redhat-linux-gnu"...
(gdb) run /usr/bin/facter
Starting program: /usr/bin/ruby /usr/bin/facter
[Thread debugging using libthread_db enabled]
[New Thread 0xf7ff2000 (LWP 3495)]

Program received signal SIGABRT, Aborted.
0x0f66789c in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Comment 5 Akira TAGOH 2008-08-06 10:27:09 EDT
(In reply to comment #4)
> I've not used gdb before so I'm not sure if this is exactly what you're looking
> for but after installing all the debuginfo packages, etc:

Okay.

> 
> This GDB was configured as "ppc-redhat-linux-gnu"...
> (gdb) run /usr/bin/facter
> Starting program: /usr/bin/ruby /usr/bin/facter
> [Thread debugging using libthread_db enabled]
> [New Thread 0xf7ff2000 (LWP 3495)]
> 
> Program received signal SIGABRT, Aborted.
> 0x0f66789c in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> 64        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

then, type "thread apply all bt"
Comment 6 Mike McGrath 2008-08-06 10:40:17 EDT
Created attachment 313576 [details]
GDB debug info

Here's the gdb output
Comment 7 Bug Zapper 2008-11-25 21:38:17 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Fedora Admin XMLRPC Client 2009-01-30 07:45:17 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 jbooth 2009-03-02 17:07:10 EST
Any news? This is still broken for F10 on ppc. Just ran into it today.
Comment 10 Nicholas Haggin 2009-03-04 14:09:03 EST
To expand on comment #9: now that F8 has reached end-of-life, we are interested in updating a large (768 node) compute cluster to F10. We use Puppet for configuration management, and without a functioning Ruby the upgrade is impossible.
Comment 11 Jeroen van Meeuwen 2009-03-04 17:08:09 EST
I have been unable to replicate this issue so far. My only ppc capable box is a ppc64. A ppc chroot through mock does not show the same behaviour.
Comment 12 Nicholas Haggin 2009-03-05 12:19:53 EST
(In reply to comment #11)
> I have been unable to replicate this issue so far. My only ppc capable box is a
> ppc64. A ppc chroot through mock does not show the same behaviour.

What kind of PPC box? We're using Xserve G5s, if that gives you any more data.

Two additional notes:

1) I attempted to obtain a backtrace similar to the one Mike McGrath got, and GDB promptly segfaulted.

2) I attempted to rebuild Ruby from the SRPM, and two of the subprocesess aborted as well:

ar rcu libruby-static.a array.o bignum.o class.o compar.o dir.o dln.o enum.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o variable.o version.o  dmyext.o
gcc -O2 -g -fsigned-char -Wall  -fPIC  -DRUBY_EXPORT -D_GNU_SOURCE=1  -L.  -rdynamic -Wl,-export-dynamic   main.o  libruby-static.a -lpthread -ldl -lcrypt -lm   -o miniruby
make: *** [libruby.so.1.8.6] Aborted
gcc -shared -Wl,-soname,libruby.so.1.8   array.o bignum.o class.o compar.o dir.o dln.o enum.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o variable.o version.o  dmyext.o -lpthread -ldl -lcrypt -lm   -o libruby.so.1.8.6
make: *** [.rbconfig.time] Aborted
make: *** Waiting for unfinished jobs....
error: Bad exit status from /var/tmp/rpm-tmp.M7AhnZ (%build)

Sorry for the paucity of data....
Comment 13 Jeroen van Meeuwen 2009-03-05 12:57:58 EST
(In reply to comment #12)
> (In reply to comment #11)
> > I have been unable to replicate this issue so far. My only ppc capable box is a
> > ppc64. A ppc chroot through mock does not show the same behaviour.
> 
> What kind of PPC box? We're using Xserve G5s, if that gives you any more data.
> 

I have a dual-core, dual-proc ppc64 YDL Powerstation from Terrasoft Solutions.
Comment 14 Jeroen van Meeuwen 2009-03-14 22:09:22 EDT
I cannot reproduce this on a Fedora 10 ppc32 box I just got (Apple G3 developer station). Running facter gives me the output I expect.
Comment 15 Bryson Lee 2009-11-05 19:26:19 EST
Here is a (shorter) backtrace from an abort of facter on an IBM JS12 Power6 blade, running Fedora10 (ppc64 kernel, ppc userland).  This problem is a complete blocker for our use of puppet...

[root@blade01 ~]# gdb ruby
GNU gdb Fedora (6.8-32.fc10)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "ppc-redhat-linux-gnu"...
(gdb) run /usr/bin/facter
Starting program: /usr/bin/ruby /usr/bin/facter
[Thread debugging using libthread_db enabled]
[New Thread 0xf7e20210 (LWP 15143)]

Program received signal SIGABRT, Aborted.
0xf7e59dfc in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0xf7e59dfc in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0xf7e5bcd4 in abort () at abort.c:88
#2  0x0feb9884 in rb_jump_context (val=<value optimized out>, env=<value optimized out>) at eval.c:97
#3  rb_longjmp (tag=6, mesg=4158466704) at eval.c:4632
#4  0x0feb9bc8 in rb_exc_raise (mesg=<value optimized out>) at eval.c:4648
#5  0x0fea76f0 in rb_raise (exc=4158763440, fmt=<value optimized out>) at error.c:1061
#6  0x0fec5f98 in load_failed () at eval.c:7226
#7  rb_require_safe (fname=4158696672, safe=0) at eval.c:7296
#8  0x0fec60a0 in rb_f_require (obj=<value optimized out>, fname=<value optimized out>) at eval.c:7162
#9  0x0feabe64 in call_cfunc (func=0xfec6070 <rb_f_require>, recv=4158775800, len=<value optimized out>, 
    argc=<value optimized out>, argv=<value optimized out>) at eval.c:5721
#10 0x0feb79f8 in rb_call0 (klass=4158781632, recv=4158775800, id=9737, oid=9737, argc=1, argv=0xffff99f0, 
    body=0xf7e0cf78, flags=2) at eval.c:5870
#11 0x0feb7bc4 in rb_call (klass=4158781632, recv=4158775800, mid=9737, argc=1, argv=0xffff99f0, scope=1, 
    self=4158775800) at eval.c:6117
#12 0x0feb2694 in rb_eval (self=4158775800, n=<value optimized out>) at eval.c:3505
#13 0x0feb50f0 in rb_eval (self=4158775800, n=<value optimized out>) at eval.c:3306
#14 0x0fec52e4 in ruby_exec_internal () at eval.c:1642
#15 0x0fec534c in ruby_exec () at eval.c:1662
#16 0x0fec539c in ruby_run () at eval.c:1672
#17 0x1000178c in main (argc=2, argv=0xffffe764, envp=<value optimized out>) at main.c:48
Comment 16 Bug Zapper 2009-11-18 02:53:28 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Nicholas Haggin 2009-11-23 08:20:33 EST
Fedora 11 fixed this bug for us, running Xserve G5s.
Comment 18 Bug Zapper 2009-12-18 01:16:32 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.