Description of problem: $ oocalc /usr/lib64/openoffice.org2.0/program/soffice: line 147: 32040 Segmentation fault "$sd_prog/$sd_binary" "$@" in /var/log/messages Jul 29 14:30:59 rousalka kernel: javaldx[32038]: segfault at 000000000040300c rip 0000003d34503909 rsp 00007fff3bb74a60 error 4 Jul 29 14:30:59 rousalka kernel: scalc.bin[32040]: segfault at 000000000040100c rip 0000003d34503909 rsp 00007fff4e89c950 error 4 Version-Release number of selected component (if applicable): openoffice.org-core-2.0.3.x86_64 How reproducible: Always
Does this happen with openoffice.org-core-2.0.3-7.6 ?, and if it does can you give me the output of /usr/sbin/sestatus. Was there a dialog when office crashed which had some "paste me in" info ?
It happens with openoffice.org-core-2.0.3-7.6. These is no crash dialog I forced reinstall of : # rpm -Uvh --force openoffice.org-c* java-1.4.2-gcj-compat-* libgcj-4.1.1-13.x86_64.rpm 1:libgcj ########################################### [ 20%] 2:openoffice.org-core ########################################### [ 40%] 3:java-1.4.2-gcj-compat ########################################### [ 60%] 4:openoffice.org-calc ########################################### [ 80%] 5:java-1.4.2-gcj-compat-p########################################### [100%] and now it works. So I suspect some form of prelink f-up Do you still need /usr/sbin/sestatus ? I don't know if I can reproduce the bug now I've workarounded it
Ok, I've manually forced preliking # /etc/cron.daily/prelink and calc is hosed again
$ /usr/sbin/sestatus SELinux status: disabled
So, installed freshly, all ok, run prelink, not ok.
Did this just break after updating to prelink-0.3.9-2?
This is actually a glibc bug. 71 const ElfW(Sym) *symtab 72 = (const ElfW(Sym) *) D_PTR (match, l_info[DT_SYMTAB]); 73 const char *strtab = (const char *) D_PTR (match, l_info[DT_STRTAB]); 74 75 ElfW(Word) strtabsize = match->l_info[DT_STRSZ]->d_un.d_val; 76 77 const ElfW(Sym) *symtabend; 78 if (match->l_info[DT_HASH] != NULL) 79 symtabend = (symtab 80 + ((Elf_Symndx *) D_PTR (match, l_info[DT_HASH]))[1]); 81 else 82 /* There is no direct way to determine the number of symbols in the 83 dynamic symbol table and no hash table is present. The ELF 84 binary is ill-formed but what shall we do? Use the beginning of 85 the string table which generally follows the symbol table. */ 86 symtabend = (const ElfW(Sym) *) strtab; With prelinking (but even otherwise, there are no guarantees), the assunmption that .dynstr immediately follows .dynsym is wrong. And, for binaries and/or libraries built with --hash-style=gnu there is no DT_HASH, which has been superceeded by DT_GNU_HASH. So, glibc needs to handle that.
Should be fixed in glibc-2.4.90-17 in rawhide.
*** Bug 200313 has been marked as a duplicate of this bug. ***
*** Bug 200366 has been marked as a duplicate of this bug. ***