Bug 69460 - Copy/Paste of a column in Calc file followed by Cmd-Q causes soffice process to consume all resources
Summary: Copy/Paste of a column in Calc file followed by Cmd-Q causes soffice process ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Mac OS X (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:6.2.0 target:6.1.3
Keywords:
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2013-09-17 10:15 UTC by mercergeoinfo
Modified: 2018-10-22 01:57 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
sampling trace (107.54 KB, text/plain)
2013-09-17 13:35 UTC, Alex Thurgood
Details
timer trace (107.54 KB, text/plain)
2013-09-17 13:37 UTC, Alex Thurgood
Details
ODS test document (9.61 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-09-17 13:57 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mercergeoinfo 2013-09-17 10:15:43 UTC
This bug actually applies to OpenOffice, NeoOffice and LibreOffice.
When working with csv files in Calc, saving and exiting causes the program to hang but worse than this, it causes OSX to to slow to a halt. I cant access Force Quit by any method, using KILL in the terminal wont work because accessing Terminal, even if running already becomes incredibly slow. The only option is to power off or wait a long, long time.
It only happens if I save and exit in quick succession, without interacting with the program in any way been these actions, i.e. by using cmd-Q directly after saving.
This issue has been around for some time and isn't specific to 10.7 (my OS). Mostly I can avoid it, by clicking somewhere in LibreOffice, but occasionally I forgot and am suddenly dropped into a very slow process of restarting my work flow.
Sorry if this doesn't conform to standard bug descriptions.
Comment 1 Alex Thurgood 2013-09-17 11:00:53 UTC
Sorry, can not confirm on OSX 10.8.4 with LO 4.1.1.2

Please provide details :

OSX version
LO / AOO / NeoOffice version



Alex
Comment 2 mercergeoinfo 2013-09-17 11:14:05 UTC
LibreOffice Version: 4.1.1.2
OSX 10.7.5

But I have had this issue for some time, using OSX 10.6 and many versions of OO/LO/NeoOffice and it is specifically triggered by quitting directly after saving a csv file with "Save as" and "Edit filter settings" even if using the default settings.
Comment 3 Alex Thurgood 2013-09-17 11:15:58 UTC
Also, which CSV export settings are you using ?

A minimum size ODS file which you use to reproduce the problem would be necessary, otherwise we'll be running around all day trying to find out the specific cause.
Comment 4 Alex Thurgood 2013-09-17 11:22:20 UTC
I'm not saying that the behaviour you observed doesn't exist, just that I can't reproduce it, nor have I ever seen this, whether it be with LO, AOO, or Neo, and I've gone through 3 OSX upgrades in as many years from 10.6, to 10.7 and now to 10.8.

This would indicate on the face of it that there is something specific, either in your configuration files, or in the data that you are attempting to export, which causes the problem.


Alex
Comment 5 Alex Thurgood 2013-09-17 11:29:39 UTC
Just tried with 

AOO400m3(Build:9702)  -  Rev. 1503704
2013-07-16 14:51:10 (Tue, 16 Jul 2013)

No hang there either.
1) Start OOo app
2) Open new Calc document
3) Enter some text in A1
4) Enter some numbers in B1
5) Enter a number with decimals in C1
6) Enter a date in D1
7) Save as CSV - choose default export options
8) OpenOffice main menu > Quit

I did exactly the same with LO.

You need to provide us with that kind of detail, so we can try and reproduce.
Comment 6 mercergeoinfo 2013-09-17 11:42:38 UTC
Use cmd-Q to quit, no interaction with NO's GUI, that's what triggers it. I can avoid the crash by quitting via the menu but sometimes I'm in my "flow" and just use keyboard shortcuts, forgetting that disaster awaits.
Comment 7 mercergeoinfo 2013-09-17 11:51:52 UTC
So, tried again and had some difficulties  but managed to get a close match to the behaviour.
csv file of 1kb
Open in LibreOffice
Swap two columns
Save as
Edit Filter Settings
Press Enter key to save then cmd-Q to quit

I had prepared beforehand by closing everything else down and having the Force Quit window open. This eased the problem but it certainly triggered a crash in LO

Re previous comment about config file: I always clean install so it seems unlikely. Also, I think, though I cant be certain, that I had this issue with OO on 10.5
Comment 8 Alex Thurgood 2013-09-17 13:08:22 UTC
OK, I can reproduce now, but only :

- if I import an existing CSV file ;
- if I copy and paste one or more columns to another column position ;
- then use Cmd-Q to quit the application

Memory consumption of the soffice process steadily climbs over time, seemingly as 5 or 6 threads are polled/respawned, and memory continuously allocated.


Changing title to reflect findings.


Alex
Comment 9 Alex Thurgood 2013-09-17 13:10:18 UTC
Adding Markus, Kohei, and Eike to CC

Lifecycle memory allocation problem ?


Alex
Comment 10 Alex Thurgood 2013-09-17 13:18:08 UTC
Correction : after more testing, the problem can be reproduced with native ODS Calc documents too.
Comment 11 Alex Thurgood 2013-09-17 13:35:05 UTC
Created attachment 85983 [details]
sampling trace

Sample trace after Cmd-Q with soffice process still running
Comment 12 Alex Thurgood 2013-09-17 13:37:19 UTC
Created attachment 85984 [details]
timer trace

timings of process threads/calls after Cmd-Q is issued and soffice process still running
Comment 13 Alex Thurgood 2013-09-17 13:56:55 UTC
How to reproduce :

1) Open attached ODS test file
2) Select a whole column by clicking on column header
3) Copy/paste any column to another empty column
4) Save
5) Quit the application (Cmd-Q or LibreOffice > Quit)

Watch how the soffice process remains running, maintaining 5 or 6 threads, consuming processor availability til it hits 100%, at which point the OSX process monitor kicks in and states that the application is no longer responding. The processor occupancy drops, but memory continues to be allocated to the soffice process.



Alex
Comment 14 Alex Thurgood 2013-09-17 13:57:26 UTC
Created attachment 85988 [details]
ODS test document
Comment 15 Alex Thurgood 2013-09-17 13:59:14 UTC
Upping priority as the only way to escape this is to force kill the application.
Comment 16 Alex Thurgood 2013-09-17 14:00:45 UTC
I have only tested this back to LO 3.3.4, so can't say at the moment whether it does go back to OOo times
Comment 17 Alex Thurgood 2013-09-17 14:05:37 UTC
Confirming also in OOo 3.2.1. Changing version back to Inherited from OOo
Comment 18 QA Administrators 2015-04-01 14:41:48 UTC Comment hidden (obsolete)
Comment 19 Alex Thurgood 2015-04-01 16:44:54 UTC
Tested on 

Version: 4.5.0.0.alpha0+
Build ID: 09f83e1f409853a6c6e4300287c4e50bad5b9d0b
Locale: fr_


It now quits, but in two clearly defined stages :
- document windo destroyed ;

beachball spinning 10-15 seconds

- then main app window closure


lldb shows this from the save point of the document :

warn:vcl.quartz:54361:1:vcl/quartz/salbmp.cxx:318: bad alloc 304x15845148
warn:vcl.quartz:54361:1:vcl/quartz/salbmp.cxx:318: bad alloc 304x15845148
warn:vcl.quartz:54361:1:vcl/quartz/salbmp.cxx:318: bad alloc 304x15845148
warn:legacy.osl:54361:1:sfx2/source/appl/app.cxx:222: Memory leak: some object shells were not removed!
warn:sal.osl.pipe:54361:1:sal/osl/unx/pipe.cxx:396: shutdown() failed: Socket is not connected
warn:sal.osl.pipe:54361:3:sal/osl/unx/pipe.cxx:437: accept() failed: Software caused connection abort
warn:sal.osl:54361:1:sal/osl/all/debugbase.cxx:116: unexpected number of 19SvxUnoTextRangeBase: 63; Expected: 0
warn:legacy.osl:54361:1:unotools/source/config/configmgr.cxx:168: OSL_ASSERT: items_.empty()
Process 54361 exited with status = 0 (0x00000000) 


so it is still not shutting down properly by the looks of it.
Comment 20 Alex Thurgood 2015-04-01 16:46:28 UTC
don't know whether this has any impact on the bug, but when copying/pasting, I see the following output in lldb :

warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-column with mismatching mapper ! 31ScXMLColumnExportPropertyMapper 25SvXMLExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-row with mismatching mapper ! 28ScXMLRowExportPropertyMapper 25SvXMLExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-cell with mismatching mapper ! 29ScXMLCellExportPropertyMapper 28XMLShapeExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-column with mismatching mapper ! 31ScXMLColumnExportPropertyMapper 25SvXMLExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-row with mismatching mapper ! 28ScXMLRowExportPropertyMapper 25SvXMLExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-cell with mismatching mapper ! 29ScXMLCellExportPropertyMapper 28XMLShapeExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-column with mismatching mapper ! 31ScXMLColumnExportPropertyMapper 25SvXMLExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-row with mismatching mapper ! 28ScXMLRowExportPropertyMapper 25SvXMLExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-cell with mismatching mapper ! 29ScXMLCellExportPropertyMapper 28XMLShapeExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-column with mismatching mapper ! 31ScXMLColumnExportPropertyMapper 25SvXMLExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-row with mismatching mapper ! 28ScXMLRowExportPropertyMapper 25SvXMLExportPropertyMapper
warn:xmloff:54361:1:xmloff/source/style/impastpl.cxx:432: Adding duplicate family table-cell with mismatching mapper ! 29ScXMLCellExportPropertyMapper 28XMLShapeExportPropertyMapper
warn:legacy.osl:54361:1:vcl/source/filter/wmf/emfwr.cxx:1526: EMFWriter::ImplWriteActions: unsupported MetaAction #150
warn:legacy.osl:54361:1:vcl/source/filter/wmf/emfwr.cxx:1526: EMFWriter::ImplWriteActions: unsupported MetaAction #151
warn:legacy.osl:54361:1:vcl/source/filter/wmf/emfwr.cxx:1526: EMFWriter::ImplWriteActions: unsupported MetaAction #150
warn:legacy.osl:54361:1:vcl/source/filter/wmf/emfwr.cxx:1526: EMFWriter::ImplWriteActions: unsupported MetaAction #151
warn:legacy.osl:54361:1:vcl/source/filter/wmf/wmfwr.cxx:1621: Unsupported action: MetaISectRegionClipRegionAction!
warn:legacy.osl:54361:1:vcl/source/filter/wmf/wmfwr.cxx:1633: Unsupported meta action!
warn:legacy.osl:54361:1:vcl/source/filter/wmf/wmfwr.cxx:1633: Unsupported meta action!
warn:legacy.osl:54361:1:vcl/source/filter/wmf/wmfwr.cxx:1633: Unsupported meta action!
warn:legacy.osl:54361:1:vcl/source/filter/wmf/wmfwr.cxx:1621: Unsupported action: MetaISectRegionClipRegionAction!
warn:legacy.osl:54361:1:vcl/source/filter/wmf/wmfwr.cxx:1621: Unsupported action: MetaISectRegionClipRegionAction!
warn:legacy.osl:54361:1:vcl/source/filter/wmf/wmfwr.cxx:1621: Unsupported action: MetaISectRegionClipRegionAction!
Comment 21 tommy27 2016-04-16 07:28:03 UTC Comment hidden (obsolete)
Comment 22 Alex Thurgood 2017-05-11 06:42:00 UTC
Bug still present in 

Version: 5.2.7.2
Build ID: 2b7f1e640c46ceb28adf43ee075a6e8b8439ed10
Threads CPU : 2; Version de l'OS :Mac OS X 10.12.4; UI Render : par défaut; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group
Comment 23 Alex Thurgood 2017-05-11 06:43:54 UTC
The app eventually closes, but for a 3 x 8 cell array in the CSV, the shutdown time is ludicrously long. In the meantime, the app appears to have hung, the spinning beachball just keeps on turning, and the app is unresponsive.
Comment 24 Chris Sherlock 2017-09-22 01:59:47 UTC
Hi Alex, I just tried this in LO 5.4.0.3 on Windows 7, no slow shutdown occurring for me.

I can try on OS X when I get home, is this the only OS you have tested on?

Version I opened the ODS on:

Version: 5.4.0.3 (x64)
Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
CPU threads: 4; OS: Windows 6.1; UI render: default; 
Locale: en-AU (en_AU); Calc: group
Comment 25 Tor Lillqvist 2018-06-27 12:57:03 UTC
I get an assertion failure when attempting to quit:

> #0	0x00007fff5023db6e in __pthread_kill ()
> #1	0x00007fff50408080 in pthread_kill ()
> #2	0x00007fff501991ae in abort ()
> #3	0x00007fff501611ac in __assert_rtn ()
> #4	0x0000000113f567df in BitmapInfoAccess::BitmapInfoAccess(Bitmap&, BitmapAccessMode) at /Users/tml/lo/osx/vcl/source/gdi/bmpacc.cxx:62
> #5	0x0000000113f56c1b in BitmapReadAccess::BitmapReadAccess(Bitmap&, BitmapAccessMode) at /Users/tml/lo/osx/vcl/source/gdi/bmpacc.cxx:83
> #6	0x0000000113f57223 in BitmapReadAccess::BitmapReadAccess(Bitmap&, BitmapAccessMode) at /Users/tml/lo/osx/vcl/source/gdi/bmpacc.cxx:86
> #7	0x000000011429a1a2 in Bitmap::AcquireReadAccess() at /Users/tml/lo/osx/vcl/source/bitmap/bitmap.cxx:363
> #8	0x0000000113eb534a in vcl::ScopedBitmapAccess<BitmapReadAccess, Bitmap, &(Bitmap::AcquireReadAccess())>::ScopedBitmapAccess(Bitmap&) at /Users/tml/lo/osx/include/vcl/scopedbitmapaccess.hxx:53
> #9	0x0000000113eb163d in vcl::ScopedBitmapAccess<BitmapReadAccess, Bitmap, &(Bitmap::AcquireReadAccess())>::ScopedBitmapAccess(Bitmap&) at /Users/tml/lo/osx/include/vcl/scopedbitmapaccess.hxx:52
> #10	0x00000001141a8c1e in vcl::PNGWriterImpl::PNGWriterImpl(BitmapEx const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const*) at /Users/tml/lo/osx/vcl/source/gdi/pngwrite.cxx:230
> #11	0x00000001141aae55 in vcl::PNGWriterImpl::PNGWriterImpl(BitmapEx const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const*) at /Users/tml/lo/osx/vcl/source/gdi/pngwrite.cxx:117
> #12	0x00000001141ace74 in vcl::PNGWriter::PNGWriter(BitmapEx const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const*) at /Users/tml/lo/osx/vcl/source/gdi/pngwrite.cxx:695
> #13	0x00000001141acf65 in vcl::PNGWriter::PNGWriter(BitmapEx const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const*) at /Users/tml/lo/osx/vcl/source/gdi/pngwrite.cxx:696
> #14	0x00000001106a2301 in TransferableHelper::SetBitmapEx(BitmapEx const&, com::sun::star::datatransfer::DataFlavor const&) at /Users/tml/lo/osx/svtools/source/misc/transfer.cxx:666
> #15	0x000000015d5a7d62 in ScTransferObj::GetData(com::sun::star::datatransfer::DataFlavor const&, rtl::OUString const&) at /Users/tml/lo/osx/sc/source/ui/app/transobj.cxx:376
> #16	0x000000011069e3cb in TransferableHelper::getTransferData2(com::sun::star::datatransfer::DataFlavor const&, rtl::OUString const&) at /Users/tml/lo/osx/svtools/source/misc/transfer.cxx:377
> #17	0x000000011069ce3a in TransferableHelper::getTransferData(com::sun::star::datatransfer::DataFlavor const&) at /Users/tml/lo/osx/svtools/source/misc/transfer.cxx:275
> #18	0x000000011069cec3 in non-virtual thunk to TransferableHelper::getTransferData(com::sun::star::datatransfer::DataFlavor const&) ()
> #19	0x000000011452d046 in DataFlavorMapper::getDataProvider(NSString const*, com::sun::star::uno::Reference<com::sun::star::datatransfer::XTransferable> const&) const at /Users/tml/lo/osx/vcl/osx/DataFlavorMapping.cxx:549
> #20	0x00000001145419f9 in AquaClipboard::provideDataForType(NSPasteboard*, NSString const*) at /Users/tml/lo/osx/vcl/osx/clipboard.cxx:289
> #21	0x0000000114545715 in AquaClipboard::flushClipboard() at /Users/tml/lo/osx/vcl/osx/clipboard.cxx:314
> #22	0x000000011069cb72 in TransferableHelper::ImplFlush() at /Users/tml/lo/osx/svtools/source/misc/transfer.cxx:522
> #23	0x000000011069cabd in TransferableHelper::TerminateListener::notifyTermination(com::sun::star::lang::EventObject const&) at /Users/tml/lo/osx/svtools/source/misc/transfer.cxx:254
> #24	0x000000014ef6cd15 in framework::Desktop::impl_sendTerminateToClipboard() at /Users/tml/lo/osx/framework/source/services/desktop.cxx:1655
> #25	0x000000014ef6b090 in framework::Desktop::terminate() at /Users/tml/lo/osx/framework/source/services/desktop.cxx:327
> #26	0x000000010c44d601 in desktop::Desktop::QueryExit() at /Users/tml/lo/osx/desktop/source/app/app.cxx:595
> #27	0x0000000113d0b10c in ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) at /Users/tml/lo/osx/vcl/source/window/winproc.cxx:2456
> #28	0x000000011451f4a5 in SalFrame::CallCallback(SalEvent, void const*) const at /Users/tml/lo/osx/vcl/inc/salframe.hxx:280
> #29	0x0000000114687c12 in ::-[VCL_NSApplication applicationShouldTerminate:](NSApplication *) at /Users/tml/lo/osx/vcl/osx/vclnsapp.mm:329
> #30	0x00007fff25a5a1b4 in -[NSApplication _docController:shouldTerminate:] ()
> #31	0x00007fff25a5a071 in __91-[NSDocumentController(NSInternal) _closeAllDocumentsWithDelegate:shouldTerminateSelector:]_block_invoke ()
> #32	0x00007fff25a59cbb in -[NSDocumentController(NSInternal) _closeAllDocumentsWithDelegate:shouldTerminateSelector:] ()
> #33	0x00007fff25a597c4 in -[NSDocumentController(NSInternal) __closeAllDocumentsWithDelegate:shouldTerminateSelector:] ()
> #34	0x00007fff25a59426 in -[NSApplication _shouldTerminate] ()
> #35	0x00007fff25a58ad2 in -[NSApplication terminate:] ()
> #36	0x00007fff2600fa43 in -[NSApplication(NSResponder) sendAction:to:from:] ()
> #37	0x00007fff25aa4213 in -[NSMenuItem _corePerformAction] ()
> #38	0x00007fff25aa3f9b in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] ()
> #39	0x00007fff25aa2dff in -[NSMenu performKeyEquivalent:] ()
> #40	0x0000000114686072 in ::-[VCL_NSApplication sendEvent:](NSEvent *) at /Users/tml/lo/osx/vcl/osx/vclnsapp.mm:148
> #41	0x000000011452094e in AquaSalInstance::DoYield(bool, bool) at /Users/tml/lo/osx/vcl/osx/salinst.cxx:647
> #42	0x0000000114394d69 in ImplYield(bool, bool) at /Users/tml/lo/osx/vcl/source/app/svapp.cxx:470
> #43	0x0000000114394674 in Application::Yield() at /Users/tml/lo/osx/vcl/source/app/svapp.cxx:535
> #44	0x00000001143945f1 in Application::Execute() at /Users/tml/lo/osx/vcl/source/app/svapp.cxx:450
> #45	0x000000010c456801 in desktop::Desktop::Main() at /Users/tml/lo/osx/desktop/source/app/app.cxx:1634
> #46	0x00000001143a6deb in ImplSVMain() at /Users/tml/lo/osx/vcl/source/app/svmain.cxx:200
> #47	0x000000011451f6e5 in AquaSalInstance::handleAppDefinedEvent(NSEvent*) at /Users/tml/lo/osx/vcl/osx/salinst.cxx:464
> #48	0x0000000114685dc0 in ::-[VCL_NSApplication sendEvent:](NSEvent *) at /Users/tml/lo/osx/vcl/osx/vclnsapp.mm:101
> #49	0x00007fff2586c8b5 in -[NSApplication run] ()
> #50	0x00007fff2583ba72 in NSApplicationMain ()
> #51	0x000000011451ddca in ImplSVMainHook(int*) at /Users/tml/lo/osx/vcl/osx/salinst.cxx:224
> #52	0x00000001143a9bdc in SVMain() at /Users/tml/lo/osx/vcl/source/app/svmain.cxx:235
> #53	0x000000010c4d041a in ::soffice_main() at /Users/tml/lo/osx/desktop/source/app/sofficemain.cxx:169
> #54	0x000000010c30ff5d in sal_main at /Users/tml/lo/osx/desktop/source/app/main.c:48
> #55	0x000000010c30ff37 in main at /Users/tml/lo/osx/desktop/source/app/main.c:47
Comment 26 Tor Lillqvist 2018-06-27 14:16:52 UTC
The assertion failure is not related to this bug but caused by a very recently added assertion that I think can actually be removed.

I don't understand why the initial description of this bug makes it sound so complicated and special case. Comment #13 is much better. But even the "save" step is unnecessary; just quit and choose "Don't" save changes is enough to see the slowness.

Presumably the slowness is caused when some of the formats that the copied column is exported in to the system clipboard insist on exporting all one million rows of the column, even if just two cells actually exist. Here is some timings. The "== flavour" rows are printed before the column is exported into that format.

> 0.000:debug:5098:49559583: >> AquaClipboard::flushClipboard()
> 0.000:debug:5098:49559583: == flavour: application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"
> 0.548:debug:5098:49559583: == flavour: application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)"
> 0.549:debug:5098:49559583: == flavour: application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile"
> 0.552:debug:5098:49559583: == flavour: application/x-openoffice-emf;windows_formatname="Image EMF"
> 0.556:debug:5098:49559583: == flavour: application/x-openoffice-wmf;windows_formatname="Image WMF"
> 0.559:debug:5098:49559583: == flavour: NeXT TIFF v4.0 pasteboard type
> 1.534:debug:5098:49559583: == flavour: application/x-openoffice-bitmap;windows_formatname="Bitmap"
> 2.411:debug:5098:49559583: == flavour: image/bmp
> 3.288:debug:5098:49559583: == flavour: Apple HTML pasteboard type
> 3.290:debug:5098:49559583: == flavour: application/x-openoffice-sylk;windows_formatname="Sylk"
> 3.492:debug:5098:49559583: == flavour: application/x-openoffice-link;windows_formatname="Link"
> 3.493:debug:5098:49559583: == flavour: application/x-openoffice-dif;windows_formatname="DIF"
> 5.092:debug:5098:49559583: == flavour: NSStringPboardType
> 5.095:debug:5098:49559583: == flavour: application/x-libreoffice-tsvc
> 5.096:debug:5098:49559583: == flavour: NeXT Rich Text Format v1.0 pasteboard type
> 5.096:debug:5098:49559583: == flavour: text/richtext
> 5.097:debug:5098:49559583: << AquaClipboard::flushClipboard()
Comment 27 Tor Lillqvist 2018-06-27 15:15:28 UTC
If it is of any consolation, doing the corresponding thing on Linux causes LibreOffice to crash;)

I don't understand how this hasn't been a much more common problem? Surely it can't be that uncommon for users to select a whole column, and then quit, causing LibreOffice to try to store all of the column in the system clipboard?
Comment 28 Tor Lillqvist 2018-06-27 15:34:56 UTC
(I mean select *and* *copy* in my previous comment, of course.)
Comment 29 Tor Lillqvist 2018-06-28 10:04:14 UTC
Sugested fix at https://gerrit.libreoffice.org/#/c/56577/1 . Reduces the time to under half a second for me. (From five seconds, as seen in comment #26)
Comment 30 Commit Notification 2018-07-16 19:36:21 UTC
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.
Comment 31 Xisco Faulí 2018-08-16 08:22:26 UTC
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
Comment 32 Commit Notification 2018-10-17 19:46:33 UTC
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.
Comment 33 Commit Notification 2018-10-21 22:27:29 UTC
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.