Apache OpenOffice (AOO) Bugzilla – Issue 62482
Large files cause force quit popup on close
Last modified: 2017-05-20 11:31:12 UTC
I work with the user guide as one large file. Upon closing, I get a popup saying that OOo is not responding and offers force quit or cancel. I have discovered that cancel permits continuation of the close but the popup is annoying and suggests to me there is a timing problem. If you need a large test file, use the latest attachment on issue 29679
Created attachment 34635 [details] Popup that seems unnecessary
TM->MAV: Please have a look at this one. I wasn´t able to reproduce it on WinXP.
To make things a bit clearer, this occurs mostly on my primary machine when the manual is left idle long enough for OOo to be swapped out. Here are the particulars for this box: MEMORY: MemTotal: 775632 kB MemFree: 15440 kB Buffers: 53052 kB Cached: 144916 kB SwapCached: 191672 kB Active: 629716 kB Inactive: 60380 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 775632 kB LowFree: 15440 kB SwapTotal: 17093112 kB SwapFree: 16223340 kB Dirty: 356 kB Writeback: 0 kB Mapped: 534824 kB Slab: 42176 kB CommitLimit: 17480928 kB Committed_AS: 2939172 kB PageTables: 8000 kB VmallocTotal: 245752 kB VmallocUsed: 14128 kB VmallocChunk: 229908 kB CPU: processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.40GHz stepping : 4 cpu MHz : 2399.869 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips : 4804.09 WINDOW SYSTEM: Gnome OS: Linux www do pathtech dot org 2.6.15-1.1833_FC4 #1 Wed Mar 1 23:41:37 EST 2006 i686 i686 i386 GNU/Linux Not surprized about XP as it is inherently a single user system and is thus less like to swap outwith the qs active. Hope this helps.
The problem might be that the internal frame-close mechanics is asynchronous. AS has mentioned that this is required by VCL, so that the window that triggers the closing does not die while it is still on the stack. And the Gnome, probably, expects synchronous closing. MAV->PL: Could you please take a look. If the suspection is correct, the solution could be a simulation of synchronous call by "yielding" in the event handling of the window.
pl->mav: pretty much nothing in X11 is synchronous. Depending on what scenario we're looking at this is what happens: - User presses the close button on the window - This causes the window manager to send a close request to OOo which will normally cause OOo to close the window (possibly after requesting whether to save changes - The window manager can run into a timeout during that time and assume that the process is hung Alternatively the session manager scenario: - User logs out - session manager tells OOo to save its session - OOo answers after documents are saved - session manager tells OOo to shut down - OOo does that - here the session manager can run into timeout during waiting for the answer that the session was saved. From the description I'd say that the first scenario is probably what hits here, especially since the system is swapping which would let the timeout elapse more often since the waiting process can only measure wall clock time. To make this less likely we would have to close the document faster, i just don't see any immediate way to do that. Furthermore this is not really in the scope of gsl.
Changing the target accordingly.
Reset assigne to the default "issues@openoffice.apache.org".