Soffice crashes with segv?

[aviancer]

HELP!

After a recent update to my RHEL4 system, soffice fails to launch with a sigsegv. The same error happens with versions 2.2 and 2.3 at about the same place according to strace. Does anyone have a remedy for this issue?

Thanks!
~ Paul

Code: Select all

./soffice: line 251:  5275 Segmentation fault      "$sd_prog/$sd_binary" "$@"

In addition to the inline strace snippet below, I've attached the full strace output.

Code: Select all

[ DEV wyerd:/opt/openoffice.org2.0/opt/openoffice.org2.2/program ]
0 > strace -f ./soffice
execve("./soffice", ["./soffice"], [/* 36 vars */]) = 0
uname({sys="Linux", node="wyerd.examen.com", ...}) = 0
brk(0)                                  = 0x9d18000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/i686/sse2/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/tls/i686/sse2", 0xbff70230) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/i686/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/usr/X11R6/lib/tls/i686", 0xbff70230) = -1 ENOENT (No such file or directory)
open("/usr/X11R6/lib/tls/sse2/libtermcap.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
(SNIP)
[pid  5355] read(6, "i\0\0\0\6\0\0\0", 8) = 8
[pid  5355] read(6, "j\0\0\0\6\0\0\0", 8) = 8
[pid  5355] read(6, "k\0\0\0\1\0\0\0", 8) = 8
[pid  5355] read(6, "l\0\0\0\1\0\0\0", 8) = 8
[pid  5355] read(6, "m\0\0\0\1\0\0\0", 8) = 8
[pid  5355] read(6, "n\0\0\0\1\0\0\0", 8) = 8
[pid  5355] read(6, "o\0\0\0\10\0\0\0", 8) = 8
[pid  5355] read(6, "p\0\0\0\10\0\0\0", 8) = 8
[pid  5355] read(6, "q\0\0\0\10\0\0\0", 8) = 8
[pid  5355] read(6, "r\0\0\0\10\0\0\0", 8) = 8
[pid  5355] read(6, "\204\0\0\0\10\0\0\0", 8) = 8
[pid  5355] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 5344 resumed
Process 5355 detached
[pid  5356] <... futex resumed> )       = -1 EINTR (Interrupted system call)
[pid  5356] +++ killed by SIGSEGV +++
[pid  5344] <... waitpid resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], 0) = 5355
[pid  5344] fstat64(2, {st_mode=S_IFREG|0664, st_size=304129, ...}) = 0
(SNIP)
[pid  5344] fstat64(3, {st_mode=S_IFREG|0644, st_size=1474, ...}) = 0
[pid  5344] mmap2(NULL, 1474, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7da8000
[pid  5344] close(3)                    = 0
[pid  5344] write(2, "./soffice: line 251:  5355 Segme"..., 78./soffice: line 251:  5355 Segmentation fault      "$sd_prog/$sd_binary" "$@"
) = 78
[pid  5344] rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
[pid  5344] rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
[pid  5344] rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
[pid  5344] rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
[pid  5344] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid  5344] --- SIGCHLD (Child exited) @ 0 (0) ---
[pid  5344] waitpid(-1, 0xbff7016c, WNOHANG) = 0
[pid  5344] sigreturn()                 = ? (mask now [])
[pid  5344] rt_sigaction(SIGINT, {SIG_DFL}, {0x807612b, [], SA_RESTORER, 0x9b8908}, 8) = 0
[pid  5344] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
[pid  5344] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid  5344] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid  5344] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid  5344] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid  5344] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid  5344] rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
[pid  5344] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid  5344] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid  5344] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid  5344] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid  5344] exit_group(0)               = ?
Process 5355 detached

[ccornell]

Was OOo working on RHEL4 prior to the update? What was updated? Did you install SELinux kernel?

[aviancer]

Yes, OO was running perfectly prior to update. I'll have to poke about in the logs to find out what, specifically were updated. I don't believe I'm running selinux extensions. (RH is /not/ my area of expertise, but it's what I'm stuck with at work)

[aviancer]

Attached is the up2date run which contained the patches after which OO failed.

[ccornell]

RHEL is not my area either. I use SLES and openSUSE. Much much easier to use

I've done some digging, and it seems that this "might" be an issue with the SE kernel (which is why I asked if you were using SE). The SE kernel locks everything down, and you have to explicitly allow apps to run (or so I understand). Did you go from a regualr to SE kernel in the update? I didn't see it in the logs, but... asking anyway. If you are running SE, you might want to look at the access rights? I'm not 100% sure this is where the issue is, but it's worth checking.

Anyone else here have any experience with SELinux?

[aviancer]

I didn't switch anything to SE Linux. I know some of the libs are downloaded, but I didnt change the config to use SE. Anyway, it seems to stand to reason that if it were an SE problem, that there wouldn't be a segment violation - rather some other kind of access error.

[aviancer]

Here's the interesting part of the strace. The program crashes reading data from file descriptor 6. Here's where file descriptor 6 is created:

Code: Select all

31695 socket(PF_FILE, SOCK_STREAM, 0)   = 6
31695 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
31695 uname({sys="Linux", node="wyerd.examen.com", ...}) = 0
31695 uname({sys="Linux", node="wyerd.examen.com", ...}) = 0
31695 connect(6, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 19) = 0
31695 uname({sys="Linux", node="wyerd.examen.com", ...}) = 0
31695 fcntl64(6, F_SETFD, FD_CLOEXEC)   = 0

It would appear that fd6 is the X file socket, apparently. I'm not much of an X protocol expert -- maybe there's someone out there that can help decipher the reads, to understand why the protocol is failing??

[aviancer]

I no longer believe this is an OOo issue. The ATI device management console fails with EXACTLY THE SAME ERROR and ptrace result. I now suspect that there is a library issue with the RHEL4 updates that are failing to interface properly with the X server.

If you have a suggestion on a debugging method or resolution technique, please feel free to email at paulprogrammer <at@at> []gmail [] --dot-- com

Thank you all,
~ Paul

[ccornell]

I had done some digging back when this thread was started, and there are a few people with the same or similar issues... all with RHEL4... I don't have any suggestions for you though.. other than looking at what was updated and try rolling back one at a time until you find the culprit.