If you run
On the attached binary, prelink segfaults almost immediately.
It's before it reads any other files, so I suspect it
will be reproducable.
I'm not sure if the binary is corrupt or not; if it is
corrupt, that's another prelink bug, but I can't give
a reproduction sequence, I'm afraid. It was something
prelink -a -v
prelink -a -u -v
[ upgrade openssl, which is indirectly pulled in by gnome-terminal ]
prelink -a -u
With gnome-terminal and libraries mostly from the
Created attachment 73164 [details]
gnome-terminal binary reproducing the problem
The binary is in fact broken, sh_link member of .gnu.liblist Shdr has
completely bogus value. Not segfaulting on it will be trivial, will try to
look where it might come from too.
--- exec.c~ 2002-08-27 16:35:51.000000000 +0200
+++ exec.c 2002-08-27 16:35:51.000000000 +0200
@@ -793,7 +793,7 @@ prelink_exec (struct prelink_info *info)
- = new_dynstr ? new[new_dynstr] : move->old_to_new[dynstrndx];
+ = new_dynstr != -1 ? new[new_dynstr] : move->old_to_new[dynstrndx];
data = elf_getdata (dso->scn[i], NULL);
data->d_type = ELF_T_WORD;
data->d_size = (ndeps - 1) * sizeof (Elf32_Lib);
seems like the candidate why sh_link was garbage (new[-1]).
I've added checks so that prelink -u wouldn't segfault on bogus sh_link or
sh_info fields too.
Will be soon in prelink-0.2.0-8.
Assuming fixed in current versions.