Bug 62653 - EDITING: segfault on nested table delete
Summary: EDITING: segfault on nested table delete
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.5.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: mab4.1
  Show dependency treegraph
 
Reported: 2013-03-22 21:33 UTC by Walter
Modified: 2013-12-13 09:33 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
attachment-1168-0.html (1.69 KB, text/html)
2013-06-03 11:12 UTC, Walter
Details
attachment-1168-1.dat (1 bytes, multipart/alternative)
2013-06-03 11:12 UTC, Walter
Details
Schemi di Diritto Romano.odt (30.61 KB, application/vnd.oasis.opendocument.text)
2013-06-03 11:12 UTC, Walter
Details
Diritto Romano_2012-2013_2lati.odt (258.66 KB, application/vnd.oasis.opendocument.text)
2013-06-03 11:12 UTC, Walter
Details
WinDbg Crash Debug on LO 412dev (27.67 KB, text/plain)
2013-09-12 10:01 UTC, Timur
Details
backtrace from segfault, with symbols, GNU/Linux (44.52 KB, text/plain)
2013-11-12 18:30 UTC, Terrence Enger
Details
typescript of valgrind session (260.74 KB, text/plain)
2013-11-12 22:34 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Walter 2013-03-22 21:33:07 UTC
Problem description: After a series of Copy - Paste actions (especially when tables are involved but not only), Writer crashes. It does not save before closing (which is a very useful tool). I must say that the 3.6.5.2 version is much more stable than 3.3.0 but it still happened a number of times.

Steps to reproduce:
1. Copy some formatted text
2. Paste
3. Redo steps 1 and 2

Current behavior: the mouse pointer changes into a rotating blue arrow (like when an application is loading) and locks at this point

Expected behavior: that the text copied from clipboard is pasted correctly or at least that an error is shown, giving the option of trying to copy the text again.

Thanks for your effort
Walter
Operating System: Windows 7
Version: 3.6.5.2 release
Comment 1 Jorendc 2013-06-01 16:21:02 UTC
Hi,

Thanks for reporting! But I can not reproduce this using Linux Mint 15 x64 with LibreOffice 4.0.3. Did some tests by formatting some text, copying it around, undo-and redo it etc etc... no crash.

So, is it please possible to attach a sample document with formatted text you can reproduce this issue? In that case we can try to reproduce it with the same document.

Also, is this still reproducible using LibreOffice 4.0.x ?

Thanks in advance for your extra information,
Joren
Comment 2 Walter 2013-06-03 11:12:44 UTC
Created attachment 80205 [details]
attachment-1168-0.html

Hi Jorendc,

Yes it is still being reproduced under 4.0.2.2, though it is more stable.
The difficulty is that it cannot be reproduced by some file. It is not some
command that is crashing the application. It seems more vulnerable when
tables and nested tables are involved but in these years using LibreOffice
I never managed to find a pattern. The same Copy-Paste operation works
after reloading LibreOffice. What I suspect is that something gets mixed up
in the Clipboard. It might be an issue specific to Windows. Is there some
crash error report which I could send to you.

I have been uninstalling and reinstalling versions of
OpenOffice/LibreOffice quite some time. My settings are kept throughout the
changes, like the default template, dictionaries and plugins. This is a
good thing in itself but could this cause a problem for this bug? I guess
it should not but i thought I'd ask.


I have managed to reproduce a similar crash which might be connected with
these two files:
1. open both
2. Goto p 70 of Diritto Romano_2013-2013_2lati.odt
3. Copy a table with some text before and after it
3. Goto p. 1 of Schemi di Diritto Romano
4. Paste the contents
5. Go into one of the columns of the pasted table
6. Paste the contents again
7. Put the cursor out of the table and select all the text
8. Press Backspace

This procedure reproduces the crash everytime on my computer (Windows 7,
x64, LibreOffice 4.0.2.2)

Hope this helps
Walter
Comment 3 Walter 2013-06-03 11:12:45 UTC
Created attachment 80206 [details]
attachment-1168-1.dat
Comment 4 Walter 2013-06-03 11:12:45 UTC
Created attachment 80207 [details]
Schemi di Diritto Romano.odt
Comment 5 Walter 2013-06-03 11:12:45 UTC
Created attachment 80208 [details]
Diritto Romano_2012-2013_2lati.odt
Comment 6 Timur 2013-09-12 10:01:15 UTC
Created attachment 85707 [details]
WinDbg Crash Debug on LO 412dev

My congrats to Walter on this bug and it's description :)

I confirm the same with
libreoffice-4-1~2013-08-29_15.01.24_LibreOfficeDev_4.1.2.0.0_Win_x86.msi (pre 4.1.2)

Crash debug attached. Please confirm validity.
Comment 7 Timur 2013-09-12 10:06:13 UTC
I changed the title from "Copy Paste Crash" to "Crash on nested table delete".
Comment 8 Terrence Enger 2013-11-12 18:19:23 UTC
I have reproduced a crash, and am changing summary to say "segfault"
and the platform to "All".

For specificity:
(*) My command line was (all one line)
        $( cat lo_hacking/forrunning )/instdir/program/soffice
             --norestore
             ~/lo_hacking/notes/bug_06xxxx/bug_062653/Diritto\ Romano_2012-2013_2lati.odt
             ~/lo_hacking/notes/bug_06xxxx/bug_062653/Schemi\ di\ Diritto\ Romano.odt

(*) I copied from page "59 70/165" of file Dir..., starting from words
    "Se il latimo" to the next instance of the same words.

(*) I pasted in file Sch..., first before the words "Per diretto" and
    then at the top of the second column, i.e., before the text "32o
    Sililmente"

(*) <backspace> appeared to work correctly.  To my surprise, the
    document-modified flag seems not to have been set at this point.

(*) I took menu option File > Exit.  Progam segfaulted from an STL
    iterator.  Bah, another one of those!

Backtrace coming.


My LibreOffice is master commit e9fdc84, fetched around 2013-11-09 00:23 UTC, configured with

    --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 executing on debian-wheezy:

    terry@debian:~$ uname -a
    Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

    terry@debian:~$ gcc --version
    gcc (Debian 4.7.2-5) 4.7.2
    Copyright (C) 2012 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    terry@debian:~$ java -version
    java version "1.6.0_27"
    OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1~deb7u1)
    OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
Comment 9 Terrence Enger 2013-11-12 18:30:15 UTC
Created attachment 89104 [details]
backtrace from segfault, with symbols, GNU/Linux
Comment 10 Terrence Enger 2013-11-12 22:34:38 UTC
Created attachment 89109 [details]
typescript of valgrind session

The following accidents make this run different from the one which led
to the previously attached backtrace

(*) Platform for execution is ubuntu-quantal.

(*) On the command line I named file Sch... twice and omitted file
    Dir... So, valgrind output, compared to the earlier backtrace, has
    an extra excution of File > Open menu options.

(*) LibreOffice presented two messages "...locked, really open?".  I
    said Yes, of course.

(*) I am not sure that I copied the same text.  

(*) The destination document definititely had its dobument-modified
    flag set.
Comment 11 Timur 2013-12-12 09:43:00 UTC
This seems to be corrected in LO 4.1.4. I tested with libreoffice-4-1~2013-12-10_13.59.45_LibreOfficeDev_4.1.5.0.0_Win_x86.

This may be a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=70358. Anyway, works for me.
Comment 12 Timur 2013-12-13 09:33:49 UTC
I close as Worksforme, because Bug 70358 was marked for version 4.1 and this one for 3.6. 
Feel free to reopen if reproduced again.