Bug 457582

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.

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

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

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

(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"

Created attachment 313576 [details]
GDB debug info

Here's the gdb output

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

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Any news? This is still broken for F10 on ppc. Just ran into it today.

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.

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.

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

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

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.

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

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

Fedora 11 fixed this bug for us, running Xserve G5s.

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.