Description: Using LibreOffice Writer version 7.0.5.2 x64 when opened through API on Sybase PowerBuilder the document that was opened cannot be closed. Closing using File->Close doesn't work. Closing using X Button also doesn't work. This problem doesn't happen on LibreOffice version 6.3.5.2 x64 release. NOTE: I inform that the version dropdown here in bugzilla doesn't list 7.0.5.2 release. Because of that I selected 7.0.4.2 release but my version is 7.0.5.2 release. Version: 7.0.5.2 (x64) Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: pt-PT (pt_PT); Interface: pt-PT Calc: threaded Steps to Reproduce: 1.Using API with Sybase Powerbuilder open a document on LibreOffice Writer. 2.Close the document using File->Close 3.Close the document using X Button of the window Actual Results: 1.Closing on File->Close doesn't close the document 2.Closing on X Button of the window doesn't close the document. Expected Results: Should close the document. Reproducible: Always User Profile Reset: No Additional Info: I've monitored this LibreOffice behavior using Procdump v10.0. See the attached image for more information. Also attached goes the actual dump that is created by Procdump. This problem doesn't happen on LibreOffice version 6.3.5.2 x64 release.
Created attachment 170547 [details] Exceptions shown on Procdump using File->Close or X Button Exceptions shown on Procdump using File->Close or X Button
Created attachment 170548 [details] Dump created by the monitoring done with Procdump Dump created by the monitoring done with Procdump
The behavior is reproducible invoking LibreOffice 7.0.5.2 through API using Sybase Powerbuilder IDE or invoking LibreOffice 7.0.5.2 through API using the executable version of the deployed application. The exceptions thrown are these: Exception: E06D7363.?AVTerminationVetoException@frame@star@sun@com@@ Exception: 406D1388 As mentioned before LibreOffice 6.3.5.2 doesn't has this behavior.
I suppose someone on Windows could use the procdump. For those on Linux perhaps a backtrace retried with Windbg could help: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows:_How_to_get_a_backtrace About TerminationVetoException, I found this: 31 If a XTerminateListener use this exception for a veto against 32 the termination of the office, he will be the new "owner" of it. 33 After his own operation will be finished, he MUST try to terminate the 34 office again. Any other veto listener can intercept that again or office 35 will die really. 36 37 Since LibreOffice 5.3: 38 Throwing this exception will only prevent *termination*. 39 Exiting LibreOffice will close all the windows, but the process will keep running. See https://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/frame/TerminationVetoException.idl?r=6d9f07d5 You can give a try at https://wiki.documentfoundation.org/QA/FirstSteps just to exclude corruption LO profile and skia parts.
Hi Julien Nabet. Thanks for the feedback. My understanding of the information you sent is that the process that invokes LO through API becomes the only one that can actually terminate LO. Was this an intended change? What is the use case that was needed to be met? Is there any more detail about the changes that originates this current behavior? --> Opening LO through API, import data into LO using it's API, and then user interacts with LO's GUI and eventually close LO through it's GUI in my opinion is a very frequent use case. Best Regards.
"You can give a try at https://wiki.documentfoundation.org/QA/FirstSteps just to exclude corruption LO profile and skia parts." Regarding this advice I did a reset of the user profile, some things changed about Skia, now is Vulkan, before was Raster. I also disabled extensions. Nevertheless the behavior that was described in this bug is unchanged. It's not possible to close LO by it's GUI when LO is opened through it's API. Best Regards
This bug is also present on 7.1.2.1 version. Information: Version: 7.1.2.1 (x64) / LibreOffice Community Build ID: 094b4116e8de6d2085e9b65d26912d6eac4c74a9 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: pt-PT (pt_PT); UI: pt-PT Calc: threaded Best regards
(In reply to Julien Nabet from comment #4) > I suppose someone on Windows could use the procdump. > For those on Linux perhaps a backtrace retried with Windbg could help: > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows: > _How_to_get_a_backtrace > > About TerminationVetoException, I found this: > 31 If a XTerminateListener use this exception for a veto against > 32 the termination of the office, he will be the new "owner" of it. > 33 After his own operation will be finished, he MUST try to > terminate the > 34 office again. Any other veto listener can intercept that again > or office > 35 will die really. > 36 > 37 Since LibreOffice 5.3: > 38 Throwing this exception will only prevent *termination*. > 39 Exiting LibreOffice will close all the windows, but the process > will keep running. > See > https://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/frame/ > TerminationVetoException.idl?r=6d9f07d5 > > You can give a try at https://wiki.documentfoundation.org/QA/FirstSteps just > to exclude corruption LO profile and skia parts. Hi Julien Nabet, I recorded a backtrace with WinDBG. Attached to this bug you will find a image with some written notes about what happened at every specific point in time and the backtrace file. I think the Exception Analysis on the file will be useless because I think WinDBG analysed the break o soffice.bin on WinDBG because the reported bug doesn't crash LO and killing the soffice.bin process on task manager wouldn't make possible a !analyze -v execution. Maybe I've done something wrong about the backtrace. Feel free to suggest something. I think looking to the notes on the image might be more interesting. Best regards
Created attachment 170806 [details] Backtrace_LO_7.1.2.1_x64_windbg_x64
Created attachment 170807 [details] LO_backtrace_notes
similar problems in: Bug 139023 - LO 7.0.4 cannot be terminated on win2012 in terminal server mode sometimes Bug 140737 - Writer: Can not close the program window
(In reply to kabilo from comment #11) > similar problems in: > Bug 139023 - LO 7.0.4 cannot be terminated on win2012 in terminal server > mode sometimes > Bug 140737 - Writer: Can not close the program window Thanks kabilo. Replied on both bugs with questions and instructions to follow to further analyse the bugs that Knecker and you are having. For me, my bug and yours are the same. Best regards
Hi, I compared the code of 7.1.2.2 vs 6.3.5.2 on the following file libreoffice-7.1.2.2\extensions\source\ole\unoobjw.cxx libreoffice-6.3.5.2\extensions\source\ole\unoobjw.cxx And I see that: 1- there are some new includes on 7.1.2.2: #include <com/sun/star/frame/TerminationVetoException.hpp> #include <com/sun/star/frame/XTerminateListener.hpp> 2- this comment on line 105 explains the reported bug: // Always veto termination while an OLE object is active, except if it is an OLE object that // has asked us to quit. This implementation of veto regarding OLE object is completely biased because you assume that the interaction will be completely done through OLE object, eg, create/open a odt/ott minimized or invisible, import data, save, close. When in most use cases the OLE object will be used as well to create/open a odt/ott, import data, turn document visible, permit user interaction and then save on GUI and close by user interaction. My suggestion is make this Veto behavior an option on the API or on LO's GUI. Or, using other words, the veto that is being currently forced should be optional when using OLE object. By default the new suggested option can implement this Veto behavior and I will change on my side to permit user interaction to close on GUI. If there is already an UNO function regarding this suggestion please send me the link for me to read. PS: Maybe there is more code related to this bug on other code files. This comparison that I made of unoobjw.cxx file appeared like the most relevant to me. Best regards
*** Bug 141513 has been marked as a duplicate of this bug. ***
In bug 141513, Advantage Database is in use with API
(In reply to Buovjaga from comment #15) > In bug 141513, Advantage Database is in use with API Since that code that I analysed on https://bugs.documentfoundation.org/show_bug.cgi?id=141097#c13 was made all LO opened through API breaks closing on GUI so I'm not surprised by the existence of several bugs that are reported regarding this precise issue.
Removed keyword wantBacktrace. Backtrace was given on 2021-03-29. For what I see this bug is more than confirmed, it already has a duplicate, so I'm very disappointed that isn't being given the proper attention to this issue. The usage of LO API to generate a document and turn document visible is only done by 3 or 4 people worldwide?! Best Regards
I have this same problem that I would like to see solved. When is it resolved by the LibreOffice team?
@Makrea, I am not very familiar with OLE or LO's interaction with it, so please forgive if I am asking a bad question. However, in the comment you quoted, the words "is active" stood out to me: // Always veto termination while an OLE object is active In the use case you provide, it sounds like you don't need to interact with OLE any more once the document is open. Is there any way you can de-activate or end the OLE session at that point?
(In reply to Michael Warner from comment #19) > @Makrea, I am not very familiar with OLE or LO's interaction with it, so > please forgive if I am asking a bad question. However, in the comment you > quoted, the words "is active" stood out to me: > > // Always veto termination while an OLE object is active > > In the use case you provide, it sounds like you don't need to interact with > OLE any more once the document is open. Is there any way you can de-activate > or end the OLE session at that point? Hi Michael Warner, > please forgive if I am asking a bad question Feel free to ask all questions. I'm more than available to see this issue solved once and for all. > In the use case you provide, it sounds like you don't need to interact with > OLE any more once the document is open. That's true most of the times. I'll give you some real world examples where that's not 100% true. Say you have a template and you need to insert text and bookmarks. On this occasion the OLE object that links to the LibreOffice instance will be used by means of UI and at a lower layer invokes API calls to LibreOffice. To be more specific say a UI window that you double click to set a specific bookmark on a template at a specific insertion point. Say now that the user wants to close and save the template. It can save but cannot close the template document because of the veto limitation that was inserted. I asked on comment 5 what was the use case that needed to be met that caused this change. All I got was silence.... This is only one example I can give. Another example is: Say a Calc sheet and data is exported to cells. The user can't close the sheet after export. You will excuse me the sentence but here it goes. This veto implementation was poorly designed and collides with all real word use cases that involves user interaction. >Is there any way you can de-activate > or end the OLE session at that point? Maybe. But I feel that isn't a straightforward (point in time) action to be made because of user unpredictability . I don't investigated that because my opinion is that this veto exception error originates from a 100% wrong approach to API LibreOffice usage. Please see that, as it stands now, it completely disregards the possibility of real world user interaction with Libreoffice close by UI. Legitimate real world user actions. So our course of action was all instances didn't update and this bug link was made publicly known to all users that updated, reported this issue, and then had to go back to a previous LibreOffice version. I think I will give your question back to you. On comment 13 (3 months ago) I already went somewhat on that course. >By default the new suggested option can implement this Veto behavior and I >will change on my side to permit user interaction to close on GUI. >If there is already an UNO function regarding this suggestion please send >me the link for me to read. So, is there any way you can de-activate or end the OLE session at that point? Best regards.
Thanks to Makrea's work in Comment 13, I can see that the VetoTermination code was added in this commit: commit 89f883bd90a50587868a57397b6350ed9559a20f Author: Tor Lillqvist <tml@collabora.com> Date: Mon Jun 10 15:41:28 2019 +0300 Veto process exit while an OLE client is connected Change-Id: Iad9fc1742ae371a8a162edbc16998e9cb6895919 Reviewed-on: https://gerrit.libreoffice.org/73763 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Then, modified here: commit 05e03911cd1f8a355b6410d3997cffc2c794a1e9 Author: Tor Lillqvist <tml@collabora.com> Date: Wed Aug 21 11:57:28 2019 +0300 @Tor, do you have any advice here?
As far as I know the functionality my change was for is not needed any more, so if it is of benefit to revert it, be my guest.
I would like to thank Michael Warner and Tor Lillqvist for your input. If you create a test build I can further validate it for you. (I analysed the link you posted and it seems like it's the only files to be reverted.) I would also like to thank kabilo for making the effort to find other similar and apparently related bugs that ultimately had the effect to strengthen this bug I posted. Best regards.
[Automated Action] NeedInfo-To-Unconfirmed
Just to follow up in BZ as well, I submitted a patch for this last week here: https://gerrit.libreoffice.org/c/core/+/118596 It's just waiting for review now.
(In reply to Michael Warner from comment #25) > Just to follow up in BZ as well, I submitted a patch for this last week here: > https://gerrit.libreoffice.org/c/core/+/118596 > > It's just waiting for review now. Thanks for the feedback Michael! Best regards.
*** Bug 143966 has been marked as a duplicate of this bug. ***
Michael Warner committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/080e4550257a90597c241f83fd766b99c83ba6e8 tdf#141097 Revert "Veto process exit while an OLE client is connected" It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Just for the record, I pushed the commit so people may give it a try once a daily build will be available with the patch.
Hi Julien Nabet. I will try the fix on the daily build and give feedback here. Thanks!
(In reply to Makrea from comment #30) > Hi Julien Nabet. > > I will try the fix on the daily build and give feedback here. > > Thanks! I just pushed the patch, the one to thank is Michael Warner! :-)
(In reply to Julien Nabet from comment #29) > Just for the record, I pushed the commit so people may give it a try once a > daily build will be available with the patch. Hi Julien, I'm wondering, should it be backported to 7.2 branch ?
(In reply to Xisco Faulí from comment #32) > (In reply to Julien Nabet from comment #29) > > Just for the record, I pushed the commit so people may give it a try once a > > daily build will be available with the patch. > > Hi Julien, > I'm wondering, should it be backported to 7.2 branch ? I think it could be useful indeed but perhaps we should wait a confirmation it works well from Makrea ?
(In reply to Julien Nabet from comment #33) > (In reply to Xisco Faulí from comment #32) > > (In reply to Julien Nabet from comment #29) > > > Just for the record, I pushed the commit so people may give it a try once a > > > daily build will be available with the patch. > > > > Hi Julien, > > I'm wondering, should it be backported to 7.2 branch ? > I think it could be useful indeed but perhaps we should wait a confirmation > it works well from Makrea ? Hi, Wait a confirmation from me and maybe kabilo as well (if he is available to validate his use cases obviously). Nevertheless i will update here with the results I get. PS: A backport to the 7.2 branch would be welcome if you see that it does not collide with anything else. Best regards.
Hi, It's impossible to tell if its solved because i'm unable to test properly. The alpha DEV version doesn't behave like a normal LibreOffice release executable. I uninstalled, on purpose, the 6.3.5.2 version, then installed the 7.3.0.0 alpha DEV version. The DEV version, as it seems by design, doesn't create registry entries to the documents. So eg this entry on registry doesn't exist LibreOffice.WriterDocument.1 after install at HKEY_CLASSES_ROOT. I know I could have the two versions installed simultaneously but then I would be in doubt which LO version intervened on what occasion. What version created the OLE object by API, etc. Also it does not represent the typical use case. Real world users on production environment don't have two LO installed. I also know I could inject the missing registry information but I don't think that would be a proper test. Maybe there is a way to force a full and normal installation using a alpha DEV version. I'll wait your advice. If your advice is to inject the missing registry information then i will do that. Best regards.
If https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/ is the debug version, I must recognize I don't know, since the other Windows daily builds are 32 bits one and Arm one.
(In reply to Julien Nabet from comment #36) > If > https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/ > is the debug version, I must recognize I don't know, since the other Windows > daily builds are 32 bits one and Arm one. Hi Julien, The version that I installed corresponds to the link on your comment. I guess I will have to either: 1- Install 6.3.5.2 or 7.2.0.0 production version and then export the registry info. And then uninstall, reboot, install 7.3.0.0 DEV version and then import the previously exported registry info (changing paths where needed) and see if it works. 2- Wait for a version (i'm guessing a release candidate version) that after installation has all registry info properly in place. I will keep you updated about option number 1. Best regards
(In reply to Julien Nabet from comment #36) > If > https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/current/ > is the debug version, I must recognize I don't know, since the other Windows > daily builds are 32 bits one and Arm one. No, that is not a debug build. TB39 is. (In reply to Makrea from comment #37) > 2- Wait for a version (i'm guessing a release candidate version) that after > installation has all registry info properly in place. Then you would have to wait for 6 months.
I tested the daily buid 7.3 and I have the same experience as Makrea. Would it be possible to backport to 7.2 and test it in 7.2.1?
(In reply to kabilo from comment #39) > I tested the daily buid 7.3 and I have the same experience as Makrea. > Would it be possible to backport to 7.2 and test it in 7.2.1? The backport to 7.2 looks like the best way to go at this point. I will still be doing the test by injecting the missing registry information and let you know the results. But that's not the most desired test environment. Best regards.
The backport on 7.2 is now waiting for review here: https://gerrit.libreoffice.org/c/core/+/120877
(In reply to Julien Nabet from comment #41) > The backport on 7.2 is now waiting for review here: > https://gerrit.libreoffice.org/c/core/+/120877 Thanks Julien! :-)
Michael Warner committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/1e3f7a0370b13ba0da69385103f6419d55ff487b tdf#141097 Revert "Veto process exit while an OLE client is connected" It will be available in 7.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Makrea from comment #40) > I will still be doing the test by injecting the missing registry information > and let you know the results. > But that's not the most desired test environment. > > Best regards. Hi! I have good news! :) The technique of injecting missing registry information yielded results. The injection comprised above 6500 lines on HKEY_CLASSES_ROOT registry hive based on 6.3.5.2 registry information (extracted from a clean virtual machine). After injection, just by doing this, on a machine with LibreOfficeDev_7.3.0.0.alpha0_Win_x64.msi version installed I verified that becomes possible to create via API the most important LibreOffice related OLE objects directly related to the invocation of "com.sun.star.ServiceManager" and "com.sun.star.frame.Desktop". (This injection part would not be needed to be done on a release candidate version.) So after this the generation of the ODT document based on a OTT template occurs, the bookmarks are detected, information is then inserted on those bookmarks (nothing new at this point :) ) and then I typed some text on the generated document and tried to close the LibreOffice GUI on the X button and it closed! I'm fairly confident at this point that Michael Warner commit solves the issue that was reported. I would like to thank your work regarding this issue and kabilo for his duplicate findings. Any further information or tests that you need feel free to ask. PS: I'm not sure if DEV versions install to a "DEV" path. If so be aware that for this test I explicitly changed on installation the suggested "DEV" path to it's production version path that would normally be this one: C:\Program Files\LibreOffice\ I've done this to be sure to match the extracted 6.3.5.2 version registry paths. Best regards!
(In reply to Makrea from comment #44) > I'm fairly confident at this point that Michael Warner commit solves the > issue that was reported. Happy to help! :-) Given this confirmation, I will mark as Resolved Fixed. > > I would like to thank your work regarding this issue and kabilo for his > duplicate findings. I would also like to thank Julien and everyone else involved in driving this to closure.
*** Bug 139023 has been marked as a duplicate of this bug. ***