Created attachment 141207 [details] backtrace log Description: crash when moving mouse over a cell containing a comment Steps to reproduce: 1. Create a new Spreadsheet 2. Right click > Insert Comment 3. Type a comment 4. Click outside Comment to close it 5. Move mouse over cells: Comment is shown 6. Move mouse to hide Comment Actual result: crash Expected result: no crash Version: 6.1.0.0.alpha0+ Build ID: 2c63fcb0cf10c7ce580545576f2bd40dbcdb61d0 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: fr-FR (fr_FR.UTF-8); Calc: group Attached backtrace
Regression introduced by: author Armin Le Grand <Armin.Le.Grand@cib.de (CIB)> 2018-03-01 15:54:32 +0100 committer Armin Le Grand <Armin.Le.Grand@cib.de> 2018-04-07 00:28:30 +0200 commit dfefe448c41921f2f1e54d3f69b8b9e89031d055 (patch) tree 1aace31054b5740e2faffcbc5de66a791be27f7d parent eba4d5b2b76cefde90cb3d6638c736f435023a45 (diff) SOSAW080: Added first bunch of basic changes to helpers Bisected with: bibisect-linux64-6.1 Adding Cc: to Armin Le Grand
confirm Version: 6.1.0.0.alpha0+ Build ID: 2c63fcb0cf10c7ce580545576f2bd40dbcdb61d0 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: gtk3; Locale: nl-BE (en_US.UTF-8); Calc: group
Ran into this crash when trying to confirm bug 116998 in current master. Best regards. JBF
*** Bug 116991 has been marked as a duplicate of this bug. ***
How will we know when this has been resolved?
(In reply to Elmar from comment #5) > How will we know when this has been resolved? You are subscribed to this bug report, so you will receive a mail when the status will have been changed to resolved fixed. Best regards. JBF
*** Bug 117200 has been marked as a duplicate of this bug. ***
Tried to reproduce, but did not happen on Win. Checked the log, too - nothing obvious. Maybe Linux only...? FGix for tdf#117145 already included in test version, thuogh.
Could repro on Linux, non-current version. Updating to have fix for tdf#117145 included...
(In reply to Armin Le Grand (CIB) from comment #9) > Could repro on Linux, non-current version. Updating to have fix for > tdf#117145 included... Still reproducible in Version: 6.1.0.0.alpha1+ Build ID: f1579d3d6c5f5f3a651825e035b93bee7a4f43c6 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group with the fix for bug 117145 included...
Happens on updated Linux, but not on updated Win -> strange, Win-only crash? Will again update win version and get Linux-version with debug...
Re-checked, no crash on Windows (Is there a setting like 'not_on_windows' instead 'on_linux' ?)
yep, it doesn't crash with gen, only gtk3 and gtk... Adding Caolán to the loop as well
gtk2/gtk3 have working accessibilty so its possible that this sort of thing is an a11y related crash which might appear on turning on windows a11y (however that's done)
Linux debug version ready, taking a look...
Start is in ScNoteMarker::~ScNoteMarker. It destructs a SdrModel which uses ::ClearModel() which uses ::DeletePage() to destruct the SdrPage(s). SdrPage is derived from SdrObjList (was already in lo-6-0) which gets deleted first. That again uses SdrObjList::Clear() which removes and deletes the SdrObjects from the SdrObjList. What has changed is that there is no longer a pModel SdrModel* in SdrObjList that was set to nullptr in SdrObjList::~SdrObjList() in lo-6-0 with the comment: // To avoid that the Clear() method will broadcast changes when in destruction // which would call virtual method (not allowed in destructor), the model is set // to NULL here. This did change and there is broadcasting now. Not directly a virtual functoin call, but the broadcasts goes to ScDrawModelBroadcaster::Notify and there SdrPage::GetUnoPage() is called exactly at the SdrPage that gets destructed. Thus: Need to find a way not to broadcast in SdrObjList::Clear() when coming from SdrObjList::~SdrObjList()...
@Caolan: Just curious - why is with Linux and gtk3/gtk ScNoteMarker on the stack? Is there some 'auto-clipboard' stuff going on...? This *does* use massive ressources (con/de/structing a SdrModel, cloning SdrObjects, ...). Is that needed/intended..?
Solution with splitetd ::ClearSdrObjList on gerrit (https://gerrit.libreoffice.org/#/c/53839/)
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0fe7bda233da3c1f95a82c0050c8f917dc39c22e tdf#116879 Separate SdrObjList::Clear() as needed It will be available in 6.1.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.
looking at the bt of the crash for me I don't see any clipboard stuff in this case, which is unlike the other crash on exit bug which is different. All there is here is a mouse move event which triggers some help balloon code paths, so the gtk/gtk3 path here doesn't look particularly odd, and not c-n-p related as far as I can see.
Hello, It seems to be OK now. Tha
Thanks a lot for your work
No crash anymore for me with Version: 6.1.0.0.alpha1+ Build ID: 3988bd9dc8339aa32f1721df6b256def5e94f786 Threads CPU : 4; OS : Linux 4.4; UI Render : par défaut; VCL: gtk3; Ubuntu_16.04_x86-64 Locale : fr-FR (fr_FR.UTF-8); Calc: threaded Best regards. JBF
no crash anymore for me with Version: 6.1.0.0.alpha1+ Build ID: 8e794c95c48d7c7fbfffebb9cd99f8d49dcf4735 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: gtk3; Locale: nl-BE (en_US.UTF-8); Calc: group
Verified in Version: 6.1.0.0.alpha1+ Build ID: 1e2afc9bd3062cfba6b65b45c17a08f298014239 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Thank you. checked it
Bug still present in version 6.1.0.0.alpha1+. Technical data on the crash report is in the following link: http://crashreport.libreoffice.org/stats/crash_details/cf9ba2ab-daab-4a6b-a016-1e2e4b881c14
More data... Versión: 6.1.0.0.alpha1 Id. de compilación: cb47f0d320994e001bc38dc2ee9b7d957b15e6ab CPU threads: 2; OS: Linux 4.13; UI render: default; VCL: gtk2; Locale: es-CO (es_CO.UTF-8); Calc: group
More data... Versión: 6.1.0.0.alpha1 Build ID: cb47f0d320994e001bc38dc2ee9b7d957b15e6ab CPU threads: 2; OS: Linux 4.13; UI render: default; VCL: gtk2; Locale: es-CO (es_CO.UTF-8); Calc: group
(In reply to Daniel from comment #27) > Bug still present in version 6.1.0.0.alpha1+. Technical data on the crash > report is in the following link: > > http://crashreport.libreoffice.org/stats/crash_details/cf9ba2ab-daab-4a6b- > a016-1e2e4b881c14 It is because the commit that fixes the bug is more recent than your version: https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=cb47f0d320994e001bc38dc2ee9b7d957b15e6ab You can try a daily build. Best regards. JBF
I think this is resolved in 6.1 alpha