Issue 62482 - Large files cause force quit popup on close
Summary: Large files cause force quit popup on close
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 2.0.2
Hardware: All All
: P3 Trivial (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-02-23 15:06 UTC by grsingleton
Modified: 2017-05-20 11:31 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Popup that seems unnecessary (14.82 KB, image/png)
2006-03-07 14:28 UTC, grsingleton
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description grsingleton 2006-02-23 15:06:51 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
Comment 1 grsingleton 2006-03-07 14:28:05 UTC
Created attachment 34635 [details]
Popup that seems unnecessary
Comment 2 thorsten.martens 2006-03-28 14:43:06 UTC
TM->MAV: Please have a look at this one. I wasn´t able to reproduce it on WinXP.
Comment 3 grsingleton 2006-03-28 15:08:31 UTC
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:
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


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



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. 
Comment 4 mikhail.voytenko 2006-05-23 11:18:47 UTC
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.
Comment 5 philipp.lohmann 2006-05-23 11:45:21 UTC
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.
Comment 6 mikhail.voytenko 2006-05-23 12:56:08 UTC
Changing the target accordingly.
Comment 7 Marcus 2017-05-20 11:31:12 UTC
Reset assigne to the default "".