Bug 105055 - Crash in: ScPostIt::CreateCaption(ScAddress const &,SdrCaptionObj const *)
Summary: Crash in: ScPostIt::CreateCaption(ScAddress const &,SdrCaptionObj const *)
Status: RESOLVED DUPLICATE of bug 104967
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha1+
Hardware: x86-64 (AMD64) Windows (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2017-01-02 19:57 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2020-04-15 19:10 UTC (History)
4 users (show)

See Also:
Crash report or crash signature: ["ScPostIt::CreateCaption(ScAddress const &,SdrCaptionObj const *)"]


Attachments
Backtrace with WinDbg (7.89 KB, text/plain)
2017-01-15 22:06 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan_Lange_KA@T-Online.de 2017-01-02 19:57:59 UTC
This bug was filed from the crash reporting server and is br-0dc37319-2e36-4ba2-8b8d-f6231a1aaabc.
=========================================

originally reported as part of bug 104969 and later reported as separate bug

In special cases shutdown of LibreOffice (LO) is not completed. In the Task Manager remain 2 LO processes. When one then tries to start LO again (one time or repeatedly), it seems that LO doesn't start, but in the Task Manager appear 4 or more LO processes, belonging pairwise one to another. Only when the "old" processes are cancelled in the Task Manager, LO really opens.
Then it says (only in LO 5.3.0 RC1, not in LO 5.4.0): "Leider scheint LibreOffice bei der letzten Verwendung abgestürzt zu sein." (Unfortunately LibreOffice seems to have crashed during the last use.). 

Simple way to reproduce the behavior:
- open LO
- File -> New -> Spreadsheet
- enter something in cell A1
- insert a comment to cell A1
- copy complete (!) cell A1 into clipboard
- paste clipboard content into any other cell (e.g. A2 or B1)
- save the document and close LO --> Shutdwon of LO hangs: LO Windows is closed, but in the task manager remain 2 LibreOffice processes and hinder a new start of LO

reproduced with LO 5.3.0 RC1 
Version: 5.3.0.1 (x64)
Build-ID: 3b800451b1d0c48045de03b5b3c7bbbac87f20d9
CPU-Threads: 4; BS-Version: Windows 6.19; UI-Render: Standard; Layout-Engine: neu; 
Gebietsschema: de-DE (de_DE); Calc: group

and with LO 5.4.0
Version: 5.4.0.0.alpha0+
Build ID: a7c51323b7343f82b5aea6098f5d5e31a8bad0e9
CPU Threads: 1; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-29_23:35:20
Locale: de-DE (de_DE); Calc: group
Comment 1 Xisco Faulí 2017-01-02 22:33:18 UTC
Hello,
it seems like a duplicate of bug 104969...

*** This bug has been marked as a duplicate of bug 104969 ***
Comment 2 Xisco Faulí 2017-01-04 15:50:13 UTC
Moving back to UNCONFIRMED. I incorrectly closed this as a duplicate of bug 104969 without paying attention to the description...
Comment 3 V Stuart Foote 2017-01-04 16:21:33 UTC
http://crashreport.libreoffice.org/stats/signature/ScPostIt::CreateCaption(ScAddress%20const%20&,SdrCaptionObj%20const%20*)?page=3

Little doubt it is valid--to NEW

Looking through the catalog of stacktraces crashes all seem to fall here:
http://opengrok.libreoffice.org/xref/core/sc/source/core/data/postit.cxx#707

Pointer issue?
Comment 4 Telesto 2017-01-08 16:25:21 UTC
Confirming with:
Versie: 5.3.0.1 
Build ID: 3b800451b1d0c48045de03b5b3c7bbbac87f20d9
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Layout Engine: new; 
Locale: nl-NL (nl_NL); Calc: CL

and with
Version: 5.4.0.0.alpha0+
Build ID: 92a1ad1f36b6d3cc13135a8c0805508933011577
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-06_23:42:59
Locale: nl-NL (nl_NL); Calc: CL
Comment 5 Telesto 2017-01-08 18:56:28 UTC
*** Bug 104967 has been marked as a duplicate of this bug. ***
Comment 6 Telesto 2017-01-08 20:38:31 UTC Comment hidden (obsolete)
Comment 7 Telesto 2017-01-08 21:12:30 UTC
Previous list is wrong:

Found in:
Version: 5.4.0.0.alpha0+
Build ID: 92a1ad1f36b6d3cc13135a8c0805508933011577
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-06_23:42:59
Locale: nl-NL (nl_NL); Calc: CL

and in
Versie: 5.3.0.0.alpha1 
Build ID: f4ca1573fcf445164c068c1046ab5d084e1b005f
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; 
Locale: nl-NL (nl_NL); Calc: CL

but not in:
Versie: 5.2.4.2 
Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 8 Aron Budea 2017-01-08 23:16:02 UTC Comment hidden (bibisection)
Comment 10 Aron Budea 2017-01-15 22:06:01 UTC
Created attachment 130465 [details]
Backtrace with WinDbg

(In reply to V Stuart Foote from comment #3)
> Pointer issue?

Yes, incoming pCaption is invalid (all the way from Clone(...)). Interestingly, other parts of maNoteData seem to be valid.
Comment 11 Eike Rathke 2017-01-20 19:43:36 UTC
This most likely is a duplicate of bug 104967 as the backtrace and crashreports indicate, CreateCaption() happens under CopyFromClip(), presumably also here if the originating document was closed before.

*** This bug has been marked as a duplicate of bug 104967 ***
Comment 12 Stefan_Lange_KA@T-Online.de 2017-01-20 20:49:40 UTC
For me this is OK, because the patch to solve the problem of bug 104967 also solves the problem of bug 105055.

Tested with
Version: 5.4.0.0.alpha0+
Build ID: cef8ebe925bde6fc1889085e3ccb1be236791e99
CPU Threads: 1; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-01-20_02:26:12
Locale: de-DE (de_DE); Calc: group