Bug 91357

Unfortunately this bug is still valid for 3.3.2.

I can reproduce it when selecting text in <textarea></textarea>, e.g. in this very field I am just typing in. The app I select the text in, e.g. konqueror, as well as klipper (icon not visible in kicker) are stalled for several seconds on a 1,4 GHz with 512MB RAM. If I delete the content of klipper, the app in question also stalls for several seconds in a row. Appart from the fact that klipper does not delete all its content but keeps one entry, after that every selection stalls klipper but not the app. Moreover, if I right-click klipper it stalls, then shows the menu, then stalls itself and the app. The same happens when I place the cursor in the textarea.

I tried to use gdb, but did not succeed and would appreciate some help. I use attach PID to attach to klipper and then hit CTRL+C when kicker is stalled. After that a backtrace does not give much information. Do I have to recompile with --debug-full? If you cannot reproduce it, I'll try to recompile kdebase myself. Is there maybe a way to just re-compile klipper?

On Monday 20 December 2004 09:13, S.Burmeister wrote:

> I can reproduce it when selecting text in <textarea></textarea>, e.g. in
> this very field I am just typing in. The app I select the text in, e.g.
> konqueror, as well as klipper (icon not visible in kicker) are stalled for
> several seconds on a 1,4 GHz with 512MB RAM. If I delete the content of
> klipper, the app in question also stalls for several seconds in a row.

I cannot reproduce this in 3.3.1, nor in CVS :-( I'll try later with a slower 
machine, though the machine I have with comparable specs is headless at the 
moment.

Could you give a step-by-step procedure to reproduce? Like

1. type sfkdngafd in the bug field below
2. press delete
3. ...

Thanks

> Appart from the fact that klipper does not delete all its content but keeps
> one entry, after that every selection stalls klipper but not the app.

That is working as designed (or at least as Klipper has done since I took over 
maintenance :) ). Deselect "Prevent empty clipboard" if this is not desired.

> I tried to use gdb, but did not succeed and would appreciate some help. I
> use attach PID to attach to klipper and then hit CTRL+C when kicker is
> stalled. After that a backtrace does not give much information. Do I have
> to recompile with --debug-full? If you cannot reproduce it, I'll try to
> recompile kdebase myself. Is there maybe a way to just re-compile klipper?

Yes, you need debug symbols, use enable-debug=full in ./configure. You can 
compile Klipper alone by running make -f Makefile.cvs and ./configure 
normally, then cd to klipper and make && make install. Remember to check that 
the application is installed in the correct location before doing so.

If you need further help, perhaps it would be easiets to catch me on Jabber 
(id: mesbenh (at) jabber.dk)

Thanks for helping out!

Ok, I got the beta 1 kdebase-package. I tried to do a make -f Makefile, which did not succeed. Then I cd klipper and there I could do a make -f Makefile and then make install.

Finally I went into gsb and used attach pid to attach to klipper.

When klipper stalled (icon is not refreshed in kicker) I typed in backtrace in gdb and got:

#0  0xffffe410 in ?? ()
#1  0xbfffe7d8 in ?? ()
#2  0x0818079c in ?? ()
#3  0x08180618 in ?? ()
#4  0x40fa59fd in ___newselect_nocancel () from /lib/tls/libc.so.6
#5  0x407b397a in QEventLoop::processEvents ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#6  0x4081dcb1 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3
#7  0x4081daf6 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#8  0x408077df in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#9  0x416f960c in kdemain (argc=1, argv=0x81584e8) at main.cpp:52
#10 0x40018589 in kdeinitmain (argc=1, argv=0x81584e8) at klipper_dummy.cpp:2
#11 0x0804e742 in launch ()
#12 0x0804ee4c in handle_launcher_request ()
#13 0x0804f409 in handle_requests ()
#14 0x0804fbea in main ()

Does this mean anything?

What else can I do? I can reproduce the bug when going to some article at www.heise.de, I look for a large posting on the third or deeper level and click on "Beantworten", then I log in and click on the "Zitat einfügen" button to insert the previous postings text, then I select >12 lines of the cited text and this is when klipper gets stalled. It does also get stalled when I click somewhere in the textarea to deselect the text.

Still can't reproduce this. I have no login at http://www.heise.de, and my German is too poor to create a login, if that is possible. If you write a recipie, I'll try it.

Two things: 
1. Are you still using Konqueror? (Klipper logic is wildly different between QT and non-QT apps.)
2. Open Configure in Klipper menu. Tell me:
  a. Is "synchronize contents of clipboard and selection" selected?
  b. What is the large value you can set the "Clipboard history size" to?

Thanks!

Yes, I am using konqueror.

Kepp seperate is enabled.

2048 is the highest value I can set the history to, yet I have it on 7.

Does "nm $(which klipper)" output any symbols in Konsole? Or does it just say something about no symbols?

This is what I get:

08049744 A __bss_start
08048444 t call_gmon_start
08049744 b completed.1
08049630 d __CTOR_END__
0804962c d __CTOR_LIST__
08049738 D __data_start
08049738 W data_start
080485e0 t __do_global_ctors_aux
08048470 t __do_global_dtors_aux
0804973c D __dso_handle
08049638 d __DTOR_END__
08049634 d __DTOR_LIST__
08049640 A _DYNAMIC
08049744 A _edata
08049748 A _end
08048604 T _fini
0804962c A __fini_array_end
0804962c A __fini_array_start
08048620 R _fp_hw
080484b0 t frame_dummy
08048628 r __FRAME_END__
08049724 A _GLOBAL_OFFSET_TABLE_
         w __gmon_start__
080485d8 T __i686.get_pc_thunk.bx
080483d4 T _init
0804962c A __init_array_end
0804962c A __init_array_start
08048624 R _IO_stdin_used
0804963c d __JCR_END__
0804963c d __JCR_LIST__
         w _Jv_RegisterClasses
         U kdemain
08048510 T __libc_csu_fini
08048580 T __libc_csu_init
         U __libc_start_main@@GLIBC_2.0
080484dc T main
08049740 d p.0
08048420 T _start

Today I got the stall when typing into the bugs.kde.org textarea. I am really not sure what triggers it because it works till some point that I select text in the textarea without stalling the KDE GUIs. I think today it started after I inserted something using CTRL+V. It inserted something from the last session, i.e. yesterday, I guess it was saved in klipper?
Yet again, I am not sure and I'll poke further because this issue is annoying. ;)

http://bugs.kde.org/show_bug.cgi?id=96639

I've found my bug \o/ => works with kde 3.4 current cvs too!
So it comes from klipper :)

To reproduce the bug, easy:
Tell klipper to save clipboard content on exit. logout from kde. login, then klipper make konqueror freeze when selecting text in a textarea. 

Works really well on current Debian Sarge and current mandrake cooker(freezing is shorter but mandrake kde is evily patched). Works well with current kde CVS on Debian SID.

In Debian Sid, bug has gone as kde 3.3.2 from debian sid is unable to save clipboard content :)

But i also have this bug sometimes even if clipboard is empty at startup and have to kill klipper and restart it :(

At least during 'freeze' I see no wasted CPU cycles so don't try with a slower machine ;)

Hi, I chated with Bellegarde (thx again) on irc.   I had this problem too.
Debian sarge kdebase 3.3.2-1 and kdebase 3.3.2-1 pkgs.   I assume
both bugs should be merged?

reproduce:  in this textwidget on b.k.o with konqueror
       
  o add some fafsadfasdfsafasd strings
  o select some part of this string with the mouse
  o press backspace

==>  nothing for ~ 4 sec, no cpu cycles burned,  text gets removed

  o now add quickly some dfasdfasfsaf string

==> nothing for ~ 4 sec, no cpu cycles burned,  text gets inserted

during this hang.  Clicking with rmb on klipper systray icons has no
effect and when the text is modified the menu pops up to.

Solutions: Fix that works for me (tm):

  disable 'save clipper contents on exit'  and stop start klipper

above problems are gone.

  enable 'save clipper contents on exit' and stop start klipper

hangs are there again.  (verified again during I wrote this comment)

comparing a working and not working klipperrc  that even had some
chinese (?) spam in the clipboard (to simulate 'strange' chars ;)

--- /home/ach/.kde/share/config/klipperrc{.works}       2005-02-17 01:12:41.000000000 +0100
+++ /home/ach/.kde/share/config/klipperrc{.buggy}       2005-02-17 01:14:45.000000000 +0100
@@ -179,9 +179,8 @@

 [General]
 AutoStart=true
-ClipboardData=dfasdfsdafdsafadsf   dfsadsf   dsafasd,safasfas,argl.   I would miss then,po/xx/digikamimageplugin_sola,po/et/digikamimageplugins.po,digik,no po files
+ClipboardData=asdfdsafa,/home/ach/.kde/share/config/klipperrc,dsfadfdasfsda,'save clipboard contents on exit',用\n户\n,\n,的用
 IgnoreSelection=false
-KeepClipboardContents=false
 MaxClipItems=7
 NoEmptyClipboard=true
 Number of Actions=9


and here the working klipperrc as reference:

$ cat  /home/ach/.kde/share/config/klipperrc{.works}
[$Version]
update_info=klipperrc.upd:25082001,klipperrc.upd:kde3.1

[Action_0]
Description=Lookup Bug Number
Number of commands=2
Regexp=^(#|Bug |BR)\\d\\d\\d\\d\\d+$

[Action_0/Command_0]
Commandline=konqueror "http://bugs.kde.org/show_bug.cgi?id=`echo '%s' | sed -e 's/[^0-9]//g'`"
Description=lookup KDE bug report

[Action_0/Command_1]
Commandline=konqueror "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=`echo '%s' | sed -e 's/[^0-9]//g'`"
Description=lookup Debian bug report
Enabled=true

[Action_1]
Description=Debian Bug Number
Number of commands=1
Regexp=^dbug:\\d\\d\\d\\d\\d[\\d]+$

[Action_1/Command_0]
Commandline=konqueror %s
Description=Query Debian BTS

[Action_2]
Description=Jpeg-Image
Number of commands=1
Regexp=^\\/.+\\.jpg$

[Action_2/Command_0]
Commandline=kview %s
Description=Launch K&View

[Action_2/Command_1]
Commandline=ps x |grep -q '[n]etscape' && netscape -no-about-splash -remote openURL\\(%s, new-window\\) || netscape %s
Description=Open with &Netscape

[Action_2/Command_2]
Commandline=ps x |grep -q '[m]ozilla' && mozilla -remote openURL\\(%s, new-window\\) || mozilla %s
Description=Open with &Mozilla
Enabled=true

[Action_2/Command_3]
Commandline=kmail --body  %s
Description=Send &URL
Enabled=true

[Action_2/Command_4]
Commandline=kmail  --attach %s
Description=Send &Page
Enabled=true

[Action_3]
Description=Web-URL
Number of commands=5
Regexp=^https?://.

[Action_3/Command_0]
Commandline=dcop `dcop|grep konqueror|head -n 1` default 'createNewWindow(QString)' %s || kfmclient exec %s
Description=Open with &Konqueror

[Action_3/Command_1]
Commandline=ps x |grep -q '[n]etscape' && netscape -no-about-splash -remote openURL\\(%s, new-window\\) || netscape %s
Description=Open with &Netscape

[Action_3/Command_2]
Commandline=ps x |grep -q '[m]ozilla' && mozilla -remote openURL\\(%s, new-window\\) || mozilla %s
Description=Open with &Mozilla
Enabled=true

[Action_3/Command_3]
Commandline=kmail --body  %s
Description=Send &URL
Enabled=true

[Action_3/Command_4]
Commandline=kmail  --attach %s
Description=Send &Page
Enabled=true

[Action_4]
Description=Mail-URL
Regexp=^mailto:.

[Action_4/Command_0]
Commandline=kmail --composer `echo %s | sed 's/mailto://g'`
Description=Launch &Kmail

[Action_4/Command_1]
Commandline=konsole -e mutt `echo %s | sed 's/mailto://g'`
Description=Launch &mutt

[Action_5]
Description=Text File
Regexp=^\\/.+\\.txt$

[Action_5/Command_0]
Commandline=kedit %s
Description=Launch K&Edit

[Action_5/Command_1]
Commandline=kwrite %s
Description=Launch K&Write

[Action_6]
Description=Local file URL
Number of commands=2
Regexp=^file:.

[Action_6/Command_0]
Commandline=kmail --body  %s
Description=Send &URL

[Action_6/Command_1]
Commandline=kmail  --attach %s
Description=Send &File

[Action_7]
Description=Gopher URL
Number of commands=2
Regexp=^gopher:.

[Action_7/Command_0]
Commandline=kmail --body %s
Description=Send &URL
Enabled=true

[Action_7/Command_1]
Commandline=kmail  --attach %s
Description=Send &File
Enabled=true

[Action_7/Command_2]
Commandline=mozilla -remote openURL\\(%s, new-window\\)
Description=Open with &Mozilla
Enabled=true

[Action_7/Command_3]
Commandline=kmail --body  %s
Description=Send &URL
Enabled=true

[Action_7/Command_4]
Commandline=kmail  --attach %s
Description=Send &File
Enabled=true

[Action_8]
Description=ftp URL
Number of commands=5
Regexp=^ftp://.

[Action_8/Command_0]
Commandline=dcop konqueror default 'createNewWindow(QString)' %s || kfmclient exec %s
Description=Open with &Konqueror
Enabled=true

[Action_8/Command_1]
Commandline=netscape -no-about-splash -remote openURL\\(%s, new-window\\)
Description=Open with &Netscape
Enabled=true

[Action_8/Command_2]
Commandline=mozilla -remote openURL\\(%s, new-window\\)
Description=Open with &Mozilla
Enabled=true

[Action_8/Command_3]
Commandline=kmail --body  %s
Description=Send &URL
Enabled=true

[Action_8/Command_4]
Commandline=kmail  --attach %s
Description=Send &File
Enabled=true

[General]
AutoStart=true
ClipboardData=dfasdfsdafdsafadsf   dfsadsf   dsafasd,safasfas,argl.   I would miss then,po/xx/digikamimageplugin_sola,po/et/digikamimageplugins.po,digik,no po files
IgnoreSelection=false
KeepClipboardContents=false
MaxClipItems=7
NoEmptyClipboard=true
Number of Actions=9
ReplayActionInHistory=false
Strip Whitespace before exec=true
SynchronizeClipboards=false
Timeout for Action popups (seconds)=8
URLGrabberEnabled=true
UseGUIRegExpEditor=false
Version=v0.9.6



for ~ 4 sec

gnumdk@flanders:~/.kde/share/apps/klipper$ ls
history.lst

In kde3.4, history is here. Removing this file at kde startup fix the problem :)

So, why not remove "saving clipboard" for kde 3.4, this bug make konqueror a really bad experience :(

I search for this bug and here are my conclusion:

at startup, klipper call KlipperWidget::loadHistory()

KlipperWidget::loadHistory() call KlipperWidget::setClipboard()

KlipperWidget::setClipboard() call clip->setText( item.text(), QClipboard::Clipboard );

And here is the bug. Removing the last call will remove the bug. Really strange as KlipperWidget::setClipboard() works really well when not called by KlipperWidget::loadHistory() .

Will continue to search why...

>KlipperWidget::setClipboard() works really well when not called by
>KlipperWidget::loadHistory() .

False :(
 Everytime i select something from klipper, it make konqueror freeze. So problem come from setClipboard() and maybe clip->setText()...
A Qt bug?

*** This bug has been confirmed by popular vote. ***

I think it's a klipper problem because:

- launch klipper, tell him to put some text in current clipboard => konqueror textarea freeze
- launch another apps(kwrite for exemple), select text, copy it to clipboard => konqueror textarea stop freezing
- select another text from klipper => konqueror textarea freeze again
- ...

I also have this bug with Klipper + Konqueror (3.4 from CVS) freezing when selecting and part of a long text in textarea on webpages. I disabled Klipper and all is fine now.

Klipper causes all sorts of lags - for example it often causes windows to visibly freeze for a short while (likely candidates: konqueror, "open file" dialogs) if you double-click a location line-edit to select the contents and then right-click to open a context menu (to copy or cut the selected text).

Very strange. I'm on KDE 3.3.2 on Ark Linux and I do not see this behaviour at all. What version of X11 are you using?

Gary: that's probably because your Qt has http://webcvs.kde.org/qt-copy/patches/0048-qclipboard_hack_80072.patch?rev=1.3&view=markup applied. This is a dupe of bug #80072, most likely

Just compiled qt with this patch. 
It fix the problem but it's not perfect, textarea is always slower than with klipper disabled...

I finally managed to reproduce this. I think. These are my steps:
1. Enter some text in a textarea (like the one in this bug report)
2. Select the text, then immediately try to open Klipper
3. Notice Klipper hangs for a few seconds.
4. Notice how Konqueror freezes for some seconds at the time
5. Select something in another program or out of the textarea.
6. Notice how everything works as it should.

It's QT that's doing the actual blocking, in qt_xclb_wait_for_event(). The blocking occurs when Klipper queries the clipboard to try to determine if the clipboard is empty. 

    bool clipEmpty = ( data->format() == 0L );

This in turn calls 

QByteArray QClipboardWatcher::getDataInFormat(Atom fmtatom) const

which blocks and waits for the selection owner (that's Konqueror) to return the supported formats. Likely, Konqueror are likewise blocked at this stage.

I'll look further into this tomorrow. This bug looks very much like bug #80072. I agree. 

Thoughts and suggestions are welcome. 

Hi,

This bug is about Klipper and Konqueror slowing each other down. Most of it is 
fixed with a QT patch, but the bug is still there to lesser degree. Help in 
determining whether I should apply the attached patch would be appreciated. 
It is a ugly hack, but also an ugly bug with no easy solution.

As I suspected, this bug is a conflict between Klipper and Konqueror, more 
specifically between the QClipboardWatcher class provided by QT. Unless there 
is more than one bug, of couse :)

It seems that on mouse-up, Konqueror request the formats available on the 
selection or clipboard, concurrently with the selection being set. As Klipper 
also request the format available on the selection, they end up deadlocking 
with each other. I have back traces for interested parties :)

I can see no easy fix for this as the problem lies in QT converting an 
asynchronous query to a synchronous. This cannot be done without blocking the 
X event queue. When two application uses this functionality, deadlock will 
ensue.

I'm attaching a ugly hack <tm>. This works by delaying Klipper's collecting 
the clipboard contents for 30ms after the selection contents change. It fixes 
the problem, but might cause other subtle strangeness if anyone clicks fast 
enough, and if konqueror doesn't finish it's business before the 30ms, the 
bug will rear it's head again. Also, pure chance might cause this to occur 
anyway, and the latter goes with all QT programs.

I will, of course, try fix this in a better way for KDE4, but for now, time is 
up.

Thought and comments? Should I commit?



Created an attachment (id=9758)
klipper_konq_hack.patch

Strike that. I cannot reproduce this anymore. Turned out I had accidentally unapplied the 0048 patch.

I won't commit the patch above, since I never liked it, and the bug is manageable now. QT4 might very well fix this anyway, from what I hear.

My uneducated guess is that you are seeing the effects of QT trying to be crossplatform by converting the async X-windows behavior to sync behavior.

I see this problem too. Here in Bug #95302 and Bug #100234 you see this behaviour (and another depending on js, but that's solved).

One workaround there was maybe interesting: these people with ati or nvidia drivers were able to solve this bug with changing the option-value 
 Option "VideoOverlay" "on" to "off" and switch Option "OpenGLOverlay" "off" to "on". Then the input fields do not slow down.

So what's about the status of the patch right now? Bug #80072 talks about a fixed version, but does this apply for this bug, too?

This is fixed now as far as I can say. If you still can reproduce the problem, make sure your qt package has qt-copy patch #0048, and if yes, reopen and provide details about your problem.


*** This bug has been marked as a duplicate of 80072 ***

Well, almost two years later, with KDE 3.5.2 freshly installed
from FreeBSD ports, qt-x11-free-3.3.6 with 0048-qclipboard_hack_80072.patch
present in the ports collection, the bug is still very much alive and
has been troublesome to the extent that any editing in web applications
like OTRS or Wiki lengthier that few words makes konqueror useless
and one has to switch to firefox. I would hardly call it resolved!

  Mark