Description of problem: I receive everyday after the cron job worked a mail saying: > /etc/cron.daily/prelink: > > /etc/cron.daily/prelink: line 47: 6111 Aborted /usr/sbin prelink -av $PRELINK_OPTS >> /var/log/prelink/prelink.log 2>&1 I can then see on the file /var/log/prelink/prelink.log at the end the line: > Prelinking /usr/bin/git-receive-pack > Prelinking /usr/bin/qrstat > Prelinking /usr/bin/g_nmtraj > Prelinking /usr/bin/pawX11.dynamic > Prelink failed with return value 134 Version-Release number of selected component (if applicable): $ rpm -q prelink prelink-0.4.0-3.x86_64 How reproducible: Every day Steps to Reproduce: 1.run the cron task 2.get the mail 3.read the log file Actual results: Receive an error mail See the line mentioned above on the log file Expected results: No error :) Additional info: I don't exactly know what would be needed to debug this error, so please do not hesitate to ask for additional information. :)
*** Bug 436878 has been marked as a duplicate of this bug. ***
I to get this every single day on my F11 machines. The last bit in prelink.log is: Prelinking /usr/lib64/matlab-2009a/sys/os/glnxa64/libstdc++.so.6.0.9 Prelink failed with return value 134 Yeah, closed source application and all that, but still, prelink shouldn't just abort when it sees something it doesn't understand. Not to mention that the paw package that also causes this problem is free software and in Fedora. I can share that library if someone wants to look at it, but duplicate bugs have been open for years on a so I'm not sure anyone's concerned about it. I guess I should just blacklist the directory.
All aborts in prelink aren't duplicates, there are over 220 assertions/abort calls. What would be interesting is to copy the problematic library into some empty directory and try to prelink just that library (prelink /tmp/foo/libstdc++.so.6.0.9). If it aborts the same way, you can install prelink-debuginfo and see where it crashed and post readelf -Wa output on that library.
Sorry, in the absence of useful debugging information making it into the log it's not really obvious that these might not be the same issue. I did what you asked and it does abort, with a useful message this time. > s prelink libstdc++.so.6.0.9 prelink: dwarf2.c:801: adjust_dwarf2_aranges: Assertion `ptr == endcu' failed. [1] 7211 abort sudo prelink libstdc++.so.6.0.9 I think it might help immensely if that output actually made it into the prelink log. I'm not sure why it doesn't; stderr seems to be properly redirected I installed the debuginfo and generated a core; here's the backtrace: #0 0x0000000000475475 in raise () (gdb) bt #0 0x0000000000475475 in raise () #1 0x0000000000444b8a in abort () #2 0x000000000043fbee in __assert_fail () #3 0x0000000000420e67 in adjust_dwarf2_aranges (adjust=<value optimized out>, start=<value optimized out>, dso=<value optimized out>) at dwarf2.c:801 #4 adjust_dwarf2 (adjust=<value optimized out>, start=<value optimized out>, dso=<value optimized out>) at dwarf2.c:1132 #5 0x000000000041d66e in adjust_dso (dso=0x10074c0, start=22, adjust=16786464) at dso.c:1388 #6 0x00000000004053db in prelink_ent (ent=0x10002d0) at doit.c:130 #7 0x0000000000405486 in prelink_all () at doit.c:253 #8 0x000000000040eff7 in main (argc=2, argv=0x7fff07599b48) at main.c:412 which probably isn't all that enlighhtening. I will attach the readelf -Wa output. As for the pawX11.dynamic problem which originally prompted this bug report, I'm afraid I can't reproduce it.
Created attachment 368292 [details] readelf -Wa output
In that case readelf -wr libstdc++.so.6.0.9 is interesting, maybe also objdump -s -j .debug_aranges libstdc++.so.6.0.9 .
Created attachment 368303 [details] readelf -wr output
Created attachment 368304 [details] objdump -s -j .debug_aranges output
Ah, the buggiest gcc ever released (4.2.x) in action :(. See http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01200.html for more details. Guess I'll turn that assert into an error which will prevent prelinking it. Makes me wonder why matlab doesn't ship with stripped libstdc++.so.6 at least though...
For the reference, I do not see this bug on my machine any more.
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 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.
Also seen on fedora 12.
x86_64 on amd 9550. upgraded to F12 from 11. no F12 kernel. no f12 radeonhd The rest is F12 more or less.
prelink-0.4.2-4.fc12.x86_64 same errorlevel 134 Happened for the first time during the Wed Dec 2009 16 03:30 run.
gcc-4.4.2-7.fc12.x86_64 btw... (but this is not gentoo, you built most of the binaries on this box)
and it failed again the past few days. now what can we do?
Also my recently and freshly built and installed MytTV running box, with Fedora 12 x86_64 has this issue. So is it defective by design? Or what can we DO to help fix this issue?
Running the reconstructed prelink command from the cli gives me a run without the problem. So what's next?
Box that was recently upgraded to F13: /etc/cron.daily/prelink: /etc/cron.daily/prelink: line 47: 21195 Aborted /usr/sbin/prelink -av $PRELINK_OPTS >> /var/log/prelink/prelink.log 2>&1 So no improvement?
No progress since Fedora 13, so we're at 14 now. What can we do to help fix the issue?
Any updates? It has been two years... (no we do not count bugzappers)
The same happens on all my machines after updating from FC16 to FC17: /etc/cron.daily/prelink: /etc/cron.daily/prelink: line 47: 2385 Aborted (core dumped) /usr/sbin/prelink -av $PRELINK_OPTS >> /var/log/prelink/prelink.log 2>&1 Note: I'm clearing the "needinfo" flag now, as I cannot see which additional information would be needed.
Oh, and can someone who has the necessary permissions please update the version entry to "Fedora 17"? Thanks.
Hi, this is happening to me too, after FC16 -> FC17 upgrade. I modified the /etc/cron.daily/prelink by adding a set -x to the script and launching prelink with strace. I can provide the logs if this may help. The log is 2.2GB in size, but maybe the last 1000 lines may be enough?
I also have this exact problem every day, in a fresh-install of a completely clean Fedora-17 with no taints or anything. Like others, the prelinking aborts on or after handling the as-shipped paw library. Prelinking /usr/lib64/libply.so.2.0.0 Prelinking /usr/lib64/libply-splash-core.so.2.0.0 Prelinking /usr/bin/pawd Prelink failed with return value 134 I take it from the dates on this bug, that it has not been fixed for 3 years. What can I supply to get some movement on this bug? What do you need?
This is been happening to me in one of my F17 systems. I have lots of error messages in prelink.log. After I get rid of the lines with 'because its dependency XXX could not be prelinked', I have 20 lines complaining of "undefined non-weak symbols" for these libs: /usr/lib64/libgmyth.so.0 /lib64/libabrt.so.0 /usr/lib64/htdig/libcommon-3.2.0.so /lib64/libtheoraenc.so.1 /usr/lib64/tracker-0.14/libtracker-data.so.0 /usr/lib64/libgpsd.so.20 /usr/lib64/man-db/libmandb-2.6.0.2.so /lib64/libgle.so.3 /lib64/libusal.so.0 /usr/lib64/libogrove.so.0 /usr/lib64/libospgrove.so.0 /lib64/libFestival.so.1.96.0 /lib64/libreport-gtk.so.0 /usr/lib64/htdig/libhtnet-3.2.0.so /usr/lib64/htdig/libhtword-3.2.0.so /usr/lib64/htdig/libht-3.2.0.so /lib64/libmathview_backend_svg.so.0 /lib64/libvamp-hostsdk.so.3 /lib64/libpinyin.so.2 /lib64/libabrt_web.so.0 and five complaining "Could not prelink XXX because it doesn't use /usr/lib64/freetype-freeworld/libfreetype.so.6, but one of its dependencies has been prelinked against it". Guess I need to track each of the files above and file a bug to whichever package they come from. Not sure about the libfreetype error.
- This bug happens on clean installs - This bug has been open for a while - This bug has seen logging attached to it So when can we please see patches or anything towards a solution, please? At the end of september I will have plenty of time to test...
Still happening. Any updates? It's been just 3.5 years now. Can we help fix this?
prelink runs clean on F18, on the machine where I had lots of errors on F17 (comment 27)
Confirmation: While F17 did, F18 does not exhibit this bug.
When will F17 get the fix for this years old bug?
Created attachment 763139 [details] xz of a reproducer PASS: prelink-0.4.6-5.fc17.i686 glibc-2.15-59.fc17.i686 PASS: prelink-0.4.6-8.fc18.i686 glibc-2.16-31.fc18.i686 PASS: prelink-0.5.0-1.fc20.i686 glibc-2.17.90-2.fc20.i686 FAIL: prelink-0.5.0-1.fc19.i686 glibc-2.17-4.fc19.i686 prelink: dwarf2.c:923: adjust_dwarf2_aranges: Assertion `ptr == endcu' failed. rm -f ld-linux.so.2{,.debug,.full};cp -p /lib/ld-linux.so.2 /usr/lib/debug/lib/ld-linux.so.2.debug .;prelink -uN ld-linux.so.2;prelink -uN ld-linux.so.2.debug;eu-unstrip -o ld-linux.so.2.full ld-linux.so.2{,.debug};/usr/sbin/prelink -N ./ld-linux.so.2.full;echo $? "ld-linux.so.2.full" is attached here: $ prelink -N ld-linux.so.2.full prelink: dwarf2.c:923: adjust_dwarf2_aranges: Assertion `ptr == endcu' failed.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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 problem also exisits in Fedora 21 - I see it many (probably all) systems I'm running here. Please update version to 21 ! E-Mail says: /etc/cron.daily/prelink: /etc/cron.daily/prelink: line 47: 30398 Aborted (core dumped) /usr/sbin/prelink -av $PRELINK_OPTS >> /var/log/prelink/prelink.log 2>&1 It is always "line 47"; the PID obviously varies. In the log files I see this: ... prelink: dso.c:1512: recompute_nonalloc_offsets: Assertion `!((dso->shdr[i].sh_flags) & ((1 << 0) | (1 << 1) | (1 << 2)))' failed. ... Prelink failed with return value 134 The "asssertion failed message" is identical on all systems. I wonder why we are still using prelink-0.5.0-1.fc20.x86_64 (i.e. a FC20) in FC21 systems? Note: I'm clearing the "needinfo" flag now, as I cannot see which additional information would be needed.
Prelink isn't installed by default any longer, and shouldn't be installed on most machines. I'm honestly not sure why it is still in the distribution, and if I were you I'd just remove it. Having an F20 package on an F21 system is not, in general, a problem; it just means the package wasn't rebuilt. In this case, though, it's because the package doesn't even build correctly. It appears this is due to a lack of support on ARM. I guess the package really should just be removed at this point, or at least have an ExcludeArch:. BTW, the needinfo flag was for the package maintainer; it should be kind of obvious which additional information he would supply.
If F20 is supported, then why not support prelink-0.5.0-1.fc20.* ? 'no longer installed' also expects explanation as to why.
(In reply to Jason Tibbitts from comment #37) > Prelink isn't installed by default any longer, and shouldn't be installed on > most machines. I'm honestly not sure why it is still in the distribution, > and if I were you I'd just remove it. Even if you remove it, it gets automatically pulled in and installed by othe rpackages that depend on it, for example, try installing the ghc-rpm-macros package: ====================================================================================================== Package Arch Version Repository Size ====================================================================================================== Installing: ghc-rpm-macros x86_64 1.2.17-1.fc21 updates 48 k Installing for dependencies: prelink x86_64 0.5.0-1.fc20 fedora 1.0 M Transaction Summary ====================================================================================================== Install 1 Package (+1 Dependent package)
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora 'version' of '21'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.