Bug 57197 - undo insertion of table row (or table column) crashes in A11y code
Summary: undo insertion of table row (or table column) crashes in A11y code
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha0+ Master
Hardware: Other Linux (All)
: medium normal
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: target:4.3.0
Keywords: notBibisectable, regression
Depends on:
Blocks:
 
Reported: 2012-11-16 14:43 UTC by Terrence Enger
Modified: 2015-12-17 10:55 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
typescript with `backtrace full` (31.04 KB, text/plain)
2012-11-16 14:43 UTC, Terrence Enger
Details
valgrind output (25.48 KB, text/plain)
2012-11-20 14:44 UTC, Terrence Enger
Details
starting point close to the segfault (9.40 KB, application/vnd.oasis.opendocument.text)
2013-12-10 13:17 UTC, Terrence Enger
Details
typescript of terminal session with backtrace (13.15 KB, text/plain)
2013-12-10 13:18 UTC, Terrence Enger
Details
typescript: 4 times ( run LO, segfault, backtrace ) (58.01 KB, text/plain)
2014-03-25 21:34 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Terrence Enger 2012-11-16 14:43:58 UTC
Created attachment 70161 [details]
typescript with `backtrace full`

(Late breaking news: A segfault is apparent even without selecting the
(only) fow of the table.)

Here is the route to the segfault.  First the short version: create
table with one row, select the row, insert a row, undo.

Longer version:
(*) First column, "app", identifies the window involved; gdb=gnmoe
    terminal, Un1=LibreaOffice.
(*) The spaces in the keystrokes column are for readability in this
    report; never during the test did I type a space into LibreOffice.
(*) The column "typescript lines" shows the result of `wc --lines
    $scriptfile` after things have settled down.

                         typescript  progrem
app keystrokes                lines  action
--- -------------------  ----------  ------------------------------------
gdb                              29  prompt for command
    run <enter>                  66  empty Writer document, "Untitled 1"
Un1 <ctrl><f12>                  68  "Insert Table" dialog
    <alt> R 1 <enter>            73  "Unititled 1", table 1 row by 2
    <properties> R S             73  The table is highlighted
    <properties> R I             73  "Insert Rows" dialog, rows=1
    <enter>                      75  2nd row of table is highlighted
    <ctrl> Z                     80  SIGSEGV
gdb info threads
    backtrace full              328


Just by-the-way ... The same user inputs to LibO commit f1b6058,
pulled 2012-10-13 also led to a segfault, but the backtrace is
superficially different.  I had hopes that commit f4f5c04 "atk:a11y:
unwind re-entrancy/lifecycle hazard issues at least a little bit"
would fix the problem, but it merely changed it.


The LibreOffice here is master commit 2bcae27, pulled 2012-11-15.  The
configuration parameters are
    --enable-symbols
    --enable-dbgutil
    --enable-crashdump
    --disable-build-mozilla
    --without-system-postgresql
    --enable-debug
    --enable-werror
    --without-myspell-dicts
    --without-help

The environment for build and execution is ubuntu-natty (11.04)
32-bit:
    $ uname -a
    Linux cougar-natty 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 18:00:43 UTC 2012 i686 athlon i386 GNU/Linux
    $ gcc --version
    gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
Comment 1 Terrence Enger 2012-11-16 22:30:37 UTC
The segfault is also present in a slightly simpler scenario:
(*) The original table is just 1 by 1
(*) No selection of the original row before insering a second row.

Investigation in gdb shows that one SwTableBox is constructed for
each row.  Undo destructs the second SwTableBox, but
SwCellFrm::GetLayoutRowSpan(), through data member pTabBox,
subsequently calls SwTableBox::getRowSpan for the just-destructed
SwTableBox, and the segfault follows shortly thereafter.
Comment 2 Roman Eisele 2012-11-17 11:15:16 UTC
In a quick test, I could NOT reproduce the problem on Mac OS X 10.6.8 (Intel) with LOdev 4.0.0.0.alpha0+ (Build ID: ed8067; pull time: 2012-11-15 03:54:19).

Following the “short version” or following the comments in “program action” does not give me a crash; pressing Command-Z just correctly removes the newly inserted row again.

So a Linux-only problem?!
Comment 3 Korrawit Pruegsanusak 2012-11-17 14:28:29 UTC
NOT reproduce on Windows 7 x64 Home Premium, with build from tinderbox Win-x86@6, pull time 2012-11-16 23:06:35, core: 4767bbb00dc9eacce6f6d60fd4c55107333cee2d
Comment 4 Terrence Enger 2012-11-20 14:44:26 UTC
Created attachment 70318 [details]
valgrind output

segfault is in abeyance, presumably because --freelist-vol prevents overwriting the destructed object.
Comment 5 Terrence Enger 2012-12-04 13:13:41 UTC
A couple of subsequent observations:

(*) I see the problem only when the inserted row is *before* the
    current row.  This is the default on master but not in earlier
    versions that I have tried.

    Does this suggest that the segfault is related to the warning
    "tabchain in knots" that I have seen raised?  I dunno.

(*) <ctrl><F12> calls up the Insert Table dialog on master and some
    but not all of the earlier versions I have tried.

(*) In the Insert Table dialog the shortcut for number of columns is
    sometimes different from what I wrote originally.

(*) More on the valgrind output ...

    Valgrind option --fill-free brings back the segfault.

    And, in this way, the problem is evident back to bibisect 3.5
    oldest.  However, the problem is not evident--at least, it is not
    evident in the smae way--in Libreoffice delivered with
    ubuntu-natty (11.04) 32-bit, which identifies itself as

        LibreOffice 3.3.4 
        OOO330m19 (Build:401)
        tag libreoffice-3.3.3.1, Ubuntu package 1:3.3.4-0ubuntu1.4


My investigation into the lifecycle issue has produced nothing but my
own discouragement.
Comment 6 Terrence Enger 2012-12-20 15:38:26 UTC
The situation has changed a little bit.

With commit eaf3c60, pulled around 2012-12-19 12:20 UTC, configured
and built the same way in the same environment ...

(*) A couple of attempts ended in exist code '139' rather than a
    segfault.  I do not remember seeing this before.

(*) Still, a segfault shows a backtrace similar to the old attachment,
    at least as far as the function names in the top dozen threads.
Comment 7 Jorendc 2013-01-09 17:23:13 UTC
Terrence Enger - are you looking for independent confirmation of this bug? If not can we go ahead and mark as NEW? We're asking developers and contributors to skip UNCONFIRMED status unless they specifically want independent confirmation of their bug.

Thanks in advance!
Comment 8 Terrence Enger 2013-01-10 18:19:05 UTC
Joren,

I missed the memo about setting status NEW; setting that now.


I think independent confirmation is unlikely because I have to do
oddball things to make make the segmentation fault.

(1) Actually, a debug build is not supposed to be very rare, but it
    does seem to be a bit unusual.

(2) Under valgrind, I have to specify option --fill-free.
Comment 9 Terrence Enger 2013-08-30 20:04:48 UTC
I have tried this again with master commit 73ab2af, pulled 2013-08-19,
built on ubuntu-natty (11.04) 32-bit.  When executing on the build
system, the segfault happens.  When executin on ubuntu-quantal (12.10)
64-bit, no problem is evident.

Terry.
Comment 10 Terrence Enger 2013-12-10 13:17:06 UTC
Created attachment 90574 [details]
starting point close to the segfault

Here is an easier way to show the segfault.  I am calling it the same
segfault because of the similarity of the top five frames in the
backtraces.

(1) Download and open the attached file undo_segfault.odt.  The caret
    is at the end of the text in row 2 column 2 of the table.

(2) Type "<tab>".  The program adds row 3 to the table.

(3) Type "<ctrl>+Z".  SEGFAULT.


This happens on master commit b092637, fetched 2012-12-06 17:20 UTC,
configured:
    --enable-option-checking=fatal
    --enable-dbgutil
    --enable-crashdump
    --without-system-postgresql
    --without-myspell-dicts
    --with-extra-buildid
    --without-doxygen
    --with-external-tar=/home/terry/lo_hacking/git/src
built and and running debian-wheezy.

For comparison, LibreOffice supplied with debian-wheezy, version
3.5.2.4 (Build ID: 350m1` (Build:2)), places the cursor at the start
of row 1 cell 1 when it opens the file.  I have to move the cursor
first. Then "<tab><ctrl>+Z" correctly adds row 3 to the table and
removes it again.  So, I am setting keyword "regression".

The crash is not evident in bibisect versions
    40 oldest
    40+ latest
I take this to indicate that the crash is peculiar to debug builds,
and I conclude that the failed attempts to replicate the problem on
Win and OSX do not indicate very much.  (Of course, the all-nines
value of `this` in frame zero of the backtrace is peculiar to a debug
build.)  So, I am setting Whiteboard "NotBibisectable".
Comment 11 Terrence Enger 2013-12-10 13:18:44 UTC
Created attachment 90575 [details]
typescript of terminal session with backtrace
Comment 12 Björn Michaelsen 2014-03-23 15:11:12 UTC
@Terrence: Could you check if this is trigger by enable-dbgutil exclusively? That is build once with and once without and see if only one crashes.
Comment 13 Terrence Enger 2014-03-23 21:15:27 UTC
Thank you, Björn, for reminding me of this bug.

A quick test shows that my debug build still produces segfaults after
changes to my environment, but I see differences in behaviour and the
backtraces.  I should be able to run the comparison you ask for in
about 48 hours.
Comment 14 Terrence Enger 2014-03-25 21:34:23 UTC
Created attachment 96383 [details]
typescript: 4 times ( run LO, segfault, backtrace )

Short version: Segmentation faults from LibreOffice configured both
with and without --enable-dbgutil.

Long version
------------

I am back with commit 8931ab3, first fetched 2013-03-23 02:37 UTC,
configured both --enable-dbgutil and without that parameter.  The
other configuration parameters are:

    --enable-option-checking=fatal
    --enable-crashdump
    --without-system-postgresql
    --without-myspell-dicts
    --with-extra-buildid
    --without-doxygen
    --with-external-tar=/home/terry/lo_hacking/git/src

I did the builds and these tests on debian-wheezy 64-bit.


First, some differences from my presvious reports are visible at the
user level:

(*) I never reached the end of the long STR from the bug description.
    LibreOffice terminated with last <Enter>, leaving no opportunity
    to type the final <ctrl>+Z.  I am confident that this is a change
    in the program behaviour.

(*) In the short STR from comment 10, I wrote that Libre Office places
    the caret in row 2 column 2 upon first display of file
    undo_segfault.odt.  I hate to think that I was so careless as to
    misstate what I saw, but both of the current builds from master
    and LO 3.5.4.2 as delivered with debian-wheezy place the caret at
    the start of row 1 column 1.  Sigh.  Anyway, in the current test
    of the short STR, I did additionally:

        (1.1) Type <tab><tab><tab>


So, in the attached typescript, you can see:

(*) line  11 :  run long STR, LO configured with dbgutil
(*) line  66 :  gdb;
(*) line 190 :  run long STR, LO configured without dbgutil
(*) line 224 :  gdb
(*) line 307 :  run short STR, LO configured with dbgutil
(*) line 314 :  gdb
(*) line 429 :  run short STR, LO configured without dbgutil
(*) line 433 :  gdb
Comment 15 Commit Notification 2014-05-02 22:59:41 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bc0c939270a45469b8f22008288b5e4a4d9c9861

fdo#57197: sw: fix crash on Undo of table row/column insert



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.
Comment 16 Michael Stahl (CIB) 2014-05-02 23:00:05 UTC
Insert Columns also crashes in the same way

it looks like the actual invalid access problem is quite old.

fixed on master
Comment 17 Terrence Enger 2014-05-04 17:20:02 UTC
My debug build of commit bc0c939 runs without problem through the
short STR as in comment 10, but alas it still segfaults on the long
STR from the bug description; the function names in the backtrace
match the first backtrace in attachment from comment 14.
Comment 18 Michael Stahl (CIB) 2014-05-05 21:42:06 UTC
ah, on thurdsay i recognized there are 2 different crashes here
but on friday i had already forgotten that :)

the other crash is apparently a regression from 76c549eb01dcb7b5bf28a271ce00e386f3d388ba...

will push a fix for the remaining problems to master in some minutes.
Comment 19 Commit Notification 2014-05-05 22:00:30 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cd83ef996b09907d669d686d1a33db5a8f08f72d

fdo#57197: sw: check that cells are still alive ...



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.
Comment 20 Commit Notification 2014-05-05 22:00:45 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a82de8698a4569d043a3f656a4afbe21a952f8d3

fdo#57197: sw: fix crash on Undo of table row insert on 1-row table



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.
Comment 21 Terrence Enger 2014-05-06 23:24:51 UTC
With my debug build of commit f585323, fetched 2014-05-06 0300 UTC,
there is no preblem, neither with the long STR from the description
nor with the short STR from comment 10.

Thank you, Michael.
Comment 22 Commit Notification 2015-07-23 13:27:20 UTC
Varun committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf5d569bb6af90195a339bb3b1a19d763d2210af

Added test for tdf#57197 table row/column insert undo crash

It will be available in 5.1.0.

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.
Comment 23 Robinson Tryon (qubit) 2015-12-17 10:55:03 UTC Comment hidden (obsolete)