Issue 62088 - Base crashes when closing form after closing Writer document.
Summary: Base crashes when closing form after closing Writer document.
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOo 2.0.2
Hardware: PC All
: P1 (highest) Trivial (vote)
Target Milestone: OOo 2.0.2
Assignee: marc.neumann
QA Contact: issues@dba
Keywords: regression
Depends on:
Blocks: 61850 62201
  Show dependency tree
Reported: 2006-02-15 13:31 UTC by yossy_takeuchi
Modified: 2006-05-31 14:29 UTC (History)
5 users (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description yossy_takeuchi 2006-02-15 13:31:56 UTC
Base crashes when closing form after closing Writer document.

The reappearance procedure:
1. Open Base file (.odb)
2. Open Form of Base.
3. Open Writer document (Ex. .odt)
4. Close opened Writer document.
5. Close Form of Base.

Result: Base is crashed.
Comment 1 yossy_takeuchi 2006-02-15 13:32:45 UTC
Added keyword "regression".
Comment 2 yossy_takeuchi 2006-02-15 13:39:53 UTC
Please add as the dependence on issue 61850.
Comment 3 Frank Schönheit 2006-02-15 13:50:59 UTC
confirming, grabbing, targeting.
Comment 4 Frank Schönheit 2006-02-15 13:54:01 UTC
Comment 5 yossy_takeuchi 2006-02-15 13:54:29 UTC
Does this problem have the relation of issue 59272?
Comment 6 Frank Schönheit 2006-02-15 14:10:31 UTC
Might be that the fix for issue 59272 caused this bug here, yes.

Why did you reset the target?
Comment 7 yossy_takeuchi 2006-02-15 14:17:20 UTC

When adding the comments, target milestone will be "none".

Setted target milestone "2.0.2"
Comment 8 Frank Schönheit 2006-02-15 14:21:35 UTC
does OOo really crash for you? For me, it "kind of" crashs, in that it simply
stops responding and freezes. Didn't get the crash reporter at all ...
Comment 9 yossy_takeuchi 2006-02-15 14:39:28 UTC
Another problem seems to occur.

It crashes when closing the "[X]" button 
in the upper right of the form window.

In the method "file -> close" of menu, 
it is possible to close normally.

I want to close this issue 
and wants to publish issue newly.
Comment 10 Frank Schönheit 2006-02-15 14:46:54 UTC
why close? it's still a valid descripton of a serious bug ...
Comment 11 yossy_takeuchi 2006-02-15 15:07:30 UTC
Because this problem occurs in the condition 
not opening Writer document.

I want to rewrite summary:
"Base crashes when clicking close button [X] of form window."

The reappearance procedure:
1. Open Base file (.odb)
2. Open Form of Base.
3. Click the "[X]" button in the upper right of the form window.

Result: Base is crashed.

Comment 12 Frank Schönheit 2006-02-15 15:09:32 UTC
fs->as: When the second document is about to be closed, the respective frame
freezes when it tries to dispose itself. That is, nearly the complete "close"
process finished successfully, but in Frame::dispose, called from Frame::close,
the line
  m_aTransactionManager.setWorkingMode( E_BEFORECLOSE );
blocks infinitely.
Comment 13 Frank Schönheit 2006-02-15 15:17:24 UTC
Hmm, I would think that speaking strictly, this is not necessary, but I will not
hinder you :)

In case you decide to submit a new issue, please
- assign it to AS
- target it to 2.0.2
- CC me (fs)
- refer to this issue here so AS can read the investigations I did so far
- add the dependency to issue 61850.

Comment 14 yossy_takeuchi 2006-02-15 15:43:43 UTC
I'll not publish new issue.
Please resolve this.


It is passing zero thirty a.m.(JST). I want to sleep. :)
Comment 15 2006-02-15 16:06:29 UTC
Reproducible under GNU/Linux ( with RC1

Base also crashes when closing a newly created form thru the windowmanager controls.
Comment 16 Mechtilde 2006-02-15 16:07:08 UTC
I can commit this bug in RC 1 of OOo 2.0.2

It freeze also if I only open and close a form of a base dokument
Comment 17 Martin Hollmichel 2006-02-16 11:44:35 UTC
raise prio.
Comment 18 andreas.schluens 2006-02-16 12:10:26 UTC
The problem behind:
Closing any resource inside OOo isnt an easy job always. Often enoughh we make 
it asynchronous. E.g. our menus had problems on synchronous closing frames ... 
our our test tool had problems on terminating the office synchronous.

Normaly the dispatch ".uno:closeFrame" used here is implemented asynchronous. 
Internaly it calls ((XClosable)xFrame)->close().

But now two dispatch  interceptor objects are involved. And one of them calls 
close() synchronous. But this will close the same frame which stands on the same 
stack (some levels above) in another interface method windowClosing().

That's the reason why this frame blocks the whole thread. It waits for finishing this 
API call. I've implemented it a little bit more gracefully. Because the intention of 
windowClosing() is clear. So windowClosing can supress setting this lock ... and 
Frame->close() will work.

BUT: Now it depends from all implementations available on the same stack. If only 
one of these methods make a call after close() it can lead in potential crash.
The current version of OOb680 does not have a problem. But every added line to 
the involved code can break this ! Be warned .-)
Comment 19 uwe.luebbers 2006-02-16 12:55:05 UTC
Looks good with libraries from AS, tested on Win32.
Comment 20 andreas.schluens 2006-02-16 13:53:00 UTC
Only to clarify: The office does not crashes ... it freeze (means: do not respond 
forever). If you kill it using system tools you will get the recovery dialog next time 
you start the office. Becuase there is feature inside OOo: recovery opened 
documents even after the system was shitdown unexpectly (e.g. by a power 
outage) .-)

It's not a crash - it's a freezed office process.
Comment 21 yossy_takeuchi 2006-02-17 15:31:36 UTC
Also, OOo freezes when clicking close button [X] of "base report".
This is the problem to be the same?

Comment 22 yossy_takeuchi 2006-02-21 00:44:41 UTC
I confirmed that this problem was corrected in
- OOo_2.0.2rc2_060220_LinuxIntel_install_ja_wJRE.tar.gz
- OOo_2.0.2rc2_060220_Win32Intel_install_ja_wJRE.exe

Also, closing of BASE Report is no-problem.

Comment 23 andreas.schluens 2006-02-22 09:53:32 UTC
AS->MSC: Please verify thi stask on our actual master builds. THX.

re-open issue and reassign to
Comment 24 andreas.schluens 2006-02-22 09:53:40 UTC
reassign to
Comment 25 andreas.schluens 2006-02-22 09:53:44 UTC
reset resolution to FIXED
Comment 26 marc.neumann 2006-02-22 12:11:08 UTC
yossy_takeuchi told that this issue is fixed in the master.
Comment 27 marc.neumann 2006-02-22 12:59:25 UTC