Bug 118333 - Crash in: SfxItemPool::Remove(SfxPoolItem const &) when reloading a file
Summary: Crash in: SfxItemPool::Remove(SfxPoolItem const &) when reloading a file
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-23 17:23 UTC by robert.funnell
Modified: 2018-11-16 03:52 UTC (History)
4 users (show)

See Also:
Crash report or crash signature: ["SfxItemPool::Remove(SfxPoolItem const &)"]


Attachments
Anonymized version of file that crashed (108.50 KB, application/msword)
2018-06-24 23:54 UTC, robert.funnell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description robert.funnell 2018-06-23 17:23:00 UTC
This bug was filed from the crash reporting server and is br-8962ed3b-a646-401b-b68f-b983d1ede6c5.
=========================================
I had been editing an old .doc file, mostly clearing direct formatting, and then decided to Reload the document, at which time LO crashed.
Comment 1 Xisco Faulí 2018-06-24 15:35:49 UTC
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Comment 2 robert.funnell 2018-06-24 23:54:31 UTC
Created attachment 143079 [details]
Anonymized version of file that crashed

This is anonymized version of the file that I was editing when the crash occurred. I had done some editing (mostly removing highlighting, I think, either by setting No Fill or by clearing direct formatting) when I did a Reload and LO crashed.
Comment 3 Xisco Faulí 2018-06-26 10:33:29 UTC
The crash signature is the same as in bug 115065, so it seems related to table manipulation. However, I can reproduce the crash...

@Robert, have you been able to reproduce it again ?
Comment 4 robert.funnell 2018-06-26 11:51:14 UTC
I made one unsuccessful attempt to reproduce the crash, making some changes similar to the ones I made before (but not as many) and then reloading.

There are no tables in the document.

Xisco Faulí, are you saying that you can or cannot reproduce the crash?
Comment 5 Xisco Faulí 2018-06-26 12:06:36 UTC
(In reply to robert.funnell from comment #4)
> I made one unsuccessful attempt to reproduce the crash, making some changes
> similar to the ones I made before (but not as many) and then reloading.
> 
> There are no tables in the document.

Yep, I noticed it after opening the document :D

> 
> Xisco Faulí, are you saying that you can or cannot reproduce the crash?

No, I can't reproduce it
Comment 6 Buovjaga 2018-07-13 15:39:53 UTC
Not reproduced on Windows or Linux, 6.0 or master. Did some editing before reloading.
Comment 7 raal 2018-07-15 08:28:17 UTC
No repro with Version: 6.2.0.0.alpha0+
Build ID: 84ccbb5123fe976a105e97390141ed209c8b9bcc
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: x11; 

Version: 6.2.0.0.alpha0+ (x64)
Build ID: 2c85607101e2e04e870e3b87362f39f9a9148e6c
CPU threads: 1; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-06-16_00:12:37
Comment 8 Xisco Faulí 2018-10-18 14:35:02 UTC
Hi Robert,
have you been able to reproduce the crash again? If not, I'd suggest to close this issue.
Comment 9 robert.funnell 2018-10-18 14:58:07 UTC
No, I haven't been able to reproduce it.
Maybe the bug should be left open so somebody sometime might consider adding more error checking to the code where it crashed?
Comment 10 Xisco Faulí 2018-10-18 15:09:51 UTC
(In reply to robert.funnell from comment #9)
> No, I haven't been able to reproduce it.
> Maybe the bug should be left open so somebody sometime might consider adding
> more error checking to the code where it crashed?

We can always reopen it if needed.
Setting to RESOLVED INSUFFICIENTDATA