Description of problem: prelink -av dies with SIGABRT write(1, "/usr/lib/libxffm_tubo.so.0 "..., 79) = 79 write(1, "/usr/lib/libxffmsmb.so.0 "..., 79) = 79 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 getpid() = 3542 kill(3542, SIGABRT) = 0 Version-Release number of selected component (if applicable): prelink-0.3.1-2 How reproducible: 100% Steps to Reproduce: 1. Install 'everything' rawhide 20040414 2. prelink 3. up2date to current. 4. prelink again Actual results: Prelink kills itself without explaining why, after printing the load addresses of all the libraries write(1, "/usr/lib/libxffm_fstab.so.0 "..., 79) = 79 write(1, "/usr/lib/libxffm_tubo.so.0 "..., 79) = 79 write(1, "/usr/lib/libxffmsmb.so.0 "..., 79) = 79 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 getpid() = 3542 kill(3542, SIGABRT) = 0 --- SIGABRT (Aborted) @ 0 (0) --- Additional Info: qemu is installed and hence i386 libraries in /usr/gnemul. The strace doesn't seem to show it touching /usr/gnemul though, so I don't think that's the reason.
Created attachment 99569 [details] strace output
#0 0x100795ec in kill () #1 0x10079430 in raise () #2 0x1004da80 in abort () #3 0x1000e444 in layout_libs () at layout.c:622 #4 0x1000ecb8 in main (argc=2, argv=0x7ffff894) at main.c:394 #5 0x100463fc in generic_start_main () #6 0x100461f4 in __libc_start_main ()
er... (gdb) up 3 #3 0x1000e444 in layout_libs () at layout.c:622 622 abort (); (gdb) p/x ((deps[j - 1]->end + max_page_size - 1) & ~(max_page_size - 1)) $7 = 0xefa0000 (gdb) p/x deps[j]->base $8 = 0xefa0000 ... how did that trigger?
Created attachment 99572 [details] prelink output OK, there really does seem to be an overlap. /usr/lib/qt-3.3/lib/libqt-mt.so.3 0e850000-0ef94fa0 /usr/lib/libkmailprivate.so.0 0e700000-0ead4f44 ABORT! /usr/lib/libkmailprivate.so.0 ends at ead4f44 but /usr/lib/qt-3.3/lib/libqt-mt.so.3 starts at e850000
Please put a breakpoint on layout_libs, run it till it reaches that function, then: p prelink_entry_dump (prelink_filename_htab, "/tmp/prelink.layout.list") and attach here the file it creates. THanks.
It's running now (with --dry-run). Using '-m' seems to have avoided the problem and that's also running now (for real)
Created attachment 99577 [details] Prelink layout list
Can't reproduce with prelink-0.3.2-11, there is no abort in layout_libs when I prelink_entry_restore (prelink_filename_htab, "prelink.layout.list") you provided.