Created attachment 90982 [details] backtrace of the crash Hi. I have a crash in Calc 4.2 when sorting a table if I select the entire column by clicking on its header. It seems that the crash depend on a particular file. Unfortunately this file is confidential. Steps to reproduce: 1/ select the entire column by clicking on its header (the letter) 2/ click on the button to test 3/ in the dialog which appears, accept to extent the selection If I run LO in non debug mode I get an error messagebox saying "Vector::_M_range_check" If I run LO 4.2 in debug mode, I get a crash due to an assertion in mdds which failed : see the attached backtrace. I will try to modify my file to make a non-confidential test file. Best regards. JBF
I have the same crash on the version 4.2.0.0.beta2 build by TDF. Best regards. JBF
Forgot to add the buildID : Version: 4.2.0.1.0+ Build ID: 68a9ac8623b6b80544e9ab117804cc19c7794f44
Hi Kohei, As the backtrace seems to involve mdds, this bug may be interesting for you ;-) Best regards. JBF
Created attachment 90988 [details] another backtrace If I build LO 4.2 without the option --enable-assert-always-abort the program crashes by segmentation fault. Hope this helps. Best regards. JBF
Easily reproducible by selecting an entire column in an empty sheet and invoking Data->Sort. Though the backtrace suggests a different scenario, would be nice to have a reproducer document for this case and see if my fix will indeed fix that as well.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=efb0412eda9eb33e45b27d9d7d6cc94e4211a82c fixed crash when invoking sort on an empty sheet's entire column, fdo#72874 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=585b25194bb7c24dde6d21f3674b26decffe5ed7&h=libreoffice-4-2 fixed crash when invoking sort on an empty sheet's entire column, fdo#72874 It will be available in LibreOffice 4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@JBFaure: Could you please try in one of the next builds if that also fixes your problem? Thanks.
Created attachment 90999 [details] test document which crashes LO 4.2 Hi Eike, here is a minimal test document. Steps to reproduce the crash: 1/ open the test document with LibreOffice (Version: 4.2.0.1.0+ Build ID: 68a9ac8623b6b80544e9ab117804cc19c7794f44) 2/ click on the header of the A column to select it entirely 3/ click on the second sort button (Sort Descending) Your patch does not fix this crash. The cause of the crash is related to the hyperlinks in column B (B48 and B49). No crash if you select one of both cells and hit ctrl+M to remove the hyperlink formatting. Note: if you look carefully the sorted table, you will see that the remaining hyperlink has been lost. I do not know if that is another bug. Best regards. JBF
Created attachment 91063 [details] very minimalistic reproducer case On B3 click SortAscending, crash under ScColunm::SwapRows(). On D3 click SortDescending, edit cell with link is gone.
I suspect some mdds type confusion and resulting bad iterators of a wrong block type. But actually I don't know anything ;-) Back to the pool for Kohei to pick up.
I'll take it.
So, turns out that this was a simple case of function overloading gone wrong, though it took me a whole day to finally realize what we were doing wrong.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=21f053e2dd2867489a4d5823d9210c4368f4d115 fdo#72874: Strip const-ness from pointer value when setting it to storage. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dbd8709af0545b0372c28c5ff36effba68bca580&h=libreoffice-4-2 fdo#72874: Strip const-ness from pointer value when setting it to storage. It will be available in LibreOffice 4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Both the original and minimal test documents get sorted without crash. I'll call it fixed.
A little C++ implicit type conversion I've learned from this is that, when you pass a const pointer of a data type to a overloaded function and you don't have a version that takes a const pointer of that type, the boolean version of the function gets picked even if you have a version that takes a non-const pointer of the same exact type. For example, the following code #include <iostream> using namespace std; class MyClass {}; void printMe(MyClass* p) { cout << "pointer" << endl; } void printMe(bool b) { cout << "boolean" << endl; } int main() { MyClass* p = new MyClass; const MyClass* p2 = p; printMe(p); printMe(p2); delete p; return 0; } generates pointer boolean as its output. But when you add void printMe(const MyClass* p) { cout << "const pointer" << endl; } to it, it outputs pointer const pointer
Verified on version 4.2.0.1.0+ Build ID: e1f4de66afa5f0cf54f90a1fed150dc200680da2 under Ubuntu 13.10 x86-64: no crash for both test documents. Thank you very much Kohei !!! Best regards. JBF