Bug 146634 - Crash in: std::_Tree<std::_Tset_traits<ScFormulaCell *,std::less<ScFormulaCell *>,std::allocator<ScFormulaCell *>,0> >::erase
Summary: Crash in: std::_Tree<std::_Tset_traits<ScFormulaCell *,std::less<ScFormulaCel...
Status: RESOLVED DUPLICATE of bug 146497
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.2.4.1 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-07 09:58 UTC by Colin
Modified: 2022-12-07 12:30 UTC (History)
2 users (show)

See Also:
Crash report or crash signature: ["std::_Tree<std::_Tset_traits<ScFormulaCell *,std::less<ScFormulaCell *>,std::allocator<ScFormulaCell *>,0> >::erase"]

Attachments
Screen Dump (87.57 KB, image/png)
2022-01-07 10:13 UTC, Colin 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Colin 2022-01-07 09:58:47 UTC 
This bug was filed from the crash reporting server and is br-72dc922e-f356-4ca9-95c5-aeb4682b603d.
=========================================
See report 146497
I'm uncertain whether I should suppress repeat crash reports. Guidance needed.
Comment 1 Colin 2022-01-07 10:13:56 UTC 
Created attachment 177368 [details]
Screen Dump

Just discovered something sinister.
After crashing, recovering and reporting I perceived a noisier cooling fan so I investigated.
Attached is the Task Manager Screen.
Libre Office is not running anything. All files closed, I even opened and closed one to try to "flush it out" - Twice. All it does is push the CPU% higher.
Yes, killing the task does kill it
Comment 2 Julien Nabet 2022-01-07 17:15:56 UTC 
Would it be possible you attach a test file and a minimum step by step procedure to reproduce this?

Also, could you give a try to 7.2.4 ?
Comment 3 Julien Nabet 2022-01-07 17:23:37 UTC 
(In reply to Julien Nabet from comment #2)
> Would it be possible you attach a test file and a minimum step by step
> procedure to reproduce this?
> 
> Also, could you give a try to 7.2.4 ?

(I've just seen 7.2.5 has been released)
Comment 4 Colin 2022-01-07 18:22:55 UTC 
(In reply to Julien Nabet from comment #3)
> (In reply to Julien Nabet from comment #2)
> > Would it be possible you attach a test file and a minimum step by step
> > procedure to reproduce this?
> > 
> > Also, could you give a try to 7.2.4 ?
> 
> (I've just seen 7.2.5 has been released)

I just happened to have this lying around on another identical computer
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 1bb0e177124d5d6661b72df6c7d848fb23639652
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-US (en_SE); UI: en-US
Calc: threaded

So, going two better I couldn't reproduce the crash in this one with four significant attempts at destruction.

My other reports identified that the crash appeared to be triggered by inserting rows into arrays with conditional formatting - which was a mess.

It would replicate blocks of the conditional formatting with some overlaps and some gaps.

7.4 appears to have remedied that particular feature and it looks like a side benefit is "No More Crashes"

I shall reset to UNCONFIRMED and let one of the big boys change it to RESOLVED
Comment 5 Colin 2022-01-29 04:56:56 UTC 
I think I have caused duplicated effort: Bug 146497 appears to be related to an identical crash report
My apologies if I have wasted your time
Comment 6 Buovjaga 2022-12-07 12:30:20 UTC 

*** This bug has been marked as a duplicate of bug 146497 ***