Problem description: When I use the method endExecute() in a Dialog (to close it with a specific condition) 90% libreofice crash. Steps to reproduce: 1. create a dialog (GUI) 2. excecute it with a button with some macro like: Dim oDlg As Object Sub StartDialog oDlg = CreateUnoDialog(DialogLibraries.Standard.Dialog1 ) oDlg.execute() End Sub 3. finish the dialog excecution with a button in it, excecuting the macro: Sub CloseDialog oDlg.endExecute() End Sub Current behavior: 90% crash prob Expected behavior: Close the Dialog Operating System: Windows 8 Version: 3.6.4.3 release
Not even close to a blocker bug.
Could you attach any example documents with needed macro, button etc. to allow others to check on different system/build simply by downloading and opening a file? Thanks.
Created attachment 73706 [details] Example here it is the example. When you press the button, the dialog close and the libreoffice crash
Created attachment 73707 [details] Example Here it is (example). When you press the close button, the dialog close an then libreoffice crash.
In ubuntu works Fine, so its a Windows version bug
(In reply to comment #4) > Here it is (example). When you press the close button, the dialog close an > then libreoffice crash. Checked with: LO 4.0.0.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Could not reproduce. Dialog closed, no crash.
I´m using Windows 8 pro 64bits when it crash. I try to remove all the appdata info and reinstalling again, but the problem continues. I can reproduce it in another machine with the same windows version.
*** Bug 63525 has been marked as a duplicate of this bug. ***
Created attachment 77948 [details] more robust tescase to reproduce the problem take a look to: https://bugs.freedesktop.org/show_bug.cgi?id=63525 for more information
I have the same problem and I reported it in bug (closed as duplicate of this one): https://bugs.freedesktop.org/show_bug.cgi?id=63525 I add here the tescase that I created for that bug report the problem seems to be windows specific and doesn't happens with all dialogs and not every time you use them, with complex dialogs it's easy to reproduce. please, use that latest tescase submitted to see if you can reproduce the problem as that one is more exhaustive to look for the problem thanks
This can be reproduced with Libreoffice 4.0.4.2
(using dispose())
Comment on attachment 77948 [details] more robust tescase to reproduce the problem this testcase not longer gives error with libreoffice 4.1 (at least for me)
Created attachment 92781 [details] backtrace of the error extracted with windbg following the guide in: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg I have extracted this minidump with libreoffice 4.2.0.3
Created attachment 92782 [details] analisys of the backtrace done with windbg
Franco/Pasqual: any update with recent LO version (4.4.2 or at least 4.3.6)?
Created attachment 114914 [details] testcase to reproduce the problem to reproduce the problem click the 'Launch TestCase (complex dialog)' button. it will open and close a dialog 10 times, if that doesn't not freeze libreofice repeat the operation several times
Using the testcase, that I have uploaded a moment ago, the problem still reproduces with 4.4.2
On pc Debian x86-64 with master sources updated today, I don't reproduce this after having clicked on the button 5 times. Hope someone will be luckier than me or perhaps Windows only bug. It could be great if someone could retrieve a backtrace with symbols. (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information)
Created attachment 114961 [details] backtrace extracted with the procdump tool on windows the dump has been extracted with the procdump tool and later analyzed with windbg
Increasing the number of iterations in the testcase code can make easier to reproduce the problem (use 1000 or more). In my home pc the problem reproduces quite fast (10-15 iterations), at work it I have need a lot more, I don't know the cause. I will try to take an additional backtrace I can't reproduce too the bug in centos 7
Pasquale: taking a quick look to bt, the pb is at this line: GetMessageW( &aTmpMsg, pInst->mhComWnd, SAL_MSG_RELEASEWAITYIELD, SAL_MSG_RELEASEWAITYIELD ); (see http://opengrok.libreoffice.org/xref/core/vcl/win/source/app/salinst.cxx#239) Caolan: bt part shows vcl part with "GetMessageW" function. It seems the only location where "GetMessageW" is used (instead of "GetMessage"). Any thought?
Created attachment 114965 [details] backtrace of the problem in windows 8.1 32 bits (error in the first iteration) in this backtrace libreoffice hanged in the first iteration (normally take 10-5 to fail but this also happens sometimes), the ios was windows 8.1 32 bits
I have tested more at home (windows 8.1 32 bits), there the problem reproduces very fast and the error is different from the one I had at work (windows 7 64 bits). the error in the 32 bits machine seems a thread interlock (error in mutex.c) and happens very quickly, probably the errors are two different bugs I will test it more tomorrow to check if the os architecture is relevant
today I have tested the problem in new windows 7, 32 and 64 bits, machines. the mutex bug reproduces in both quite quickly so the os architecture doesn't seem relevant in this bug
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
Works for me in LibreOffice 5.2.4 both in Linux x86-64 (fedora) and Windows 10 32 bits