[Libreoffice-bugs] [Bug 107297] Crash in: StarBASIC::~StarBASIC()

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=107297

LeMoyne Castle <lemoyne.castle at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           See Also|                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=10
                   |                            |6294
           Assignee|libreoffice-bugs at lists.free |lemoyne.castle at gmail.com
                   |desktop.org                 |
     Ever confirmed|0                           |1

--- Comment #3 from LeMoyne Castle <lemoyne.castle at gmail.com> ---
@Timur - can see reports by version with
http://crashreport.libreoffice.org/stats/version/5.3.1.2  or other version
number at the end

~~~~~><>~~~~~><>~~~~~><>~~~~~~~~~~~~~~

Went through several (>=10) of the stack traces on the crash reports with this
signature.  They all showed evidence of this being a 'crash on close of LO'. 
Reporter (Timur) said was using add-ons so added see also: bug 106294 (crash on
close of LO with macro running).  Will do work under that bug (with test doc
for repro), but leaving this open as non-dup to preserve visibility of
crashreporter to see if fixes for that actually make this one go away too.

I think there are two issues here:
I am confident that there is at least one hardware independent issue here: all
calls that start StarBasic need protection in case LO is closed (as in fix for
Bug 88985).  However, the Linux crash stack traces I am getting directly show
significant(?) differences in the way that the visual studio and gcc compilers
generate and call the destructors for Basic objects.  It is striking that the
*order* of the calls of Basic's coded destructors & compiler generated default
destructors appears to be reversed between the Linux and Windows build systems,
and that the same destructor appears to be called twice in Linux.  Will do the
changes to try to flatten the destruction handling here as that is a separate
problem from the lack of close protection for running Basic.  

The second issue:
There are  other signatures in crashreporter that show the 'crash on close of
LO with Basic' under other Basic destructor signatures: e.g. SbiObject'vector
deleting destructor' [IIRC], etc.  There are also suspiciously similar reports
of issues with and MS bug fixes for Visual Studio's generation of default
destructors.  The thing to try is to correct the Basic destructor declarations
so that they are no longer oddly or ill-formed (outside modern C++ standards).
In short, make Basic's destructors public.  I am quite sure that much of the
Basic code predates all but the earliest C++ standards and best practices.  

The upshot (short version):
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.  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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20170502/45b0af11/attachment-0001.html>