Apache OpenOffice (AOO) Bugzilla – Issue 10451
soffice closes just after beeing opened du to a ~/.ICEauthority file.
Last modified: 2003-03-11 17:56:36 UTC
Hi, [Context] I had a working installation of OpenOffice, and installed new fonts as root. From this moment, the application stopped to work for a particular user. [Bug] When I launch soffice or swriter, I get the welcome screen, and the application opens as usual, but closes just before I should get the hand on it. (The window closes, and the application quits.) [Fix] I managed to fix the problem by removing the ~/.ICEauthority file for this user. From that moment, the application worked nicely. If I put the original file back, the broken behavior comes back. I played a little with strace and diff : chezmoi:~> strace swriter > & /tmp/soffice-good.log chezmoi:~> mv /tmp/carole.bak/.ICEauthority . # restoring the .ICEauthority file. chezmoi:~> strace swriter > & /tmp/soffice.log chezmoi:~> du -sh /tmp/soffice-good.log /tmp/soffice.log 15M /tmp/soffice-good.log 17M /tmp/soffice.log chezmoi:~> diff /tmp/soffice-good.log /tmp/soffice.log > /tmp/soffice.diff chezmoi:~> du -sh /tmp/soffice.diff 31M /tmp/soffice.diff A portion of the diff file may be interesting (This is where the files begin to differ really, and the reason why I suspected the .ICEauthority file. 2031,2039c2031,2081 < access("/home/carole/.ICEauthority", R_OK) = -1 ENOENT (No such file or directory) < write(5, "\0\2\1\0\4\0\0\0\0\0\0\0\0\0\0\0\3\0MIT\0\0\0\3\0001.0"..., 40) = 40 < read(5, "\0\0\4\0\16\0\0\0", 8) = 8 < read(5, "\2\1\0\0\2\0\0\0", 8) = 8 < read(5, "a\0None of the authentication pro"..., 104) = 104 < close(5) = 0 < write(4, "\2\0\4\0002\0\0\0\0\10\0\0\0\0\10\0\1\30\v\0\1\0 \0032"..., 84) = 84 < read(4, "\20i\n\0002\0\0\0\1\0 \3\0\0\0\0\20\0\20\0\0\0\0\0\0\0"..., 32) = 32 < read(4, "\1\r\v\0\0\0\0\0\352\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 --- > access("/home/carole/.ICEauthority", R_OK) = 0 > brk(0x808a000) = 0x808a000 > open("/home/carole/.ICEauthority", O_RDONLY) = 6 > fstat64(6, {st_mode=S_IFREG|0600, st_size=1445, ...}) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40d5c000 > read(6, "\0\3ICE\0\0\0!local/chezmoi:/tmp/.ICE"..., 4096) = 1445 > read(6, "", 4096) = 0 > close(6) = 0 > munmap(0x40d5c000, 4096) = 0 > write(5, "\0\2\1\1\6\0\0\0\0\0\0\0\0\0\0\0\3\0MIT\0\0\0\3\0001.0"..., 56) = 56 > read(5, "\0\3\0@\1\0\0\0", 8) = 8 > read(5, "\0\0\0\0\0\0\0\0", 8) = 8 > access("/home/carole/.ICEauthority", R_OK) = 0 > open("/home/carole/.ICEauthority", O_RDONLY) = 6 > fstat64(6, {st_mode=S_IFREG|0600, st_size=1445, ...}) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40d5c000 > read(6, "\0\3ICE\0\0\0!local/chezmoi:/tmp/.ICE"..., 4096) = 1445 > close(6) = 0 > munmap(0x40d5c000, 4096) = 0 > write(5, "\0\4\1\1\3\0\0\0\20\0\0\0\0\0\0\0\277?\\o\3,\201\0067\21"..., 32) = 32 > read(5, "\0\6\0@\2\0\0\0", 8) = 8 > read(5, "\3\0MIT\0\0\0\3\0001.0\0\0\0", 16) = 16 > access("/home/carole/.ICEauthority", R_OK) = 0 > open("/home/carole/.ICEauthority", O_RDONLY) = 6 > fstat64(6, {st_mode=S_IFREG|0600, st_size=1445, ...}) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40d5c000 > read(6, "\0\3ICE\0\0\0!local/chezmoi:/tmp/.ICE"..., 4096) = 1445 > read(6, "", 4096) = 0 > close(6) = 0 > munmap(0x40d5c000, 4096) = 0 > write(5, "\0\7\1\0\7\0\0\0\1\1\0\0\0\0\0\0\4\0XSMP\201\6\3\0MIT\335"..., 64) = 64 > read(5, "\0\3\0@\1\0\0\0", 8) = 8 > read(5, "\0\0MIT\0\0\0", 8) = 8 > access("/home/carole/.ICEauthority", R_OK) = 0 > open("/home/carole/.ICEauthority", O_RDONLY) = 6 > fstat64(6, {st_mode=S_IFREG|0600, st_size=1445, ...}) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40d5c000 > read(6, "\0\3ICE\0\0\0!local/chezmoi:/tmp/.ICE"..., 4096) = 1445 > close(6) = 0 > munmap(0x40d5c000, 4096) = 0 > write(5, "\0\4\1\0\3\0\0\0\20\0\0\0\0\0\0\0\277?\\o\3,\201\0067\21"..., 32) = 32 > read(5, "\0\10\0\1\3\0\0\0", 8) = 8 > read(5, "\7\0GnomeSM\0001.\7\0001.4.0.6\0\0\0", 24) = 24 > write(5, "\1\1\1\0\1\0\0\0\0\0\0\0\0\0\0\0", 16) = 16 > read(5, "\1\2\0\1\6\0\0\0", 8) = 8 > read(5, "%\0\0\00011c0a80101000104169407000000"..., 48) = 48 > write(4, "\2\0\4\0002\0\0\0\0\10\0\0\0\0\10\0\1\30\v\0\1\0 \0032"..., 80) = 80 > read(4, "\20\272\n\0002\0\0\0\1\0 \3\0\0\0\0\20\0\20\0\0\0\0\0\0"..., 32) = 32 > read(4, "\1\325\v\0\0\0\0\0\361\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 > write(4, "\22\0\20\0\1\0 \3\361\0\0\0\37\0\0\0\10\30\v\0%\0\0\000"..., 88) = 88 > read(4, "\1\325\r\0\0\0\0\0\352\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 The way the application quits when the bug occurs is given by the end of the diff file : 267076,267079c311954,311957 < munmap(0x44ab9000, 274432) = 0 < close(20) = 0 < munmap(0x44a32000, 274432) = 0 < gettimeofday({1041694054, 87061}, NULL) = 0 --- > munmap(0x44a72000, 274432) = 0 > gettimeofday({1041694140, 507661}, NULL) = 0 > gettimeofday({1041694140, 512536}, NULL) = 0 > gettimeofday({1041694140, 513746}, NULL) = 0 267083c311961 < close(9) = 0 --- > close(10) = 0 267087,267089c311965,311967 < close(6) = 0 < gettimeofday({1041694054, 100060}, NULL) = 0 < gettimeofday({1041694054, 100431}, NULL) = 0 --- > close(7) = 0 > gettimeofday({1041694140, 589984}, NULL) = 0 > gettimeofday({1041694140, 590352}, NULL) = 0 267093,267096c311971,311974 < close(5) = 0 < kill(16038, SIGRTMIN) = 0 < kill(16038, SIGRTMIN) = 0 < gettimeofday({1041694054, 102937}, NULL) = 0 --- > close(6) = 0 > kill(16082, SIGRTMIN) = 0 > kill(16082, SIGRTMIN) = 0 > gettimeofday({1041694140, 592837}, NULL) = 0 267106,267108c311984,311986 < kill(16039, SIGRTMIN) = 0 < shutdown(10, 2 /* send and receive */) = 0 < close(10) = 0 --- > kill(16083, SIGRTMIN) = 0 > shutdown(11, 2 /* send and receive */) = 0 > close(11) = 0 267128,267129c312006,312007 < close(16) = 0 < close(19) = 0 --- > close(17) = 0 > close(20) = 0 And the end of the log file of the buggy behavior : 082, SIGRTMIN) = 0 kill(16082, SIGRTMIN) = 0 gettimeofday({1041694140, 592837}, NULL) = 0 access("/tmp", W_OK) = 0 socket(PF_UNIX, SOCK_STREAM, 0) = 5 fcntl64(5, F_GETFD) = 0 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 access("/tmp/OSL_PIPE_1003_SingleOfficeIPC_-1247862714", F_OK) = 0 connect(5, {sin_family=AF_UNIX, path="/tmp/OSL_PIPE_1003_SingleOfficeIPC_-1247862714"}, 110) = 0 send(5, "InternalIPC::TerminateThread", 28, 0) = 28 shutdown(5, 2 /* send and receive */) = 0 close(5) = 0 kill(16083, SIGRTMIN) = 0 shutdown(11, 2 /* send and receive */) = 0 close(11) = 0 unlink("/tmp/OSL_PIPE_1003_SingleOfficeIPC_-1247862714") = 0 rt_sigaction(SIGXFSZ, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGXCPU, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGVTALRM, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGIO, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGURG, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGWINCH, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGPWR, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGBUS, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGFPE, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGABRT, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGTRAP, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 close(17) = 0 close(20) = 0 _exit(0) = ? (I have a slow connection, so, posting the whole file is not possible) Find the ~/.ICEauthority as attachement. Another information of potential interest is that when the ~/.ICEauthority is present, (so, when the bug is here), the log file is bigger (about 2Mb more) each time. (For example, 19Mb the first time, then 22Mb, ...) I noticed that the only file modified in the ~/OpenOffice.org directory is the file ~/OpenOffice.org1.0/user/psprint/pspfontcache, which grows at each execution. (with diff -r) Hope this helps ! Matthieu
Created attachment 4205 [details] The .ICEauthority file causing the bug.
Additional note: I was using Gnome + Sawfish (Debian 3.0). After switching to fvwm with the same user, I can't reproduce the bug. On the other hand, if I create a new user and copy only the files ~/.sversionrc, ~/OpenOffice.org1.0 and ~/.ICEauthority on his account, with sawfish, the bug happens again. Thanks, Matthieu
os->pl: Can you please take care of this one.
by removing .ICEAuthority you disabled session management, which was the culprit (see issue 4494). *** This issue has been marked as a duplicate of 4494 ***
As mentioned on the qa dev list on March 5th I will close all resolved duplicate issues. Please see this posting for details. First step in IssueZilla is unfortunately to set them to verified.
As mentioned on the qa dev list on March 5th I will close all resolved duplicate issues. Please see this posting for details.