Bug 83659

Summary:	"Prevent empty clipboard" option makes klipper hang
Product:	[Unmaintained] klipper	Reporter:	Anton <selecter>
Component:	general	Assignee:	Carsten Pfeiffer <pfeiffer>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	gbell72
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	valgrind log of klipper freezing up desktop

Description Anton 2004-06-19 17:13:29 UTC

Version:            (using KDE KDE 3.2.90)
Installed from:    Compiled From Sources
Compiler:          3.4.0 
OS:                Linux

This is very old bug. Please fix it at least in kde 3.3!!! Even in 3.3.0 alpha1 it exists.

"It seems that the "Prevent empty clipboard" makes Klipper somewhat unstable. When it's enabled and I choose "Clear Clipboard history", Klipper goes into a state where it usually doesn't respond to the next (right-)click on the systray icon or occasionally pops up the normal menu but then hangs up for a while (and apparently sometimes even hangs the rest of the KDE). 
 
 While the problem is somewhat elusive and the description therefore a bit vague, I haven't been able to hang Klipper even once when "Prevent empty clipboard" has been disabled, which strongly suggests that there actually is some bug related to that option. 
 
 My guess is that "preventing empty" and "clearing history" don't play well together and lead the program to some nasty feedback loop or such. "

Here is soure of this quote: http://bugs.kde.org/show_bug.cgi?id=63832

Comment 1 Gardner Bell 2004-08-26 19:59:22 UTC

I've been noticing this behavior as well with 3.3.89 (CVS >=20040820).  Klipper has locked up my desktop 3 times since this morning when clicking on the icon in system tray.  The first two times my desktop became usable again by switching to Ctrl-Alt-F1 and back.  The third time this didn't work and I had to kill KDE.  Klipper seems to be working fine at the moment with "prevent empty clipboard" enabled and disabled.

Comment 2 Gardner Bell 2004-08-26 20:39:31 UTC

Ok I was able to reproduce this again, although only klipper locked up this time around.  I killed the process with kill -SIGSEGV <pid> and got this backtrace.

Using host libthread_db library "/lib/libthread_db.so.1".
[KCrash handler]
#34 0x415b6c62 in select () from /lib/libc.so.6
#35 0x4110c8ac in __JCR_LIST__ ()
   from /home/gdcb04/src/kde/qt-copy/lib/libqt-mt.so.3
#36 0xbfffe800 in ?? ()
#37 0x00000000 in ?? ()
#38 0x40bab80c in qt_xclb_wait_for_event (dpy=0x807dc00, win=23068700, 
    type=31, event=0xbfffe5f0, timeout=5000) at kernel/qclipboard_x11.cpp:521
#39 0x40bae1fa in QClipboardWatcher::getDataInFormat (this=0x813f2d0, 
    fmtatom=360) at kernel/qclipboard_x11.cpp:1409
#40 0x40bad917 in QClipboardWatcher::format (this=0x813f2d0, n=0)
    at kernel/qclipboard_x11.cpp:1276
#41 0x40c200a2 in QTextDrag::decode (e=0x813f2d0, str=@0xbfffe800, 
    subtype=@0xbfffe7c0) at kernel/qdragobject.cpp:901
#42 0x40c1bca4 in QClipboard::text (this=0x80cbe18, subtype=@0xbfffe7c0, 
    mode=Clipboard) at kernel/qclipboard.cpp:232
#43 0x40c1bd43 in QClipboard::text (this=0x80cbe18, mode=Clipboard)
    at kernel/qclipboard.cpp:268
#44 0x41ed9698 in KlipperWidget::clipboardSignalArrived (this=0x80f34d0, 
    selectionMode=false)
    at /home/gdcb04/src/kde/kdebase/klipper/toplevel.cpp:658
#45 0x41eda5fb in KlipperWidget::qt_invoke (this=0x80f34d0, _id=59, 
    _o=0xbfffe900) at toplevel.h:104
#46 0x41eda7f4 in Klipper::qt_invoke (this=0x80f34d0, _id=59, _o=0xbfffe900)
    at toplevel.moc:218
#47 0x40c7635b in QObject::activate_signal (this=0x80cbe18, clist=0x8112438, 
    o=0xbfffe900) at kernel/qobject.cpp:2357
#48 0x40c761fa in QObject::activate_signal (this=0x80cbe18, signal=3)
    at kernel/qobject.cpp:2326
#49 0x40fc8ed3 in QClipboard::dataChanged (this=0x80cbe18)
    at .moc/debug-shared-mt/moc_qclipboard.cpp:94
#50 0x40bace74 in QClipboard::event (this=0x80cbe18, e=0xbfffed10)
    at kernel/qclipboard_x11.cpp:1025
#51 0x40c13247 in QApplication::internalNotify (this=0xbffff020, 
    receiver=0x80cbe18, e=0xbfffed10) at kernel/qapplication.cpp:2635
#52 0x40c12704 in QApplication::notify (this=0xbffff020, receiver=0x80cbe18, 
    e=0xbfffed10) at kernel/qapplication.cpp:2358
#53 0x4074ad5b in KApplication::notify (this=0xbffff020, receiver=0x80cbe18, 
    event=0xbfffed10)
    at /home/gdcb04/src/kde/kdelibs/kdecore/kapplication.cpp:497
#54 0x40ba8e09 in QApplication::sendSpontaneousEvent (receiver=0x80cbe18, 
    event=0xbfffed10) at qapplication.h:494
#55 0x40ba0590 in QApplication::x11ProcessEvent (this=0xbffff020, 
    event=0xbfffef10) at kernel/qapplication_x11.cpp:3687
#56 0x40bb9f1c in QEventLoop::processEvents (this=0x80b2d20, flags=4)
    at kernel/qeventloop_x11.cpp:192
#57 0x40c275b6 in QEventLoop::enterLoop (this=0x80b2d20)
    at kernel/qeventloop.cpp:198
#58 0x40c274d2 in QEventLoop::exec (this=0x80b2d20)
    at kernel/qeventloop.cpp:145
#59 0x40c133c7 in QApplication::exec (this=0xbffff020)
    at kernel/qapplication.cpp:2758
#60 0x41ed4b46 in kdemain (argc=1, argv=0x807a750)
    at /home/gdcb04/src/kde/kdebase/klipper/main.cpp:44
#61 0x41ebf950 in kdeinitmain (argc=1, argv=0x807a750) at klipper_dummy.cpp:2
#62 0x0804cbdb in launch (argc=1, _name=0x807ae3c "klipper", 
    args=0x807ae44 "\001", cwd=0x0, envc=1, envs=0x807ae55 "", 
    reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x80503dd "0")
    at /home/gdcb04/src/kde/kdelibs/kinit/kinit.cpp:599
#63 0x0804e0e4 in handle_launcher_request (sock=8)
    at /home/gdcb04/src/kde/kdelibs/kinit/kinit.cpp:1163
#64 0x0804e627 in handle_requests (waitForPid=0)
    at /home/gdcb04/src/kde/kdelibs/kinit/kinit.cpp:1364
#65 0x0804f668 in main (argc=3, argv=0xbffff6e4, envp=0xbffff6f4)
    at /home/gdcb04/src/kde/kdelibs/kinit/kinit.cpp:1817

Comment 3 Gardner Bell 2004-08-26 23:28:50 UTC

Created attachment 7304 [details]
valgrind log of klipper freezing up desktop

Comment 4 Lubos Lunak 2004-11-11 14:35:12 UTC


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