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
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.
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?!
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
Created attachment 70318 [details] valgrind output segfault is in abeyance, presumably because --freelist-vol prevents overwriting the destructed object.
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.
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.
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!
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.
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.
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".
Created attachment 90575 [details] typescript of terminal session with backtrace
@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.
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.
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
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.
Insert Columns also crashes in the same way it looks like the actual invalid access problem is quite old. fixed on master
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.
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.
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.
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.
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.
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.
Migrating Whiteboard tags to Keywords: (NotBibisectable) [NinjaEdit]