Steps to reproduce: - Select a portion of text with the left mouse button - Paste it with the middle mouse button Reproduced in different PCs. I have removed the ~/.config/libreoffice, but it does not solve the problem. I have tried with different JDK versions: java-7-openjdk/jre, java-8-openjdk/jre, but the problem continue
*** Bug 93888 has been marked as a duplicate of this bug. ***
Do you reproduce this in a brand new file with 1 paragraph of "lorem ipsum" (see http://www.lipsum.com/)? If yes, what's your Linux distrib? (perhaps it's the same on all your pcs) What's the env: gtk, gtk3, kde, kde4, other? Also, do you use accessibility option? If yes, could you disable for the test and give it a new try?
(In reply to Julien Nabet from comment #3) > Do you reproduce this in a brand new file with 1 paragraph of "lorem ipsum" > (see http://www.lipsum.com/)? > If yes, what's your Linux distrib? (perhaps it's the same on all your pcs) > What's the env: gtk, gtk3, kde, kde4, other? > Also, do you use accessibility option? If yes, could you disable for the > test and give it a new try? Steps to reproduce the error: - Create a new empty Writer Document: - Copy and paste 1 paragraph of "lorem ipsum", I've got it from http://www.lipsum.com - Select with the left mouse button, this lorem ipsum paragraph from the Writer Document and paste it again (in the same document) with the middle mouse button, and LibreOffice Writer crashes. (Only crashes if the selection was made from the same LibreOffice document. If the selection comes from other document or other source, like a browser, it does not happen) I'm using on all my PCs ArchLinux, with libreoffice-fresh package. My desktop environment is Xfce 4.12 with gtk-xfce-engine 2.10.1-1 (xfce4) I have disabled accessibility option and the bug still happens.
Thank you for your feedback. On pc Debian x86-64 with LO Debian package 4.4.5.2 or with master sources updated today (future 5.1.0), I don't reproduce this. Would it be possible you retrieve a backtrace by following this link https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace by any chance?
Created attachment 118422 [details] Backtrace I got it running the following command: $ soffice --writer --backtrace
(In reply to Julien Nabet from comment #5) > Thank you for your feedback. > > On pc Debian x86-64 with LO Debian package 4.4.5.2 or with master sources > updated today (future 5.1.0), I don't reproduce this. > > Would it be possible you retrieve a backtrace by following this link > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU. > 2FLinux:_How_to_get_a_backtrace by any chance? Anyway, you are testing with other LO version. I have attached the backtrace
Let's put this one NEW since you provided a bt. It's not a debug bt so we can just suppose it's linked to gtk3 dealing by LO. Just to be sure, could you run this export SAL_USE_VCLPLUGIN=gtk then launch LO + same with SAL_USE_VCLPLUGIN=gen ? Another question: did you install LO from Arch repo or from tdf website?
(In reply to Julien Nabet from comment #8) > Let's put this one NEW since you provided a bt. > > It's not a debug bt so we can just suppose it's linked to gtk3 dealing by LO. > Just to be sure, could you run this > export SAL_USE_VCLPLUGIN=gtk then launch LO > + same with SAL_USE_VCLPLUGIN=gen > ? The mouse copy-paste button function does not work with this variables > > Another question: did you install LO from Arch repo or from tdf website? I've installed it from Arch repo
Thank you again for your feedback. I must recognize I'm running out of ideas for the moment. Certainly someone may help here.
This one is hard to reproduce, but I finally reproduced it with master under Fedora 22 (64-bit). There is an infinite recursion of this stuff: #21813 0x00007fffe9c03c2f in g_closure_invoke () at /lib64/libgobject-2.0.so.0 #21814 0x00007fffe9c15539 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0 #21815 0x00007fffe9c1def0 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0 #21816 0x00007fffe9c1e765 in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0 #21817 0x00007fffd8d119fb in gtk_selection_invoke_handler () at /lib64/libgtk-3.so.0 #21818 0x00007fffd8d11ccf in gtk_selection_convert () at /lib64/libgtk-3.so.0 #21819 0x00007fffd8decbec in gtk_clipboard_wait_for_contents () at /lib64/libgtk-3.so.0 #21820 0x00007fffd93cd40e in GtkTransferable::getTransferData(com::sun::star::datatransfer::DataFlavor const&) (this=0x5678640, rFlavor=...) at /run/media/maxim/SAMSUNG/libreoffice/master/vcl/unx/gtk3/app/gtk3gtkinst.cxx:138 #21821 0x00007fffd93c94b2 in VclGtkClipboard::ClipboardGet(_GtkClipboard*, _GtkSelectionData*, unsigned int) (this=0x50c37c0, selection_data=0x7fffffc86aa0, info=0) at /run/media/maxim/SAMSUNG/libreoffice/master/vcl/unx/gtk3/app/gtk3gtkinst.cxx:401 #21822 0x00007fffd93c9d54 in (anonymous namespace)::ClipboardGetFunc(GtkClipboard*, GtkSelectionData*, guint, gpointer) (clipboard=0x14de800, selection_data=0x7fffffc86aa0, info=0, user_data_or_owner=0x50c4360) at /run/media/maxim/SAMSUNG/libreoffice/master/vcl/unx/gtk3/app/gtk3gtkinst.cxx:486 Had to kill gdb manually after it wrote a stack of ~22000 items.
I think the trick to reproducing this is to select in writer, paste if you want, then click inside writer to drop the selection and then middle paste again. i.e. libreoffice owns the clipboard by putting something into it, then puts nothing into it on setting a null selection but still owns it and thinks it no longer owns it because its empty.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f3f1919aa4eca2f6180649eda43bcb813b1f0450 Resolves: tdf#93887 distinguish between empty selection lost selection 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b9501f6da42ba5b9d1b3c702d527bf8795cdd7c&h=libreoffice-5-0 Resolves: tdf#93887 distinguish between empty selection lost selection It will be available in 5.0.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.
*** Bug 95215 has been marked as a duplicate of this bug. ***