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.
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
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.
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.
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
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.
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.
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
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
Adding Markus, Kohei, and Eike to CC Lifecycle memory allocation problem ? Alex
Correction : after more testing, the problem can be reproduced with native ODS Calc documents too.
Created attachment 85983 [details] sampling trace Sample trace after Cmd-Q with soffice process still running
Created attachment 85984 [details] timer trace timings of process threads/calls after Cmd-Q is issued and soffice process still running
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
Created attachment 85988 [details] ODS test document
Upping priority as the only way to escape this is to force kill the application.
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
Confirming also in OOo 3.2.1. Changing version back to Inherited from OOo
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
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.
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!
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
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
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.
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
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
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()
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?
(I mean select *and* *copy* in my previous comment, of course.)
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)
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.
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
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.
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.