Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Base crashes when closing form after closing Writer document.|
|Status:||CLOSED FIXED||QA Contact:||issues@dba <issues>|
|Priority:||P1 (highest)||CC:||frank.schoenheit, issues, khirano, mechtilde, pavel|
|Target Milestone:||OOo 2.0.2|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
|Issue Blocks:||61850, 62201|
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 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
Sorry. 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. Thanks.
Comment 14 yossy_takeuchi 2006-02-15 15:43:43 UTC
I'll not publish new issue. Please resolve this. Thanks. p.s. It is passing zero thirty a.m.(JST). I want to sleep. :)
Comment 15 p9w.vu.31122010 2006-02-15 16:06:29 UTC
Reproducible under GNU/Linux (22.214.171.124) 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
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 email@example.com
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