Issue 62088

Added keyword "regression".

Please add as the dependence on issue 61850.

confirming, grabbing, targeting.

accepting

Does this problem have the relation of issue 59272?

Might be that the fix for issue 59272 caused this bug here, yes.

Why did you reset the target?

Sorry. 

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

Setted target milestone "2.0.2"

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 ...

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.

why close? it's still a valid descripton of a serious bug ...

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.

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.

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.

Thanks.

I'll not publish new issue.
Please resolve this.

Thanks.

p.s.
It is passing zero thirty a.m.(JST). I want to sleep. :)

Reproducible under GNU/Linux (2.6.15.1) with RC1

Base also crashes when closing a newly created form thru the windowmanager controls.

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

raise prio.

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 .-)

Looks good with libraries from AS, tested on Win32.

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.

Also, OOo freezes when clicking close button [X] of "base report".
This is the problem to be the same?

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.

AS->MSC: Please verify thi stask on our actual master builds. THX.

re-open issue and reassign to msc@openoffice.org

reassign to msc@openoffice.org

reset resolution to FIXED

yossy_takeuchi told that this issue is fixed in the master.

close