Download it now!
Bug 84801 - EDITING: Cutting a table causes a crash
Summary: EDITING: Cutting a table causes a crash
Status: RESOLVED DUPLICATE of bug 82681
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: All All
: high major
Assignee: Not Assigned
Keywords: bibisected, regression
: 84509 (view as bug list)
Depends on:
Reported: 2014-10-08 13:00 UTC by Brandon Milholland
Modified: 2015-12-15 11:03 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Debug trace (89.13 KB, text/plain)
2014-10-10 17:24 UTC, Brandon Milholland
File that will crash (40.52 KB, application/vnd.oasis.opendocument.presentation)
2014-10-10 17:49 UTC, Brandon Milholland

Note You need to log in before you can comment on or make changes to this bug.
Description Brandon Milholland 2014-10-08 13:00:00 UTC
Make an empty table in an Impress presentation. Then right click on it and select "cut". Libreoffice will immediately crash.
Comment 1 Joel Madero 2014-10-08 16:49:58 UTC
Ubuntu 14.04 x64
LibreOffice release

No crash.

@Brandon - can you try with a fresh profile:
Comment 2 tommy27 2014-10-08 19:16:49 UTC
no crash on Win7x64 using
Comment 3 Matthew Francis 2014-10-10 17:07:14 UTC
Also not reproduced on OSX / release and 4.4 master

As above, please try again with a clean profile and let us know if it still happens.

If it does, it would be helpful to have a backtrace from the crash. If you don't know how to do that, please see:
Comment 4 Brandon Milholland 2014-10-10 17:24:53 UTC
Created attachment 107673 [details]
Debug trace
Comment 5 Brandon Milholland 2014-10-10 17:26:28 UTC
It still occurs after I made a fresh profile. But I noticed it only crashes with certain files (an empty file won't crash, but one with several slides full of pictures, diagrams, etc. will). I've attached a backtrace.
Comment 6 Joel Madero 2014-10-10 17:32:31 UTC
Please attach one of those files.
Comment 7 Brandon Milholland 2014-10-10 17:49:17 UTC
Created attachment 107674 [details]
File that will crash
Comment 8 Brandon Milholland 2014-10-10 17:50:49 UTC
I've attached it. Pictures removed to reduce size, so lots of empty slides. But the crash can still be reproduced with the attached file. Make a new slide, choose to insert a table, try to cut the table and it will crash.
Comment 9 Matthew Francis 2014-10-10 18:01:52 UTC
Confirmed on OSX and Linux / LO using the test file

I can't however immediately reproduce this on master. If it's been fixed then something may need backporting

-> NEW
-> OS: All
-> Importance: High
Comment 10 Matthew Francis 2014-10-11 14:30:18 UTC
This was fixed on master by the combination of the following two commits:

commit 5b63c12ace2aec9a659e4b9125f6aa9ff204ed09
Author: Michael Stahl <>
Date:   Fri Aug 29 19:09:29 2014 +0200

    n#708518: sd: check that master page matches when setting parent style
    In ODF import it happened that the parent style of "outline2" etc.
    was always set to the "outline1" style of the first master page in
    the document, but it should be the "outline1" style of the same master
    page as the "outline2".
    (regression from e955433c3574cb602dedba96bc645898f97858bf)
    Change-Id: Ie563d5ee5c2040aeb6ca5c8bb25b195e15ea964e

commit 3669242804e59c4e4d9f3db3d4e4534e223cbd78
Author: Caolán McNamara <>
Date:   Tue Sep 9 15:32:49 2014 +0100

    crashtest: sep should be curSep
    Change-Id: Ic83165ee4af86d0ed0bc77505aae8f50cfc1471a

At first glance these look like good candidates for backporting - need to build a 4.3 to check
Comment 11 Matthew Francis 2014-10-11 15:12:09 UTC
Back to confused. Those two patches have already been cherry-picked onto 4.3 and are in, so there must be another element to fixing the crash that hasn't been backported yet
Comment 12 Terrence Enger 2014-10-25 21:07:11 UTC
In the daily dbgutil bibisect repo, I can confirm that the crash goes away between the versions 2014-09-09 and 2014-09-10, only to be replaced by the misbehaviour reported in bug 85398.

After Matthew's work, I do not know how it can help, but in the 43-all
bibisect repo, I see from `git bisect bad`:

    642edb6eec6b6ba276c33b60cb38d56411e70f4a is the first bad commit
    commit 642edb6eec6b6ba276c33b60cb38d56411e70f4a
    Author: Bjoern Michaelsen <>
    Date:   Tue May 20 14:45:24 2014 +0000

        commit 2bac61013e57013bccac8c9d76482b34b5db7f69
        Author:     Thomas Arnhold <>
        AuthorDate: Sat May 10 18:19:39 2014 +0200
        Commit:     Thomas Arnhold <>
        CommitDate: Sun May 11 01:55:39 2014 +0200
            Change-Id: Iade3fedac5d2f8e978b7dd9c30f001d7d1564946

    :100644 100644 8f7b406390da8ecd41a0a0703ccb3c596d0270ad 7676516ae2308ce13b4a9a89ad5bd4de2cefa380 M	ccache.log
    :100644 100644 100b1b3f429b84659c9ea89781c7af862b5717ac c796aef63228c8907475fa817076f337fee7dc5a M	commitmsg
    :100644 100644 3feb51566ae73b1658d73efe9aa7c8d7fac0e397 ade30f1e4fe61fed4f3695ed7e0e630aa6b58826 M	make.log
    :040000 040000 0f190a6bc7977d598e6b83e40329fd725757c977 9595318cb9a2736916f60d50dfdf3bcefce1781a M	opt

and from `git bisect log`::

    # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
    # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
    git bisect start 'latest' 'oldest'
    # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
    git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
    # good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
    git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d
    # good: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07
    git bisect good a900e72b6357882284c5955bdf939bf14269f5fb
    # skip: [e80660c5a1d812cd04586dae1f22767fc3778c4a] source-hash-07c60c8ee2d1465544a6a39e57bc06b3690b8dfb
    git bisect skip e80660c5a1d812cd04586dae1f22767fc3778c4a
    # good: [df9bcaed2faa2a8d11b19f877cdff3a12a887278] source-hash-6ba9692d8bbe3e3c245aca9a7c928e81178d05f1
    git bisect good df9bcaed2faa2a8d11b19f877cdff3a12a887278
    # good: [741197a13a361480f59eeb3bd1401f984f49f1c0] source-hash-9a61470eb1fa161cba70f2e9c4ea8817dc7f617e
    git bisect good 741197a13a361480f59eeb3bd1401f984f49f1c0
    # bad: [882db5e268e28962bdf805c820a5e031b0df9936] source-hash-383dccc094f8c8c07b4298ce0b7406d18cd61cee
    git bisect bad 882db5e268e28962bdf805c820a5e031b0df9936
    # good: [17f897f0e3734070f0e5c6abd39f2f907f42ac86] source-hash-4041263bde64dcc9a9a225d7f5a171f3b0455724
    git bisect good 17f897f0e3734070f0e5c6abd39f2f907f42ac86
    # good: [5c9e81ec77cd98f952434decf83ec9820d736e56] source-hash-94e3f3e5015e53b5f3c8e5775b668e0bc12ab457
    git bisect good 5c9e81ec77cd98f952434decf83ec9820d736e56
    # bad: [642edb6eec6b6ba276c33b60cb38d56411e70f4a] source-hash-2bac61013e57013bccac8c9d76482b34b5db7f69
    git bisect bad 642edb6eec6b6ba276c33b60cb38d56411e70f4a
    # first bad commit: [642edb6eec6b6ba276c33b60cb38d56411e70f4a] source-hash-2bac61013e57013bccac8c9d76482b34b5db7f69
Comment 13 Julien Nabet 2014-11-01 22:45:59 UTC
Same bt than fdo put in See Also.
Comment 14 Julien Nabet 2014-11-01 22:48:20 UTC
*** Bug 84509 has been marked as a duplicate of this bug. ***
Comment 15 Andras Timar 2014-11-26 15:27:17 UTC

*** This bug has been marked as a duplicate of bug 82681 ***
Comment 16 Robinson Tryon (qubit) 2015-12-15 11:03:35 UTC
Migrating Whiteboard tags to Keywords: (bibisected)