Steps to reproduce: 1. Open attachment 131577 [details] from bug 106281 2. Go to Tools - Macro - Run Macro - ProgressBarTest(1).odt - ProgressBarTest - Run 3. Close LibreOffice while the macro is being executed. Reproduced in Version: 5.4.0.0.alpha0+ Build ID: d3676ceeec55a41337ce5e6bc596f4f100d0638e CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group and Versión: 5.3.0.3 Id. de compilación: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 Subpr. de CPU: 1; Versión de SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; Configuración regional: es-ES (es_ES); Calc: group
Reproduced in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
I wonder in what way this is different compared to bug 88985.
Confirmed in 5.3.0.3 / Windows 7.
@Aron - that is a very good question ... There are other ways to start Basic besides the way that was protected by Caolan under bug 88985. There are two issues here: see the longer (longest?) note on bug 107297. The upshot: I will work on the separate issues uncovered by 'crash in Basic on close of LO' bugs in the following way and order: 1. Bug 106294 - establish consistent protection for Basic at ALL calls that start StarBasic as Caolan did for bug 88985. External to Basic + a direct fix. Can test directly with close during long-running macro. 2. Bug 107297 - Make Basic's destructors public to bring the destruction of Basic objects in compliance with C++ standards/best practices in order to avoid compiler+linker confusion and gross differences between VS and gcc versions. Internal to Basic - an indirect (compiler-mediated) potential(!) fix. Might be hard to verify and will require much more thorough testing of Basic to try to avoid side effects. Will be obvious as a separate issue if the protection fix only works reliably on Linux and we still get crashes on Windows.
Dear LeMoyne Castle, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
Still reproducible in Version: 6.1.0.0.alpha0+ Build ID: 9baa3fcf1f414c74d2ea1b55b2cb358527fe7364 CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; Locale: en-US (C); Calc: group
fixed in LO 7.0 by commit f0a50d230756fc0a60780d992b807f9eb82106c2 Author: Jan-Marek Glogowski on Fri Feb 14 20:24:04 2020 +0000 tdf#127205 split Desktop::terminate process Trying to somehow keep stuff correctly alive, truned out to be rather futile. Originally I tried the same way Caolan did in the attached patch to tdf#88985, when he finally settled on adding a special terminate listener. But this is not enough to handle in-process scripted extensions, like Java, Python or even Basic macros themself. So this separates the module shutdown and SfxApplication cleanup from the rest of the terminate call. *** This bug has been marked as a duplicate of bug 127205 ***