libreoffice always crashes when I do this

[Bjlockie]

I reported the crash using ubuntu-bug and I think it uploaded the .crash but then did nothing after.
Maybe it didn't upload.
I put it here:
http://lockie.ca/libreoffice/_usr_lib_libreoffice_program_soffice.bin.1000.crash

The way to crash it is to open this file:
http://lockie.ca/libreoffice/convertible_sofas
1. select the columns E to G
2. press control-c to copy them
3. observe the crash

If you create a new calc document and try to copy 2 empty columns, it freezes but doesn't crash.

Version: 6.1.2.1
Build ID: 1:6.1.2-0ubuntu1.1
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5;
Locale: en-CA (en_CA.UTF-8); Calc: group threaded

$ apt-cache policy libreoffice
libreoffice:
  Installed: (none)
  Candidate: 1:6.1.2-0ubuntu1.1
  Version table:
     1:6.1.2-0ubuntu1.1 500
        500 http://archive.ubuntu.com/ubuntu cosmic-updates/universe amd64 Packages
     1:6.1.2-0ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu cosmic/universe amd64 Packages

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: libreoffice (not installed)
ProcVersionSignature: Ubuntu 4.18.0-11.12-generic 4.18.12
Uname: Linux 4.18.0-11-generic x86_64
ApportVersion: 2.20.10-0ubuntu13.1
Architecture: amd64
Date: Thu Nov 22 13:10:52 2018
InstallationDate: Installed on 2018-11-15 (7 days ago)
InstallationMedia: Lubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

[tml (tml)]

Description:
In a developer build, with --enable-debug:

make debugrun
r --calc
add some numbers into A1 and A2
click the column header, Control-C
Control-Q, click "Don't Save"
Boom. Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.

Stack trace:

> #0 0x00007ffff73e6530 in __memset_sse2_unaligned_erms () at /lib64/libc.so.6
> #1 0x00007fffe0095475 in _cairo_xlib_surface_create_similar_shm () at /lib64/libcairo.so.2
> #2 0x00007fffe0068b17 in cairo_surface_create_similar_image () at /lib64/libcairo.so.2
> #3 0x00007fffe0068d08 in cairo_surface_create_similar () at /lib64/libcairo.so.2
> #4 0x00007fffec574d4d in SvpSalVirtualDevice::SetSizeUsingBuffer(long, long, unsigned char*) (
> this=0x2f55e10, nNewDX=85, nNewDY=17895697, pBuffer=0x0) at /ssd1/lo/fedora/vcl/headless/svpvd.cxx:107
> #5 0x00007fffec574ae7 in SvpSalVirtualDevice::SetSize(long, long) (this=0x2f55e10, nNewDX=85, nNewDY=17895697)
> at /ssd1/lo/fedora/vcl/headless/svpvd.cxx:63
> #6 0x00007fffec262de2 in VirtualDevice::InnerImplSetOutputSizePixel(Size const&, bool, unsigned char*) (
> this=0x26eeb10, rNewSize=Size = {...}, bErase=true, pBuffer=0x0) at /ssd1/lo/fedora/vcl/source/gdi/virdev.cxx:304
> #7 0x00007fffec263376 in VirtualDevice::ImplSetOutputSizePixel(Size const&, bool, unsigned char*) (this=0x26eeb10, rNewSize=Size = {...}, bErase=true, pBuffer=0x0) at /ssd1/lo/fedora/vcl/source/gdi/virdev.cxx:379
> #8 0x00007fffec263690 in VirtualDevice::SetOutputSizePixel(Size const&, bool) (this=0x26eeb10, rNewSize=Size = {...}, bErase=true)
> at /ssd1/lo/fedora/vcl/source/gdi/virdev.cxx:425
> #9 0x00007fffc320cfe6 in ScTransferObj::GetData(com::sun::star::datatransfer::DataFlavor const&, rtl::OUString const&) (
> this=0x686c640, rFlavor=...) at /ssd1/lo/fedora/sc/source/ui/app/transobj.cxx:378
> #10 0x00007fffee789e8c in TransferableHelper::getTransferData2(com::sun::star::datatransfer::DataFlavor const&, rtl::OUString const&) (this=0x686c640, rFlavor=..., rDestDoc="") at /ssd1/lo/fedora/svtools/source/misc/transfer.cxx:377
> #11 0x00007fffee789009 in TransferableHelper::getTransferData(com::sun::star::datatransfer::DataFlavor const&) (this=0x686c640, rFlavor=...) at /ssd1/lo/fedora/svtools/source/misc/transfer.cxx:275
> #12 0x00007fffee789093 in non-virtual thunk to TransferableHelper::getTransferData(com::sun::star::datatransfer::DataFlavor const&) ()
> at /usr/bin/../lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/stl_iterator.h:794
> #13 0x00007fffd1267f3a in VclToGtkHelper::setSelectionData(com::sun::star::uno::Reference<com::sun::star::datatransfer::XTransferable> const&, _GtkSelectionData*, unsigned int) (this=0x22fb0b0, rTrans=uno::Reference to (ScTransferObj *) 0x686c668, selection_data=0x7ffffffedb50, info=5) at /ssd1/lo/fedora/vcl/unx/gtk3/gtk3gtkinst.cxx:488
> #14 0x00007fffd1267d44 in VclGtkClipboard::ClipboardGet(_GtkSelectionData*, unsigned int) (
> this=0x22fafa0, selection_data=0x7ffffffedb50, info=5) at /ssd1/lo/fedora/vcl/unx/gtk3/gtk3gtkinst.cxx:357
> #15 0x00007fffd126a2ef in (anonymous namespace)::ClipboardGetFunc(_GtkClipboard*, _GtkSelectionData*, unsigned int, void*) (selection_data=0x7fffff...

[tml (tml)]

Related to bug #69460. No idea why this issue hasn't come up more often?

[tml (tml)]

Not sure why I don't get any message from the shell when running soffice and doing the same thing that the process would have been killed by that SEGV. Does cairo actually catch it? Anyway, even if it does, surely what the code tries to do is insane?

The code in ScTransferObj::GetData() already shrinks the range handled in the case of RTF or RICHTEXT. Most likely it should do that for *all* cases. But Eike points out on IRC that it should not use the ShrinkToUsedDataArea() function to do it, as that will apparently drop empty cells that still have some visible formatting applied to them. Probably it should use ScTable::GetPrintArea().

[Xiscofauli (xiscofauli)]

No problem with

Version: 6.2.0.0.alpha0+
Build ID: 6ebc026e34d0c119067e7dfbad8d932f92844760
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

I guess it's only in debug mode ?

[tml (tml)]

When you say "no problem", you mean that you did not get the SEGV when running LO under gdb, after first selecting an entire column and then attempting to quit LO?

I know that there is no *apparent* problem (no visible indication something went wrong) when running LO otherwise. But my theory is that not all of the kinds of formats that LO tries to put on the clipboard actually end up there.

[tml (tml)]

Using the xclip command to list what "targets" (formats?) are available on the X11 clipboard after quitting LO (this time running it "normally", not under gdb):

When I copy just two cells:

> TARGETS
> MULTIPLE
> application/x-libreoffice-internal-id-9270
> STRING
> UTF8_STRING
> text/plain;charset=utf-8
> text/richtext
> text/rtf
> application/x-libreoffice-tsvc
> text/plain;charset=utf-16
> application/x-openoffice-dif;windows_formatname="DIF"
> application/x-openoffice-link;windows_formatname="Link"
> application/x-openoffice-sylk;windows_formatname="Sylk"
> text/html
> image/bmp
> application/x-openoffice-bitmap;windows_formatname="Bitmap"
> image/png
> application/x-openoffice-wmf;windows_formatname="Image WMF"
> application/x-openoffice-emf;windows_formatname="Image EMF"
> application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile"
> application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="47BBB4CB-CE4C-4E80-a591-42d9ae74950f";typename="LibreOfficeDev 6.2 Spreadsheet";displayname="file:///tmp/testcalccopypastecolumn.ods";viewaspect="1";width="2259";height="904";posx="0";posy="0"
> application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"

When I copy a whole column (by clicking on the column header, for instance "B"):

*nothing*

So clearly something does go wrong. xclip complains "Error: target TARGETS not available"

[tml (tml)]

And if I copy just a few cells and quit LO, and then run:

> xclip -o -target image/png -selection clipboard >afewcells.png

the afewcells.png indeed contains an image of those cells "printed".

[Libreoffice-commits (libreoffice-commits)]

Tor Lillqvist committed a patch related to this issue.
It has been pushed to "master":

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

tdf#69460, tdf#118416: Don't copy whole columns to the clipboard

It will be available in 6.2.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.

[Xiscofauli (xiscofauli)]

A polite ping to Tor Lillqvist:
Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing?
Thanks

[Xiscofauli (xiscofauli)]

*** Bug 120616 has been marked as a duplicate of this bug. ***

[Xiscofauli (xiscofauli)]

Hi Tor, Eike,
the fix for this issue also fixes bug 120616, which is a crash.
Any chance the commit could be backported to 6.1? Gerrit's cherry-pick prompts a merge conflict

[timur (ba.timur)]

*** Bug 120616 has been marked as a duplicate of this bug. ***

[Libreoffice-commits (libreoffice-commits)]

Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7139b259394f0b2075794bc6c42dd9c64005096b&h=libreoffice-6-1

tdf#69460, tdf#118416: Don't copy whole columns to the clipboard

It will be available in 6.1.4.

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.

[Ayca-yassi (ayca-yassi)]

We are using Libreoffice calc 6.0.6 in Manjaro. If we close the clipman, we don't get the error.

[Libreoffice-commits (libreoffice-commits)]

Tor Lillqvist committed a patch related to this issue.
It has been pushed to "libreoffice-6-1-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=037f9f91c1cb6ddb8077e59d01d62a5be5602d76&h=libreoffice-6-1-3

tdf#69460, tdf#118416: Don't copy whole columns to the clipboard

It will be available in 6.1.3.

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.

[Xiscofauli (xiscofauli)]

*** Bug 121093 has been marked as a duplicate of this bug. ***

[Bjlockie (bjlockie)]

The .crash

[Bjlockie (bjlockie)]

The sample

[Bjlockie (bjlockie)]

The files were attached so look at the attachments.

[Olivier Tilloy (osomon)]

Thanks for the report.

Unfortunately I cannot reproduce the crash here in a clean 18.10 VM, and the stack trace contained in the crash file is not useful.

If you can reliably reproduce the crash, would you mind installing debug packages for libreoffice (libreoffice-core-dbgsym, libreoffice-calc-dbgsym, libreoffice-gtk3-dbgsym, see instructions at https://wiki.ubuntu.com/DebuggingProgramCrash#Non-built-in_debug_symbol_packages_.28.2A-dbgsym.29) and running libreoffice from a terminal like that:

    libreoffice --calc --backtrace

Then open the document, trigger the crash, and attach the gdbtrace.log file that has been generated. Thanks!

[Bjlockie (bjlockie)]

I ran it as root, I got permission errors as a regular user.
It still crashed though.

root@cheetah:~# libreoffice --calc --backtrace
GNU gdb (Ubuntu 8.2-0ubuntu1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/libreoffice/program/soffice.bin...Reading symbols from /usr/lib/debug/.build-id/7b/a62316eeca8a9378bf71b85ac3ea091431cb66.debug...done.
done.
log will be saved as gdbtrace.log, this will take some time, patience...

(soffice:31505): GLib-GObject-CRITICAL **: 15:23:45.048: g_object_get_data: assertion 'G_IS_OBJECT (object)' failed

(soffice:31505): GLib-GIO-CRITICAL **: 15:23:45.099: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(soffice:31505): GLib-GIO-CRITICAL **: 15:23:45.099: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(soffice:31505): GLib-GIO-CRITICAL **: 15:23:45.099: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(soffice:31505): GLib-GIO-CRITICAL **: 15:23:45.099: g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
root@cheetah:~#

[Olivier Tilloy (osomon)]

This is an upstream crash (https://bugs.documentfoundation.org/show_bug.cgi?id=118416), which was fixed in 6.1.3, which will soon be SRU’d to cosmic (see bug #1803142).

[Chad Cloman (waoi-public)]

*** Bug 120942 has been marked as a duplicate of this bug. ***