Bug 106294 - CRASH when LibreOffice is closed while running a macro
Summary: CRASH when LibreOffice is closed while running a macro
Status: RESOLVED DUPLICATE of bug 127205
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1 all versions
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Macro-UNOAPI Crash
  Show dependency treegraph
 
Reported: 2017-03-03 12:14 UTC by Xisco Faulí
Modified: 2020-07-02 08:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature: ["SbxBase::GetError()"]
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2017-03-03 12:14:42 UTC
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
Comment 1 Xisco Faulí 2017-03-03 12:19:59 UTC
Reproduced in

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Comment 2 Aron Budea 2017-03-04 03:09:30 UTC
I wonder in what way this is different compared to bug 88985.
Comment 3 Aron Budea 2017-03-04 04:50:55 UTC
Confirmed in 5.3.0.3 / Windows 7.
Comment 4 LeMoyne Castle 2017-05-02 16:51:34 UTC
@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.
Comment 5 Xisco Faulí 2017-10-12 08:03:22 UTC
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.
Comment 6 Xisco Faulí 2018-02-01 17:17:24 UTC
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
Comment 7 Justin L 2020-07-02 08:46:46 UTC
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 ***