Bug 76607 - vector::_M_range_check crash when sorting mixed formula and value
Summary: vector::_M_range_check crash when sorting mixed formula and value
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: Other All
: medium critical
Assignee: Kohei Yoshida
URL:
Whiteboard: target: 4.3.0 target:4.2.5
Keywords: regression
: 79212 (view as bug list)
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2014-03-25 21:43 UTC by Laurent Balland
Modified: 2014-05-25 15:08 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Test file for the sorting procedure described in bug report (51.23 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-03-25 21:43 UTC, Laurent Balland
Details
valgrind log (166.38 KB, text/plain)
2014-04-11 18:59 UTC, Michael Meeks
Details
the right log now (36.21 KB, text/plain)
2014-04-11 19:02 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent Balland 2014-03-25 21:43:57 UTC
Created attachment 96384 [details]
Test file for the sorting procedure described in bug report

Description: Quite strange bug. This bug appeared in a huge file and generated a dialog with "vector::_M_range_check" then crash. I tried to simplify the file which now simply crash when sorting specific columns in a specific order.

Steps to reproduce:
1. Open attached file
2. Select all data (with mouse or keyboard) A1:E17
3. Use Tab to move to column C
4. Click on button "Sort Descending" or "Sort Ascending"
5. Hit Tab once to move to column D
6. Click on button "Sort Descending"

Current behavior:
crash

Expected behavior:
no crash

The crash is specific to this order of sorting operations. If you do some previous sorts, then there is no crash. If you directly sort column D there is no crash.
The crash is specific to cell E11 which does not contain a formula (=B11) but a text (same crash with a value). If you replace text with the regular formula =B14 like other rows, then there is no crash.
I was unable to remove some other rows without loosing the crash with this procedure.

Confirmed with Version: 4.3.0.0.alpha0+
Build ID: e5d7a360e68b1725ee28abc5c76db5c4023dce88

Confirmed with Version: 4.2.0.4
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Comment 1 pierre-yves samyn 2014-03-26 08:07:26 UTC
Hello

On windows XP & Version: 4.2.3.1
Build ID: 3d4fc3d9dbf8f4c0aeb61498a81f91c5b7922f13
I do not reproduce with *those* steps.

I reproduce the crash by following these steps:

1. Open attached file
2. Select any cell in column B (e.g. B1)
3. Click on button "Sort Ascending"

Expected & Actual results : the table is sorted

4. Click on button "Sort Descending"

Crash

The crash also occurs if you select any cell in column E (e.g. E1) in step 2
(the cells in column E are calculated from column B)

Regards
Pierre-Yves
Comment 2 Laurent Balland 2014-03-26 08:58:15 UTC
Thanks Pierre-Yves: your simpler procedure results in crash also for me with Version: 4.2.3.1
Build ID: 3d4fc3d9dbf8f4c0aeb61498a81f91c5b7922f13

NOT reproduce with Version: 4.1.5.3
Build ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24

add Regression as Keyword
Comment 3 Laurent Balland 2014-03-26 09:17:53 UTC
With Version: 4.3.0.0.alpha0+
Build ID: 9278df2c21fed09b6b10465ca33b227ad7c49b41
TinderBox: Win-x86@47-TDF, Branch:MASTER, Time: 2014-03-19_08:44:54

I cannot reproduce crash with procedure neither of comment 1 nor of comment 2

However, if with procedure of comment 1, I do some other sorts on column C, D and E, it ends with a crash.
Comment 4 Laurent Balland 2014-03-26 13:03:38 UTC
Behavior is different with different version and OS it seems.

On OpenSuse 13.1, fresh master compiled today 2014-03-26 Version: 4.3.0.0.alpha0+
Build ID: 1c00c606d125330026689192a8146c95084118ca

I reproduce crash with procedure in comment 2 on step 3: on first sort in column B in ascending order (no immediate crash in descending order).

However, I can confirm an important point: crash occurs if the same column (column E in test file) contains formulas and values. There is no crash if columns contain either only formulas or only values. I tested on the original file where I replaced forced values with regular formula and then there is no more crash.
Comment 5 Ron Johnson 2014-04-11 02:13:26 UTC
This happens to me when running the LO-supplied 4.2.3.3 x86-64 .deb binaries.  It didn't *not* occur in v4.2.1.  (I skipped v4.2.2.)

The crash happens when I delete a row which has a formula and constant data in it.  The cells above and below the formula also had formulas, and they referenced each other.  Deleting the constant data had no effect on whether the file crashed.

NO SORTING NECESSARY to invoke the crash!!
Comment 6 Michael Meeks 2014-04-11 18:58:58 UTC
running in valgrind from master / 7692b91939ea7a816e1dfaa10c36d8fd5cd7a759 I get these traces:

==3857== Invalid read of size 4
==3857==    at 0x16E692CA: ScFormulaCell::SetCellGroup(boost::intrusive_ptr<ScFormulaCellGroup> const&) (operator_bool.hpp:13)
==3857==    by 0x16F625F5: sc::SharedFormulaUtil::unshareFormulaCell(std::pair<mdds::__mtv::iterator_base<mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> > >::iterator_trait, mdds::__mtv::private_data_forward_update<mdds::__mtv::iterator_value_node<unsigned int, mdds::mtv::base_element_block> > >, unsigned int> const&, ScFormulaCell&) (sharedformula.cxx:293)
==3857==    by 0x16DC83EF: ScColumn::DetachFormulaCell(std::pair<mdds::__mtv::iterator_base<mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> > >::iterator_trait, mdds::__mtv::private_data_forward_update<mdds::__mtv::iterator_value_node<unsigned int, mdds::mtv::base_element_block> > >, unsigned int> const&, ScFormulaCell&) (column3.cxx:338)
==3857==    by 0x16D9EF99: ScColumn::SwapRow(long, long) (column.cxx:886)
==3857==    by 0x16E9C031: ScTable::SwapRow(long, long) (table3.cxx:571)
==3857==    by 0x16E9C239: ScTable::SortReorder(ScSortInfoArray*, ScProgress*) (table3.cxx:361)
==3857==    by 0x16E9D3E2: ScTable::Sort(ScSortParam const&, bool, ScProgress*) (table3.cxx:690)
==3857==    by 0x16DF49CB: ScDocument::Sort(short, ScSortParam const&, bool, ScProgress*) (documen3.cxx:1374)
==3857==    by 0x17067F4C: ScDBDocFunc::Sort(short, ScSortParam const&, bool, bool, bool) (dbdocfun.cxx:575)
==3857==    by 0x172196DF: ScDBFunc::Sort(ScSortParam const&, bool, bool) (dbfunc.cxx:279)
==3857==    by 0x172197E3: ScDBFunc::UISort(ScSortParam const&, bool) (dbfunc.cxx:270)
==3857==    by 0x17212AEE: ScCellShell::ExecuteDB(SfxRequest&) (cellsh2.cxx:381)
==3857==    by 0x172068D4: SfxStubScCellShellExecuteDB(SfxShell*, SfxRequest&) (scslots.hxx:7002)
...
==3857==  Address 0x18746eb4 is 28 bytes inside a block of size 88 free'd
==3857==    at 0x402B6AD: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3857==    by 0x16D8C79F: mdds::default_deleter<ScFormulaCell> std::for_each<__gnu_cxx::__normal_iterator<ScFormulaCell**, std::vector<ScFormulaCell*, std::allocator<ScFormulaCell*> > >, mdds::default_deleter<ScFormulaCell> >(__gnu_cxx::__normal_iterator<ScFormulaCell**, std::vector<ScFormulaCell*, std::allocator<ScFormulaCell*> > >, __gnu_cxx::__normal_iterator<ScFormulaCell**, std::vector<ScFormulaCell*, std::allocator<ScFormulaCell*> > >, mdds::default_deleter<ScFormulaCell>) [clone .isra.190] (default_deleter.hpp:40)
==3857==    by 0x16D8D759: mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> >::overwrite_values(mdds::mtv::base_element_block&, unsigned int, unsigned int) (multi_type_vector_types.hpp:587)
==3857==    by 0x16D934FD: mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> > >::set_new_block_to_middle(unsigned int, unsigned int, unsigned int, bool) (multi_type_vector_def.inl:2645)
==3857==    by 0x16DB4BF3: mdds::__mtv::iterator_base<mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> > >::iterator_trait, mdds::__mtv::private_data_forward_update<mdds::__mtv::iterator_value_node<unsigned int, mdds::mtv::base_element_block> > > mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> > >::set_cell_to_middle_of_block<svl::SharedString>(unsigned int, unsigned int, unsigned int, svl::SharedString const&) (multi_type_vector_def.inl:619)
==3857==    by 0x16DB787C: mdds::__mtv::iterator_base<mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> > >::iterator_trait, mdds::__mtv::private_data_forward_update<mdds::__mtv::iterator_value_node<unsigned int, mdds::mtv::base_element_block> > > mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> > >::set_impl<svl::SharedString>(unsigned int, unsigned int, unsigned int, svl::SharedString const&) (multi_type_vector_def.inl:367)
==3857==    by 0x16DB79FE: mdds::__mtv::iterator_base<mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> > >::iterator_trait, mdds::__mtv::private_data_forward_update<mdds::__mtv::iterator_value_node<unsigned int, mdds::mtv::base_element_block> > > mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> > >::set<svl::SharedString>(mdds::__mtv::iterator_base<mdds::multi_type_vector<mdds::mtv::custom_block_func3<mdds::mtv::default_element_block<52, svl::SharedString>, mdds::mtv::noncopyable_managed_element_block<53, EditTextObject>, mdds::mtv::noncopyable_managed_element_block<54, ScFormulaCell> > >::iterator_trait, mdds::__mtv::private_data_forward_update<mdds::__mtv::iterator_value_node<unsigned int, mdds::mtv::base_element_block> > > const&, unsigned int, svl::SharedString const&) (multi_type_vector_def.inl:289)
==3857==    by 0x16D9F866: ScColumn::SwapRow(long, long) (column.cxx:1068)
==3857==    by 0x16E9C031: ScTable::SwapRow(long, long) (table3.cxx:571)
==3857==    by 0x16E9C239: ScTable::SortReorder(ScSortInfoArray*, ScProgress*) (table3.cxx:361)
==3857==    by 0x16E9D3E2: ScTable::Sort(ScSortParam const&, bool, ScProgress*) (table3.cxx:690)
==3857==    by 0x16DF49CB: ScDocument::Sort(short, ScSortParam const&, bool, ScProgress*) (documen3.cxx:1374)
==3857==    by 0x17067F4C: ScDBDocFunc::Sort(short, ScSortParam const&, bool, bool, bool) (dbdocfun.cxx:575)
==3857==    by 0x172196DF: ScDBFunc::Sort(ScSortParam const&, bool, bool) (dbfunc.cxx:279)
==3857==    by 0x172197E3: ScDBFunc::UISort(ScSortParam const&, bool) (dbfunc.cxx:270)
==3857==    by 0x17212AEE: ScCellShell::ExecuteDB(SfxRequest&) (cellsh2.cxx:381)

I'll attach the full log.
Comment 7 Michael Meeks 2014-04-11 18:59:22 UTC
Created attachment 97234 [details]
valgrind log
Comment 8 Michael Meeks 2014-04-11 19:02:39 UTC
Created attachment 97235 [details]
the right log now
Comment 9 Michael Meeks 2014-04-11 19:09:29 UTC
the trace is not so wonderful so:

Program received signal SIGSEGV, Segmentation fault.
0xa794d2d4 in ScFormulaCell::SetCellGroup (this=0x8d1c168, xRef=...) at /data/opt/libreoffice/master/sc/source/core/data/formulacell.cxx:3528
3528	            pCode = mxGroup->mpCode->Clone();

is the crash.
Comment 10 Kohei Yoshida 2014-04-17 01:43:44 UTC
I'm looking at this right now.
Comment 11 Kohei Yoshida 2014-04-17 03:30:56 UTC
This and Bug 72741 need to be fixed together since they both are affected by the same root issue.
Comment 12 Kohei Yoshida 2014-04-18 18:16:10 UTC
Just FYI, fixing this will take a while. There are quite a lot of bases to cover.
Comment 13 Kohei Yoshida 2014-04-23 15:45:26 UTC
I'm almost done here, FYI.
Comment 14 Kohei Yoshida 2014-04-24 01:09:14 UTC
Just merged a whole bunch of changes to master that should fix this.

For 4.2: https://gerrit.libreoffice.org/9144
Comment 15 Kohei Yoshida 2014-04-25 13:00:53 UTC
This one is now fixed.
Comment 16 Laurent Balland 2014-04-26 06:14:34 UTC
Verified with Version: 4.2.5.0.0+
Build ID: 6b7f07e3dbd990fd63c707d9297b4715e6e3957d

Thanks Kohei!
Comment 17 Laurent Balland 2014-05-25 15:08:08 UTC
*** Bug 79212 has been marked as a duplicate of this bug. ***