Created attachment 149331 [details] beanshell script folderpicker we noticed a strange problem when using "com.sun.star.ui.dialogs.FolderPicker" service with java since LO 6.1. this did not happen with LO 5.4. i am adding a beanshell script to demonstrate. steps to reproduce with: Version: 6.1.5.2 (x64) Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: de-DE (de_DE); Calc: - Menu Tools/Macros/Organize Macros.../BeanShell... - [Create] a Library - [Create] a Module - [EDIT] - Clear - copy attached Source Code - adjust Line 37: xFolderPicker.setDisplayDirectory("D:\\Temp\\"); to a valid path - Save Macro - Run Macro - [Cancel] FolderPicker dialog - create a new writer document - close writer document - Run Macro again - [Cancel] FolderPicker - create a new writer document - crash i tried serveral times with a new userprofile and can always reproduce the crash, no crashreport is triggered. with attached debugger and Version: 6.3.0.0.alpha0+ (x64) Build ID: 0ae876595e9d9af44fc4d4bc948f8a42d8a27e8d CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded i can see: warn:vcl.schedule:1236:392:vcl/source/app/scheduler.cxx:368: we're too early - restart the timer (6ms)!Ausnahme ausgelöst bei 0x00007FFC1E4F5549 in soffice.bin: Microsoft C++-Ausnahme: com::sun::star::ucb::InteractiveAugmentedIOException bei Speicherort 0x0000008D8D257340. Ausnahme ausgelöst bei 0x00007FFC1E4F5549 in soffice.bin: Microsoft C++-Ausnahme: com::sun::star::ucb::InteractiveAugmentedIOException bei Speicherort 0x0000008D8D257340. Ausnahme ausgelöst bei 0x00007FFC1E4F5549 in soffice.bin: Microsoft C++-Ausnahme: com::sun::star::ucb::InteractiveAugmentedIOException bei Speicherort 0x0000008D8D257340. Ausnahme ausgelöst bei 0x00007FFC1E4F5549 in soffice.bin: Microsoft C++-Ausnahme: com::sun::star::ucb::InteractiveAugmentedIOException bei Speicherort 0x0000008D8D257340. Ausnahme ausgelöst bei 0x00007FFC1E4F5549 in soffice.bin: Microsoft C++-Ausnahme: com::sun::star::ucb::InteractiveAugmentedIOException bei Speicherort 0x0000008D8D257340. Ausnahmefehler bei 0x00007FFC1E16F08E (ucrtbase.dll) in soffice.bin: Schwerwiegende Beendigung des Programms angefordert Das Programm "[1236] soffice.bin" wurde mit Code 0 (0x0) beendet.
Created attachment 149332 [details] screenshot from debugger - solarmutext.cxx adding a debugger screenshot
Created attachment 149336 [details] LO FolderPicker no crash if i use lo service: "com.sun.star.ui.dialogs.OfficeFolderPicker" btw: implementation of FolderPicker has changed, see attached pdf.
On pc Debian x86-64 with master sources updated today, I don't reproduce this. i did: - Open Writer - Menu Tools/Macros/Organize Macros.../BeanShell... - [Create] a Library - [Create] a Macro - [EDIT] - Clear - copy attached Source Code - line 37, I put xFolderPicker.setDisplayDirectory("\\tmp\\"); - Save Macro - Run Macro - [Cancel] FolderPicker dialog I got an error message: "The folder contents could not be displayed Operation not supported" Did I miss something?
Hmm, I tried also: xFolderPicker.setDisplayDirectory("/tmp/"); => same result as previous comment
(In reply to Julien Nabet from comment #4) > Hmm, I tried also: > xFolderPicker.setDisplayDirectory("/tmp/"); > => same result as previous comment hm, can you try with a windows version ? i just tried again with: Version: 6.2.1.2 (x64) Build-ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded and can reproduce the crash. sometimes i have to repeat: - Run Macro - [Cancel] FolderPicker dialog - create a new writer document - close writer document several times before lo crashes unfortunatelly there is no crashreport...
it seems, the crash will only happen, if the windows folder/file picker is used (org.openoffice.Office.Common/Misc: UseSystemFileDialog = true) windows event log shows: Name der fehlerhaften Anwendung: soffice.bin, Version: 6.1.5.2, Zeitstempel: 0x5c526234 Name des fehlerhaften Moduls: ucrtbase.dll, Version: 10.0.17763.348, Zeitstempel: 0x26a80883 Ausnahmecode: 0xc0000409 Fehleroffset: 0x000000000006e91e ID des fehlerhaften Prozesses: 0x3c98 Startzeit der fehlerhaften Anwendung: 0x01d4e700ae3c0844 Pfad der fehlerhaften Anwendung: C:\Program Files\LibreOffice\program\soffice.bin Pfad des fehlerhaften Moduls: C:\WINDOWS\System32\ucrtbase.dll Berichtskennung: b898c6fa-05d7-419b-8fe5-65bc625c39e7 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist: Name der fehlerhaften Anwendung: soffice.bin, Version: 6.2.2.2, Zeitstempel: 0x5c8d3366 Name des fehlerhaften Moduls: ucrtbase.dll, Version: 10.0.17763.348, Zeitstempel: 0x26a80883 Ausnahmecode: 0xc0000409 Fehleroffset: 0x000000000006e91e ID des fehlerhaften Prozesses: 0x1148 Startzeit der fehlerhaften Anwendung: 0x01d4e6d75a04737e Pfad der fehlerhaften Anwendung: C:\Program Files\LibreOffice 6.2\program\soffice.bin Pfad des fehlerhaften Moduls: C:\WINDOWS\System32\ucrtbase.dll Berichtskennung: 843bb708-ea90-48d7-9457-bfd5b71c62a1 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Created attachment 150411 [details] crash dump
(In reply to Oliver Brinzing from comment #0) > we noticed a strange problem when using > "com.sun.star.ui.dialogs.FolderPicker" service with java since LO 6.1. this > did not happen with LO 5.4. to be more precise: looks like the FolderPicker implementation has changed between LO 6.1.4.2 and LO 6.1.5.2 (the 6.1.4.2 Folderpicker looks different, https://bug-attachments.documentfoundation.org/attachment.cgi?id=149336) and i cannot reproduce the crash with LO 6.1.4.2
the new FolderPicker has been implemented with: https://gerrit.libreoffice.org/plugins/gitiles/core/+/2129753120d8101f0f484571b6a8cd8eb4d4629c commit 2129753120d8101f0f484571b6a8cd8eb4d4629c [log] author Jan-Marek Glogowski <glogow@fbihome.de> Fri Sep 07 13:00:38 2018 +0200 committeJan-Marek Glogowski <glogow@fbihome.de> Sat Sep 08 23:07:06 2018 +0200 tree e06a410cf94d9815f6bf0710172bab7b6a235331 parent 025abb05385a1dc6219d48390cd4b783988cb409 [diff] tdf#119730 WIN switch to IFileDialog FOS_PICKFOLDERS Citing SHBrowseForFolderW remarks: "For Windows Vista or later, it is recommended that you use IFileDialog with the FOS_PICKFOLDERS option rather than the SHBrowseForFolder function." Since the minimum required Windows version is already 7 and we already just provide the Vista file picker, this gets rid of the Windows XP compatible folder picker code. Change-Id: I85daae84d4eb36fc827cf20aa277ce6a2f63dd2c Reviewed-on: https://gerrit.libreoffice.org/60144 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
*** Bug 124039 has been marked as a duplicate of this bug. ***
From the VS image you can see the release in fpicker/source/win32/asyncrequests.cxx:83 Just quoting my comment 3 of bug 124039: (In reply to Jan-Marek Glogowski from comment #3) > So my "lucky" assumption in the fix for bug 122927 is probably wrong. I > don't have access to a Windows build, and I won't for a longer time. If > nobody has time to fix this, you should probably revert the fix for bug > 122927, as this looks like the smaller problem. > > A huge hack would be something like > https://gerrit.libreoffice.org/#/c/69436, which will quite probably work > correct. Still I think functions should not need to handle locked and > unlocked calls, which leads to madness IMHO. Locking and multi-threading is > already hard enough… Nothing has changed for me. I'm just setting it to NEW, since the debugger shows the same backtrace as bug 124039.
https://gerrit.libreoffice.org/70301
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/a10cfc4865da9a1a5da0090f0a65dfb62c7010e2%5E%21 tdf#123502: Make sure to hold the mutex before releasing it It will be available in 6.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/e59e4c41e0fd9beaa03a60def58feefdef1e0bb6%5E%21 tdf#123502: Make sure to hold the mutex before releasing it It will be available in 6.2.4. 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-1": https://git.libreoffice.org/core/+/2e8efe4e28b5c120059bb8460141afa76e30f865%5E%21 tdf#123502: Make sure to hold the mutex before releasing it It will be available in 6.1.6. 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 Commit Notification from comment #15) > Affected users are encouraged to test the fix and report feedback. i can *not* reproduce the crash with my debug build: Version: 6.3.0.0.alpha0+ (x64) Build ID: 9079da7f62febaf4cef0b77320c31b4e8bb6b5a5 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded seems to be fixed :-)
Created attachment 150566 [details] macro for testing picker software
Created attachment 150567 [details] win cmd for starting macro
I can't confirm RESOLVED FIXED. The way I testet: 1. No LO running. 2. When starting macro (TestPickerSW.txt) by using an external command (TestPickerSW.cmd), macro stops processing, when selecting [3] ("com.sun.star.ui.dialogs.FilePicker") or [4] ("com.sun.star.ui.dialogs.FolderPicker"). 3. When additionally starting "soffice.exe" manually during macro stopped processing, macro starts processing again. Operating system used: Windows 7 Home Premium 64-bit Attached files: "TestPickerSW.txt" - the macro I used. "TestPickerSW.cmd" - The Win-CMD I used. Includes some instructions for testing. My test results: LO 6.1.4.2 => Macro selections: [1][2][3][4] OKAY Version: 6.1.4.2 (x64) Build-ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: CL LO 6.1.5.2 => Macro selections: [1][2][3][4] OKAY Version: 6.1.5.2 (x64) Build-ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: CL LO 6.1.6 Didn't find daily for "Windows 7 Home Premium 64-bit". LO 6.2.1.2 => Macro selections: [1][2] OKAY [3][4] ERROR Version: 6.2.1.2 (x64) Build-ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71 CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded LO 6.2.3.1 => Macro selections: [1][2] OKAY [3][4] ERROR Version: 6.2.3.1 (x64) Build-ID: 9ba025bafb03b962c34687cf87806cc03a3a7436 CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded LO 6.2.4.0.0+ => Macro selections: [1][2] OKAY [3][4] ERROR Version: 6.2.4.0.0+ (x64) Build ID: 52a8d0c0f4d61a1caa54331a20703175b83a5fe6 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:libreoffice-6-2, Time: 2019-04-05_07:52:55 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded 6.3.0.0.alpha0+ => Macro selections: [1][2] OKAY [3][4] ERROR Version: 6.3.0.0.alpha0+ (x64) Build ID: 35d9a2618dc0116378ab795a7b9277d248c5afd4 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-05_04:55:04 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded I hope that the attched files help you to reproduce my testing result. Gretings Hans-Werner
(In reply to Hans-Werner from comment #19) > I can't confirm RESOLVED FIXED. > ... > My test results: > > LO 6.2.4.0.0+ => Macro selections: [1][2] OKAY [3][4] ERROR > > Version: 6.2.4.0.0+ (x64) > Build ID: 52a8d0c0f4d61a1caa54331a20703175b83a5fe6 > TinderBox: Win-x86_64@42, Branch:libreoffice-6-2, Time: 2019-04-05_07:52:55 > > 6.3.0.0.alpha0+ => Macro selections: [1][2] OKAY [3][4] ERROR > > Version: 6.3.0.0.alpha0+ (x64) > Build ID: 35d9a2618dc0116378ab795a7b9277d248c5afd4 > TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-05_04:55:04 You have tested with both daily versions built before the patch was pushed (Apr 05 23:14:03 2019 +0200 for 6-2; Apr 05 19:17:10 2019 +0200 for master) ... so - what that "I can't confirm" might mean? ;-)
I'm sorry, I'm not used to use daily LO versions. May be I did'nt find the up to date LO version as you noticed. I'm just only a LO user :-)) So please send me the links for downloading the actual LO versions for testing. "I can't confirm" means, that using "com.sun.star.ui.dialogs.FilePicker" and "com.sun.star.ui.dialogs.FolderPicker" causes errors. Greetings Hans-Werner ;-))
Looks like there's no 6-2 dailies current enough. You need to check when 6-2 dailies from today or later appear. Or use a self-built versions, like Oliver does. https://dev-builds.libreoffice.org/daily/master/Win-x86@39/2019-04-06_00.08.48/ has the patch, so you might test if master has it fixed. By the way, it's interesting for me: (In reply to Hans-Werner from comment #19) > LO 6.1.5.2 => Macro selections: [1][2][3][4] OKAY > > Version: 6.1.5.2 (x64) > Build-ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 > CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; > Gebietsschema: de-DE (de_DE); Calc: CL So it looks like 6.1.5 wasn't affected after all, despite having the original patch (from comment 9) backported?
Thanks for sending the download link. I downloaded and installed: master~2019-04-06_00.08.48_LibreOfficeDev_6.3.0.0.alpha0_Win_x86.msi 179892224 2019-Apr-06 01:33 master~2019-04-06_00.08.48_LibreOfficeDev_6.3.0.0.alpha0_Win_x86_helppack_en-US.msi 2056192 2019-Apr-06 01:36 Test result: Can't confirm RESOLVED FIXED. 6.3.0.0.alpha0+ => Macro selections: [1][2] OKAY [3][4] ERROR Version: 6.3.0.0.alpha0+ Build ID: 9079da7f62febaf4cef0b77320c31b4e8bb6b5a5 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded Yes, 6.1.5 was not affected: LO 6.1.5.2 => Macro selections: [1][2][3][4] OKAY But I don't understand what you mean with "despite having the original patch (from comment 9) backported?". BTW: The time, I (12.11.1951) developed software (FortranIV, Fortran77) and administrated fault tolerant server systems (Stratus ftServer, Red Hat, CentOS) is some time ago. Therfore I'm not used and not able to do today things like building LO self-built versions. Today only some Perl and/or Basic-Macro programming. Greetings Hans-Werner :-))
(In reply to Hans-Werner from comment #19) > The way I testet: > > 2. When starting macro (TestPickerSW.txt) by using an external command > (TestPickerSW.cmd), macro stops processing, when selecting [3] > ("com.sun.star.ui.dialogs.FilePicker") or [4] > ("com.sun.star.ui.dialogs.FolderPicker"). > 3. When additionally starting "soffice.exe" manually during macro stopped > processing, macro starts processing again. (In reply to Hans-Werner from comment #23) > 6.3.0.0.alpha0+ => Macro selections: [1][2] OKAY [3][4] ERROR > > Version: 6.3.0.0.alpha0+ > Build ID: 9079da7f62febaf4cef0b77320c31b4e8bb6b5a5 > > Yes, 6.1.5 was not affected: LO 6.1.5.2 => Macro selections: [1][2][3][4] > OKAY So - all that means you are talking about a totally different thing. 1. That #3 from your testing design from comment 19 means that LibreOffice had *not* crashed, which is the essence of this specific bug. 2. The bug was filed against 6.1.5 from the very beginning. Please file a new bug report for your issue.
Today I did, what Oliver asked me to do some time ago: "[...] Das Problem habe ich auch, es tritt seit Version 6.1 auf, vgl.: Bug 123502 - crash: use of "com.sun.star.ui.dialogs.FolderPicker" service from java seems to cause crashes since LO 6.1 https://bugs.documentfoundation.org/show_bug.cgi?id=123502 Irgendetwas stimmt mit dem System-Folder Picker nicht mehr.. Wenn Du ein ein einfaches Basic Makro Demo hast, füge es bitte dem issue bei. [...]" ( https://listarchives.libreoffice.org/de/users/msg21444.html ) The last sentence of above in English: "If you have a simple basic macro demo, please add it to this issue." So I'm a little bit wondering about your answer ... Greetings Hans-Werner :-))
(In reply to Hans-Werner from comment #26) > So I'm a little bit wondering about your answer ... i just tried with Win10x64 and Version: 6.2.3.1 (x64) Build-ID: 9ba025bafb03b962c34687cf87806cc03a3a7436 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: > LO 6.2.3.1 => Macro selections: [1][2] OKAY [3][4] ERROR and macro will always end with: "Last code line of macro ..." so i am pretty sure, this is a different issue.
Just wanted to note that the way to run the macro from command prompt, like > instdir/program/soffice.bin --nologo macro:///Standard.Module1.TestPickerSW without LO already running, is essential to reproduce the problem from comment 19, which is a regression after https://git.libreoffice.org/core/+/0073101ec520e40727800f1d90b3b211fd6ec8d8. So - definitely a different problem, needing a separate report.
(In reply to Mike Kaganski from comment #28) > without LO already running, is essential to reproduce the problem exactly what i did, maybe not reproducible with all windows versions? i am running Win10x64 ? > which is a regression after > https://git.libreoffice.org/core/+/0073101ec520e40727800f1d90b3b211fd6ec8d8. > So - definitely a different problem, needing a separate report. ok, so you were able to reproduce it?
(In reply to Oliver Brinzing from comment #29) > (In reply to Mike Kaganski from comment #28) > > without LO already running, is essential to reproduce the problem > > exactly what i did, maybe not reproducible with all windows versions? > i am running Win10x64 ? me too :-) - but I tested with master, not with 6.2.3.1. > ok, so you were able to reproduce it? yes. LibreOffice just keeps waiting an event, in a working state.
(In reply to Mike Kaganski from comment #28) > Just wanted to note that the way to run the macro from command prompt, like > > > instdir/program/soffice.bin --nologo macro:///Standard.Module1.TestPickerSW > > without LO already running, is essential to reproduce the problem from > comment 19, which is a regression after > https://git.libreoffice.org/core/+/0073101ec520e40727800f1d90b3b211fd6ec8d8. > So - definitely a different problem, needing a separate report. FYI: something like the following commit may be needed: commit 7b148b0edfb217196c171f8e64e79b49669fc36f Author: Jan-Marek Glogowski <glogow@fbihome.de> Date: Thu Dec 13 11:50:41 2018 +0100 WIN move native dialog hack into WinScheduler The important line is: WinScheduler::SetForceRealTimer(); before opening the OLE dialog. I thought all this async handling would prevent this for the file picker, but since Mike found the single-shot SetTimer is a problem, it might help. OTOH Mike claims it's fixed on master, so the fix should be bisectable.
(In reply to Jan-Marek Glogowski from comment #31) > OTOH Mike claims it's fixed on master, so the fix should be bisectable. I'm sorry if I said something that looks like that - it is reproducible in master. And please, let Hans-Werner to create a dedicated issue for that problem, since it's inappropriate to track this irrelevant problem here.
New BugReport created: Basic Macro hang up when using (operation system) filepicker/folderpicker https://bugs.documentfoundation.org/show_bug.cgi?id=124579 Greetings Hans-Werner :-))
Verified in Version: 6.3.0.0.alpha0+ Build ID: 05a8749ee6f251d4b92eecb97763fa1fe94c68c8 CPU threads: 16; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded @Mike Kaganski, thanks for fixing this issue!
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-2-3": https://git.libreoffice.org/core/+/3196dffa5c14ed7b74c29f2abfa9c618bfb8b7ef%5E%21 tdf#123502: Make sure to hold the mutex before releasing it It will be available in 6.2.3. 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.