Apache OpenOffice (AOO) Bugzilla – Issue 16082
OO writer hangs, becomes very slow, timeout after first letter, space, return
Last modified: 2004-03-21 20:34:40 UTC
OpenOffice 1.1beta(1,2) hangs for several seconds when typing a key on the keyboard. There seems to be a timeout every time after typing a space, the first letter of a new word, or the return and backspace key. E.g.: T*he *L*azy *F*ox *J*umps *O*ver The timeout is between 2-4 seconds for each key, and thus makes using Writer impossible. It's a full GUI hangup, but without using any cpu (timeout, blocking socket, sleep?). It also occurs when opening new documents (hangup 4 seconds, bit disk reading, another hangup, bit more reading, etc) Loopback device is working, disk space available, default installation without changing any settings. I have tried with autoformat and dictionary off, assuming some slowdown or timeout there, but that didn't help. The other OO components have not shown this symptoms so far. strace just shows a 'sleeping' loop, although I am typing continuously. time(NULL) = 1056566578 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 nanosleep({0, 200000000}, NULL) = 0 sched_yield() = 0 time(NULL) = 1056566578 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 nanosleep({0, 200000000}, NULL) = 0 sched_yield() = 0 time(NULL) = 1056566578 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 nanosleep({0, 200000000}, NULL) = 0 sched_yield() = 0 time(NULL) = 1056566578 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 nanosleep({0, 200000000}, NULL) = 0 sched_yield() = 0 time(NULL) = 1056566578 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 nanosleep({0, 200000000}, NULL) = 0 kill(1504, SIGRT_0) = 0 sched_yield() = 0 time(NULL) = 1056566579 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 ioctl(13, FIONREAD, [0]) = 0 nanosleep({0, 200000000}, NULL) = 0 sched_yield() = 0 time(NULL) = 1056566579
This is still an issue in OpenOffice 1.1.0rc3, and makes using OpenOffice Writer impossible (unless you like to work in extreme slowmotion). Some more info: linux kernel 2.4.22 glibc 2.2.3 j2re1.4.2 The strange thing is that the computer is completely idle when hanging, openoffice must be having a delay or timeout, or waiting for an interrupt of some kind. System is not loaded, openoffice is not doing anything, just waiting and blocking for a few seconds, over and over.
jw: reassigend to jw
jw: could not reproduce on OOo1.1 RC3 on suse linux 8.2 and on windowsXP please try to reinstall the office! do you have this problem on another pc too?
jw:changed prio to p3
I have only seen this on the system described above. I have installed, reinstalled, deleted, manually erased etc all files related to openoffice releases, so it has nothing to do with program- or configuration files that were left over from previous installs. Since OpenOffice really hangs, as seen when tracing, and I never had/have this problem with other programs or versions of OpenOffice before 1.1(rc, pre), and I've tried many clean installs, I think this is a OpenOffice bug. It surprises me that this hasn't surfaced before on mailing lists or in the bugzilla (unless it's related to the scheduling bug). I wouldn't know anything that could cause such delays. I can only think of locking, resolving or scheduling problems in the code, but I fail to see why they would occur on my system only. Is there something that resolves, connects or locks while typing? Something that could have a timeout of 3-4 seconds with half of the keypresses (it sleeps only on (back)spaces, deletes and the first letter of words).
JA->Wouter: This is strange and not reproducible here... Please provide more information about your system: Is it a vanilla kernel from kernel.org or is it a distribution specific one ? (eg. RedHat included new posix threading from 2.6 kernel versions into the 2.4.? tree in RH9 and SuSE's kernel is not vanilla as well) Is there a problem with network resolution on your system ? I would probably check /etc/nsswitch.conf if the order of the services is correct. OpenOffice.org uses the system call gethostbyname() for some internal functions and in this case I could imagine that your kind of problem might exist on machines which have a misconfigured networking...
It's a vanilla kernel, no patches, no modules. Version 2.4.20 or so since 1.1beta1, to 2.4.22 with 1.1rc3 now. Nothing special included, except generic SCSI for cdwriter, and ipv6 networking. There are no problems with network (static intranet ip) or resolving, or the loopback interface. Hosts, host.conf, resolv.conf, nsswitch.conf, you name it, it should all be fine (hasn't change in a year). It's a PIII 866mhz, not the fastest machine, but not slow either. There have been two or three occasions I didn't have the problem (e.g. accidently yesterday), and I've been trying to track down what is different, but I don't have any clue. Diskspace available (both in /home and /tmp), memory available, swap available, system load pretty much zero, no changes in network whatsoever (no change in system configuration for over a year). I know I have the problem when I open openoffice, and it takes ten seconds to click file->new->textdocument because the menu hangs for about 3 seconds on every action. Usually I close openoffice then, since it's quite unusable in that state. Once again, it only happens with the first letter of words, spaces, backspaces and returns, and menu clicks, too. What is similar in the first letter of a word, backspace, or a menu click, that consecutive letters don't have? A redraw? Reflowing? Scheduling? Widget focussing? In the trace above, I was typing, but openoffice only reads my keys once every 2-4 seconds, and sleeps completely in between. Very strange indeed.
Not reproducible here either. Strange is that: > The other OO components have not shown this symptoms so far. Why should writer be different? Maybe this > [...] and ipv6 networking. is important? What version of X (and which driver) are you using and which windowmanager? (just guessing)
XFree86 Version 4.1.0 / X Window System, build in "nv" driver for a Riva TNT2. Not new hardware, it has been working fine for years in this configuration. WindowManager is Enlightenment 0.16.5, which I also have been running for years. This machine has been running IPv6, you guessed it, for several years without a problem. I don't exclude the possibility of something timing out inside OpenOffice, but that's what I was hoping some of you people would know - I don't have a clue what is happening between keystrokes. I just tried to create a presentation, nothing hangs there - menu's and typing, it's all pretty smooth. Only Writer hangs while typing (~3 seconds per first letter, space, enter or delete), and while creating a new document (File > New > Text Document), a full 10 seconds with the computer completely idle and the whole OO interface frozen (not doing anything at all). Is there anybody who would know about blocking actions, delays or timeouts in that part of the code (creating a new document, typing)?
just in case it means something to you... when i searched issues for that signal 32 SIGRT_0 i got just 3 issues - this one plus 4468 and 2090. Those others relate to crash when starting, something about loading fonts. all get SIGRT_0 in the strace.
Please try using the latest OpenOffice 1.1 Final , you can download it from www.openoffice.org many bug fixes and enhancements since your version and 1.1 Final . If the problem still happend in 1.1 please report back
added keyword needmoreinfo
Wouter: We need more information from you as we have not been able to reproduce the bug you reported. Please download the latest release and advise if behavior is still present. If we cannot confirm and hear nothing further from you, we will need to close the issue. Thanks, Tam
.
I'm getting this also, a lot, with precisely same symptoms as the original reporter. It started when I had been working on a fairly simple document for about an hour. I shut down OO, restarted loading the same document, and the slowness was still there. I resized the window, typed a little, closed OO, restarted loading the same document again, and it was gone. I've hit the same bug with some of the 1.1rc's (don't remember which), but then the bug wouldn't stop occurring with the document I was working on, and I had to discard the document. I don't have the exact strace in front of me anymore, but mine too showed it looping with ioctl(..., FIONREAD, ...), nanosleep() and kill(). This is with Finnish OO 1.1.0 final on RHL 9 with fairly vanilla 2.4.22 kernel, RH's glibc 2.3.2 and jre 2.4.2. Any other info that would be useful if the bug occurs again?
Tam: I simply can't give you more info, since it doesn't crash. What kind of info did you have in mind? What sets typing a space or first letter apart from typing the other letters in a word? That something must also appear in redrawing the interface. It *never* hangs on other characters than the first in a word, a space between words, return or backspace, so there must be a slightly different code path that is followed in these cases. Maybe a full GUI redraw? Something is not timed right, or timing out. It feels like using an editor with *very* slow syntax coloring, except the whole GUI is unresponsive too. But when you're typing inside a word, everything is perfectly fast and acceptable. Typing a whole document without spaces, breaks or backspaces - or without using the GUI's menu's - is obviously not really an option. There really is no way I can even guess when the problem will occur or what will trigger it. Sometimes it happens even when opening OO with no document loaded, sometimes it doesn't. OO 1.1 is better than 1.0.3, 1.0.4 and the rc's in this respect though, it seems to happen less often. Nevertheless, the problem is real, I'm quite sure it has nothing to do with my system's load or resources; and all OO's old configuration files have been removed too, so the problem can't be there either. The only thing I can think of that could be a difference with other systems, is that I have an IPv6 network (for years, without changes)... But I can't see how this would time out pretty much each and every GUI operation on some days and not on others, without any change to configuration. I just remember it because there used to be some bug with OO and the loopback interface, but I don't think this is related.
OOo1.1.1 final will be released in a view days. please install this version and tell us if the errer still occurs. don't update or install in the same directory. regards jw hope it solves it. because we are not able to reproduce this here and bacause of this can not make further investigations what the error might come from
i will close this here now, feel free to reopen this issue if you can make this bug reproducible for me. as far as we can not reproduce this here i need sombody from the community to make this reproducible and confirmable. closed as wfm
closing
I'm still getting this with Finnish OOo 1.1.0. When I open certain document, the UI gets updated only about once per 3 seconds, the rest of the time it's completely frozen. During the freezes, I took four stack traces with gdb, which are attached. Vanilla 2.4.25 kernel, RH9 on Celeron.
Created attachment 13963 [details] Stack traces while OOo UI is frozen
Created attachment 13964 [details] I open this file, move the cursor around and see the freezings repeatably.