Summary: | app-office/openoffice-2.4.1 crash (sigseg) after exit on AMD64 in KDE 3.5.9 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Libor Bukata <lbukata> |
Component: | [OLD] KDE | Assignee: | Gentoo Office Team <office> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugs, nelchael, pva, spbecker |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Libor Bukata
2008-06-11 09:34:25 UTC
Same thing here. Anybody have any clues? Is there a possibility of me losing work because of this? (In reply to comment #2) > Anybody have any clues? Is there a possibility of me losing work because of > this? > If it's compiled with USE="-kde", then OpenOffice work fine also in KDE. The use flag kde is reason, why OpenOffice crash. It is _not_ the useflag, but rather the desktop integration. Exporting OOO_FORCE_DESKTOP="none" (or gnome) "solves" this problem, however, with none openoffice is ugly as hell, and many people simply don't want the gnome useflag when using KDE. Strace of the crash: close(17) = 0 munmap(0x7fd637058000, 4096) = 0 access("/home/fuchs/.qt/qtrc", F_OK) = 0 open("/home/fuchs/.qt/qtrc", O_RDONLY) = 18 fstat(18, {st_mode=S_IFREG|0644, st_size=1504, ...}) = 0 fstat(18, {st_mode=S_IFREG|0644, st_size=1504, ...}) = 0 fstat(18, {st_mode=S_IFREG|0644, st_size=1504, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd637058000 read(18, "[3.3]\nlibraryPath=/home/fuchs/.k"..., 4096) = 1504 fstat(18, {st_mode=S_IFREG|0644, st_size=1504, ...}) = 0 [more of those] fstat(18, {st_mode=S_IFREG|0644, st_size=1504, ...}) = 0 close(18) = 0 munmap(0x7fd637058000, 4096) = 0 fcntl(17, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0 close(17) = 0 rt_sigaction(SIGCHLD, {SIG_DFL}, NULL, 8) = 0 close(15) = 0 close(16) = 0 select(7, [6], [6], NULL, NULL) = 1 (out [6]) writev(6, [{"6\3\2\0\225\0@\3<\3\2\0f\0@\0036\3\2\0e\0@\3\n\3\2\0)\0@\3"..., 696}], 1) = 696 select(7, [6], [], NULL, NULL) = 1 (in [6]) read(6, "\22\0\352\7)\0@\3)\0@\3\0\0\0\0\320 L\2\0\0\0\0\274\260C\0\0\0\0\0"..., 4096) = 2912 read(6, 0x6b0fb4, 4096) = -1 EAGAIN (Resource temporarily unavailable) [more of those] read(6, 0x6b0fb4, 4096) = -1 EAGAIN (Resource temporarily unavailable) select(7, [6], [6], NULL, NULL) = 1 (out [6]) writev(6, [{"+\6\1\0", 4}], 1) = 4 select(7, [6], [], NULL, NULL) = 1 (in [6]) read(6, "\1\0014\10\0\0\0\0\16\0 \3\0\0\0\0\204\20}\0\0\0\0\0\260\241\23f\377\177\0\0", 4096) = 32 read(6, 0x6b0fb4, 4096) = -1 EAGAIN (Resource temporarily unavailable) select(7, [6], [6], NULL, NULL) = 1 (out [6]) writev(6, [{"\233\23\2\0r\0@\3\233\7\2\0o\0@\3\233\7\2\0p\0@\0036\7\2\0n\0@\3"..., 36}], 1) = 36 select(7, [6], [], NULL, NULL) = 1 (in [6]) read(6, "\1\0019\10\0\0\0\0\16\0 \3\0\0\0\0\204\20}\0\0\0\0\0\260\241\23f\377\177\0\0", 4096) = 32 read(6, 0x6b0fb4, 4096) = -1 EAGAIN (Resource temporarily unavailable) close(6) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- rt_sigaction(SIGALRM, {SIG_DFL}, {SIG_DFL}, 8) = 0 alarm(3) = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 close(3) = 0 close(4) = 0 close(5) = 0 close(6) = -1 EBADF (Bad file descriptor) close(7) = 0 close(8) = 0 close(9) = 0 close(10) = 0 close(11) = 0 close(12) = 0 close(13) = 0 close(14) = 0 [many many many more of those, counts up to 1023] close(1022) = -1 EBADF (Bad file descriptor) close(1023) = -1 EBADF (Bad file descriptor) write(2, "KCrash: Application \'soffice.bin"..., 46KCrash: Application 'soffice.bin' crashing... ) = 46 uname({sys="Linux", node="thinkfox", ...}) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_FILE, path="/home/fuchs/.kde/socket-thinkfox/kdeinit__0"}, 110) = 0 write(3, "\f\0\0\0\0\0\0\0\\\0\0\0\0\0\0\0", 16) = 16 write(3, "\t\0\0\0\0\0\0\0drkonqi\0-display\0:0.0\0--"..., 92) = 92 read(3, "\4\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0", 16) = 16 read(3, "\0211\0\0\0\0\0\0", 8) = 8 alarm(0) = 3 kill(12561, SIG_0) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [SEGV], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [SEGV], NULL, 8) = 0 nanosleep({1, 0}, XIO: fatal IO error 9 (Ungültiger Dateideskriptor) on X server ":0.0" after 82 requests (82 known processed) with 0 events remaining. 0x7fff3f088f40) = ? ERESTART_RESTARTBLOCK (To be restarted) emerge --info output can be added when needed, system is amd64 with a core2duo, sane C*-Flags, kde useflag enabled. Even if KDE related, OOo isn't maintained by the KDE team. A fix was done by the Debian team as this mornings openoffice 2.4.1-3 on Debian amd64 fixed that problem on my other machine. Hope someone here can add that to our Gentoo ebuild. (In reply to comment #6) > A fix was done by the Debian team as this mornings openoffice 2.4.1-3 on Debian > amd64 fixed that problem on my other machine. Hope someone here can add that to > our Gentoo ebuild. > For reference, the Debian bug is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485833 Also, they didn't really fix the bug...they just disabled randr support to work around it. Same here. Very similar problem I experience, at least oo seems to work with OOO_FORCE_DESKTOP="none". Strangest thing is that when I have file which when I open in oo-2.4.1 crashs every time I change layout, while it does not crash with other files... No problem here with KDE 3.5.9 and OOo 2.4.1 on ppc (PowerPC 32-bit) arch. USE="binfilter cups dbus firefox gstreamer java kde ldap opengl pam -debug -eds -gnome -gtk (-mono) -odk -seamonkey -xulrunner (-webdav%)" Seems to be affecting only x86 and amd64. Here's mine: $ emerge -vp openoffice These are the packages that would be merged, in order: [ebuild R ] app-office/openoffice-2.4.1 USE="cups dbus gtk java kde opengl pam -binfilter -debug -eds -firefox -gnome -gstreamer -ldap -mono -odk -seamonkey -xulrunner" LINGUAS="-af -ar -as_IN -be_BY -bg -bn -br -bs -ca -cs -cy -da -de -dz -el -en -en_GB -en_US -en_ZA -eo -es -et -fa -fi -fr -ga -gl -gu_IN -he -hi_IN -hr -hu -it -ja -km -ko -ku -lt -lv -mk -ml_IN -mr_IN -nb -ne -nl -nn -nr -ns -or_IN -pa_IN -pl -pt -pt_BR -ru -rw -sh -sk -sl -sr -ss -st -sv -sw_TZ -ta_IN -te_IN -tg -th -ti_ER -tn -tr -ts -uk -ur_IN -ve -vi -xh -zh_CN -zh_TW -zu" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB I've just (silently) bumped the patchset to ooo-build-2.4.1.6, which should solve this crasher. Please re-sync, rebuild and try again Thank you Andreas. Seems that it should at least that's what upstream told me: http://www.openoffice.org/issues/show_bug.cgi?id=90864 I'll test it today, but I suppose that this specific issue requires revision bump, so all users could avoid this crasher. What do you think? (In reply to comment #13) > Thank you Andreas. Seems that it should at least that's what upstream told me: > http://www.openoffice.org/issues/show_bug.cgi?id=90864 > I'll test it today, but I suppose that this specific issue requires revision > bump, so all users could avoid this crasher. What do you think? > I'm not too sure about a revision bump, because of the sheer size of OOo I normaly tend to avoid those ;) On the plus side everyone would get the fix, on the minus side a lot of users would have to recompile though they don't experience this problem at all. Also we would have to re-keyword a new revision for the 2.4.1 security bug... Tough choice... (In reply to comment #12) > I've just (silently) bumped the patchset to ooo-build-2.4.1.6, which should > solve this crasher. Please re-sync, rebuild and try again > Patch really solve that bug. Now I can confirm too that this bug is solved.
> (In reply to comment #13)
> I'm not too sure about a revision bump, because of the sheer size of OOo I
> normaly tend to avoid those ;) On the plus side everyone would get the fix, on
> the minus side a lot of users would have to recompile though they don't
> experience this problem at all. Also we would have to re-keyword a new revision
> for the 2.4.1 security bug... Tough choice...
Crashers like this, which are reproducible very well without any specific
actions should have their revision bump in any case. I've noticed users having
such issue everywhere: this was asked on -dev IRC channel, this was discussed
in forums, people asked me privately in jabber.
BTW, more generally my opinion is that any such patchset upgrade requires
revision bumps for the following reasons:
1. Fixes which upstream considered important will be at users systems
2. This will reduce number of bug reports for already fixed issues at upsteam
OO
3. Currently it is unknown if user have fixed or known to be broken version of
OO
And last point: I think that taking into account compilation times is not good
idea as thouse who bother should use binary package.
Crash long fixed, OOo 3.0 in the tree, closing |