This bug was filed from the crash reporting server and is br-dd78e6d2-a7c0-4766-8907-c08c19a85440. ========================================= I don't know how I got this one, maybe on Writer close. But I had crash on paste before and restarted LO. This is working LO with add-ons, I can't say whether some of them caused this. There are 34 pages of this crash: http://crashreport.libreoffice.org/stats/signature/StarBASIC::~StarBASIC%28%29 Newest is for LO 5.3.1.2. BTW: how do we sort this crash list by version?
You can see it in the summary tab in http://crashreport.libreoffice.org/stats/signature/StarBASIC::~StarBASIC%28%29 It seems most of the reports are from 5.2.4.2 but there's still a few from the latest versions. Did you copy something to clipboard before you close Writer ?
I can't remember, maybe, or I printed this file.
@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.
Let's put ASSIGNED status since there's an assignee
Dear developer, 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.
Hi Timur, The issues seems no longer reported in http://crashreport.libreoffice.org/stats/signature/StarBASIC::~StarBASIC(). Should be close this as RESOLVED WORKSFORME as there are no steps to reproduce it?
0 reports in 5.4.* or 5.3.7
Can't say, question should be for developer. There are 66 pages and 3252 crashes, latest for Version: 5.3.6.1. I'll close for the moment, unless there are more of this.