Description of problem:
After assorted packages got updated the first run of 'prelink' with
'--quick' flag bombs as follows:
Starting program: /usr/sbin/prelink -av -Rm -q
warning: shared library handler failed to enable breakpoint
Program received signal SIGSEGV, Segmentation fault.
deps_cmp (A=0x7fff9010b968, B=0x7fff9010c848) at cache.c:344
344 if (a->type == ET_NONE && b->type != ET_NONE)
#0 deps_cmp (A=0x7fff9010b968, B=0x7fff9010c848) at cache.c:344
#1 0x000000000043d58b in msort_with_tmp ()
#2 0x000000000043d4eb in msort_with_tmp ()
#3 0x000000000043d4d5 in msort_with_tmp ()
#4 0x000000000043d702 in qsort ()
#5 0x0000000000400fbd in prelink_load_cache () at cache.c:465
#6 0x000000000040e0c0 in main (argc=4, argv=0x7fff90110978) at main.c:390
#7 0x0000000000436cb0 in __libc_start_main ()
#8 0x00000000004001b9 in _start ()
(gdb) p a
$1 = (struct prelink_entry *) 0x0
(gdb) p b
$2 = (struct prelink_entry *) 0x0
Precisely that combination of circumstances and flags is pretty likely
when /etc/cron.daily/prelink is firing up.
Once prelink was run without '--quick' then caches are redone and
a case with two "prelink_entry" pointers beeing NULL does not happen
(or at least is much harder to hit).
Adding, as the first check in deps_cmp() in cache.c:
if (a == NULL && b == NULL)
should solve the matter. We do not really care much about such entries
in any case.
Version-Release number of selected component (if applicable):
always, or at least with a pretty good chance of "success", in
circumstances described above.
This bug was originally described in comments to bug #196941
on a mistaken assumption that this is another manifestation
of a bug reported there.
Skipping -q flag in /etc/cron.daily/prelink should serve as
a workaround until updates are available.
*** This bug has been marked as a duplicate of 197451 ***