Created attachment 134775 [details] example spreadsheet STR --- ( 1) Set your macro security level (Tools > Options > LibreOfficeDev > Security > "Macro Security") to Medium. ( 2) Optionally download attached test3.ods to /tmp/ and skip ahead to step (10). ( 3) Create new empty spreadsheet. ( 4) Take menu options Tools > Macros > "Organize Macros" > "LibreOfficeDev Basic...". Program presents window "LibreOfficeDev Macros". ( 5) In pane "Macro From", click "Untitled 1" and then click <New>. Program presents dialog "New Module" with default Name "Module 1". ( 6) In dialog "New Macro", click <OK>. Program displays window "Untitled 1.Standard - LibreOfficeDev Basic 6.0". In source pane observe line 3 "Sub Main" and line 5 "End Sub". ( 7) File > Close. Program returns focus to window "Untitled 1 - LibreOfficeDev Calc 6.0". ( 8) Save the spreadsheet as /tmp/test3.ods. ( 9) Close LibreOffice. (10) Run LibreOffice from the command line with parameters --script-cat /tmp/test3.ods Expected: I am not sure, as I have never actually seen output from this option. Observed: Terminal output includes UNO exception during client open: Application Error Fatal exception: Signal 6 followed by a stack trace. Note that the behaviour of Writer is exactly parallel to Calc. I observe this on debian-stretch with daily Linux dbgutil bibisect repository version 2017-07-21 and in a local build of commit 4b7b93be (2017-07-05). Experimentation in gdb shows that the message comes from desktop/source/app/app.cxx:2074; the try block starts at line 2045. A `step` command at line 2060 -- "OpenClients(); -- transfers control directly to the catch block. The exception then is $1 = (const com::sun::star::uno::Exception &) @0x555558c7d510: { Message = "" , Context = uno::Reference to (basic::SfxScriptLibrary *) 0x555558c7a9b0 } Funnily enough, an attempt to backtrace from the catch block displays two stack frames, and then gdb pegs one CPU. Further work in the daily dbgutil bibisect repository shows that the exception entered LibreOffice at about the same time as parameter --script-cat, somewhere in the day before commit 2017-06-10: source-hash-076ed447f694239d5c67adee528ea6e471d909ff
I can confirm with Version: 6.0.0.0.alpha0+ Build ID: e0bafa78e3ad0df397d78cd65ad19bd5b07dc5f2 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-07-20_22:42:49 UNO exception during client open: https://wiki.documentfoundation.org/ReleaseNotes/6.0 : Add --script-cat parameter to allow dumping VBA and StarBasic macros from files to the console (Michael Meeks - Collabora) -> adding mmeks to cc
Thanks for the report; it seems ODT defers loading the macros - which is great - in many situations; https://gerrit.libreoffice.org/40550 forces that process and fixes this for me.
Thank you, Michael. Still on debian-stretch, I applied the patch on top of a local build of commit 7ed404ba (2017-07-27 13:31 UTC), and LibreOffice now politely shows the (minimal) contents of Module1.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ff1471d33113a26b414a473c81b0b316c3b82504 tdf#109262 - load libraries, and handle exceptions for --script-cat It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks ! =) merged.
On debian-stretch in daily dbgutil bibisect repository version 2017-08-01, I get the output from --script-cat without problem. I am setting status VERIFIED FIXED. Again, thank you, Michael.