Created attachment 49107 [details]
I can consistently get Calc to crash by adding a pivot table to a new sheet, then adding another pivot table to second sheet and then trying to delete the first sheet.
It doesn't matter if I select the PVT destination manually or use the -new sheet- selection. Once that second pivot table has been created it is impossible to delete the first worksheet and save. The document recovers fine but the sheet can still not be deleted.
Deleting the pivot table before trying to delete the sheet will allow the sheet to be deleted but then Calc crashes when trying to save.
Problem exists on Windows too. Didn't try Linux.
Reproduced on LibreOffice 3.4 340m1(Build:103) for OpenSuse Linux.
Confirmed on Linux.
I randomly created two pivot tables, first one based off sheet 1 data, second one based off sheet 2 data. I can delete sheet 2, sheet 2 pivot table fine, and sheet 1 pivot table fine, but when I delete sheet 1, the crash occurs.
But after I have recovered the spreadsheet, I can delete any of the sheets freely without any crash occurring. It seems that the problem is a bit erratic and I will look into it further.
Phil, could you provide an attachment of a spreadsheet in which you have verified the crash? That would make it a lot easier having a "valid" pivot table to work with. Thanks.
Now when I created a new document and created two new pivot tables, after deleting the second sheet, first sheet, and first pivot table, deleting the second pivot table causes Calc to crash. After recovering the document, I can delete all four. The problem does seem erratic to me and impossible to pinpoint, other than knowing that when deleting sheets with pivot tables, chances are LO might crash.
I can't reproduce a simple problem "Crash when delete sheet with pivot table on it.
[Reproducible] with attached "sample_02neu_crashes.ods" and "LibreOffice 3.4.1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:103)]", I can't tell whether that's exactly the reported problem, but may be a related one?
Steps to reproduce
1. Download and open attached "sample_02neu_crashes.ods"
2. Go to Sheet3 (click Tab)
3. Delete one by one from context menu after right click on Sheet Tab:
Sheet3, sheet2, Pivot Table_Sheet_1_1
4. Go to Sheet1 (click Tab)
5. Delete Sheet1 from context menu after right click on Sheet Tab
Expected: sheet will be deleted or at least a warning that you delete
source for a Pivot table
It would be useful if someone would confirm this behavior before I assign this bug.
Is this your bug? If not, I recommend that you open a new one with sample document and mor detailed desciption
Created attachment 49124 [details]
Sample, see Comment 3
Created attachment 49136 [details]
If I open the attached spreadsheet (MAC OSX 10.6, Intel, LO 3.4.1) and try to delete the sheet "Pivot Table_Sheet_1" LO will crash.
The latest test document does not have such sheet "Pivot Table_Sheet_1". But when I first delete "Pivot Table_Sheet1_1" and then "Pivot Table_Sheet1_2" I get the crash with version from Comment 3 and also with Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI
Delete sheet with Pivot is a very basic, so crash -> Critical and "Most annoying"
Please feel free to reassign if it's not your area!
Ok. I really struggled with this one since the reason why the crash occurs was not obvious to me just by looking at this code
void ScDPCollection::DeleteOnTab( SCTAB nTab )
remove_if(maTables.begin(), maTables.end(), MatchByTable(nTab)),
which (is supposed to) delete the data pilot instances whose output live on the sheet being deleted (specified by nTab index). And maTables is a container of pointers pointing to the data pilot instances (boost::ptr_vector).
But this causes a double-delete, and it was by design as I just found out. For those of you who are curious, turn to Item 33 of Effective STL by Scott Meyers.
Now that I know the "why", I'll try to come up with a fix soon.
Fixed on master
The patch is being reviewed on the mailing list for 3.4.2 inclusion.
Unfortunately the fix missed the boat for 3.4.2. So it will have to wait until 3.4.3, which is actually only a month away.
Waiting for this correction before deploying in professionnal environnements so I'll be glad to check it and test it when 3.4.3rc1 is up! :-)
we needed 3.4.2-rc3 and added this fix there.