Version: (using KDE KDE 3.3.0) Installed from: Gentoo Packages Compiler: gcc (GCC) 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) This is actually a way I have reproduced 3 times - every time I tried it - freezing the whole KDE. I opened Acrobat Reader (acroread - version 5.0.9 for Linux), selected almost a page of text with the text select tool (the selected text scrolled off the screen), then clicked the Edit menu. Instead of the menu dropping down, KDE froze - except the LCD of the clock in the bottom right was still blinking, and the mouse cursor could still be moved but clicking on anything had no effect. Keyboard had no effect either. The bug doesn't happen if I don't select the text first. Ctrl+Alt+F1 allowed me to get to another virtual terminal, so it doesn't seem like a kernel bug. I killed the acroread process from that virtual terminal, and going back to the window manager the Acrobat Reader window was gone but everything else was still frozen. I am using X.org - I suppose the bug could be there too. Is there a way to find out?
Sounds like one of those klipper problems. Do you have klipper running in the system tray? Does it help if you quit it? Which Qt version are you using?
I cannot reproduce this with KDE 3.3.1, QT 3.3.3, x.org 6.8.0 and acroread 5.0.10. Everything works as expected. What I do: #install acroread emerge -av acroread # start acroread with a random pdf file acroread /my/random/pdf/file.pdf # scrolled down until text was encountered, selected a lot, pressed Edit menu (came up as expected), pressed select all, waited while progress bar finished, then selected Edit again. Worked as expected. If indeed it was klipper, it is very likely that it has already been fixed in CVS, as much of the clipboard handling has been rewritten. I'll leave this bug as unconfirmed for a while, until we can either reproduce it or we are reasonable sure it is gone.
I can't reproduce the bug anymore, so I'm marking it as resolved. I am now using those versions mentioned except for KDE which is 3.3.2. However, I don't have klipper running and I doubt I did at the time, but maybe the code to copy and paste between applications is the same?
If Klipper wasn't running, I don't think it could be KDE at all. More likely it was X itself, with QT as the outside chance. Thanks for following up on this.
I was just able to reproduce this bug as many times as I wanted. As soon as I restarted klipper it went away and I could not reproduce it any more. This is what I did: * $ acroread some_document.pdf * mark a phrase * press the edit menu entry after that I was seeing the _exact_ behaveour the original reporter was seeing. I tried to attach xev to acroread to see what events it wasn't getting none except for: VisibilityNotify event, serial 11, synthetic NO, window 0x480015a, state VisibilityFullyObscured VisibilityNotify event, serial 11, synthetic NO, window 0x480015a, state VisibilityUnobscured which I account for changing from X to a text-terminal (CTRL-Alt-F1). After that I stopped klipper as Waldo Bastian suspected above and the problem went away to the point of not being reproducible any more even after starting klipper again. This looks similarily to bugs.debian.org/214514 My System here: kdelibs4 4:3.3.2-1 KDE core libraries libart-2.0-2 2.3.17-1 Library of functions for 2D graphi libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an libfam0c102 2.7.0-6 client library to control the FAM libgcc1 1:3.4.3-6 GCC support library libice6 4.3.0.dfsg.1-10 Inter-Client Exchange library libidn11 0.5.2-3 GNU libidn library, implementation libpng12-0 1.2.8rel-1 PNG library - runtime libqt3c102-mt 3:3.3.3-8 Qt GUI Library (Threaded runtime v libsm6 4.3.0.dfsg.1-10 X Window System Session Management libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte libxrender1 0.8.3-7 X Rendering Extension client libra xlibs 4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu zlib1g 1:1.2.2-3 compression library - runtime Is there a way to reopen this bug? *t
Please try with KDE3.4 first.
To comment #5: You say it went away when you restarted klipper. Had you upgraded a package while the first instance of klipper was running?
Maybe this is a dup of bug #80072. Could you try this on your libqt3c102-mt.so library? (strange name, btw). nm --demangle libqt2c102-mt.so | grep qt_qclipboard_bailout_hack If it shows nothing, please ask your distributor if they will please include patch 0048 from qt-copy and/or test with this patch.
(Mostly for the record, 'libqt3c102' is the name of the package, and it's named so due to the last C++ ABI transition, a while ago. The library file is still libqt-mt.so(.3). Having said that, the only *_hack function in Debian's version seems to be "qt_hebrew_keyboard_hack".)
Then this is almost certainly a dup of 80072. Could Debian be persuaded to patch QT? The patch will only affect Klipper; the patch is only neccesary for QT3, here is no easy fix and the bug is somewhat serious (total freeze of most of the desktop). How do I post a comment to that bug system? It seems to be mail based, somehow.
To comment #6 (Lubos Lunak wrote:) > Please try with KDE3.4 first. Sorry that's unfortunately out of my capacities atm. To comment #7 (Adam wrote:) > Had you upgraded a package while the first instance of klipper was running? No I did not upgrade anything To comment #8 (Esben Mose Hansen wrote:) > nm --demangle libqt2c102-mt.so | grep qt_qclipboard_bailout_hack > > If it shows nothing, please ask your distributor if they will please include patch 0048 from qt-copy and/or test with this patch. It doesn't show anything: # ls -l /usr/lib/libqt-mt.so.3.3.3 -rw-r--r-- 1 root root 7233776 Jan 14 17:02 /usr/lib/libqt-mt.so.3.3.3 # nm --demangle /usr/lib/libqt-mt.so.3.3.3 nm: /usr/lib/libqt-mt.so.3.3.3: no symbols However I've downloaded Debian's copy of Qt and the patch is not in there. I'm now locally building a copy of Qt out of Debian's sources with Lubos' patch applied. However since I am not able to induce the bug at will I can't see how I'd be able to test whether the patch fixes the bug or not. Lubosi, since you'we provided the patch, have you been able to somehow induce/reproduce the bug at will? It'd be nice if you could tell me how so I could test the fix here. One last comment: I'm not getting Cc: of comments to this bug - could someone include me in the Cc's please? Thanks, *t
If you want to be Cc'ed, you can add yourself in the bug page.
Tomas: Since KDE3.4 is supposed to be out in a couple of days, and there have been several possibly relevant Klipper, it doesn't make much sense to do anything about this bug until somebody is able to confirm it still exists with KDE3.4. Esben: nm when used on .so objects needs -D, it can make a difference.
To comment #13 (Lubos Lunak wrote:) > Since KDE3.4 is supposed to be out in a couple of days, and there have been > several possibly relevant Klipper, it doesn't make much sense to do anything > about this bug until somebody is able to confirm it still exists with > KDE3.4. Your point about KDE3.4 is clear. However, since Debian is "close" to releasing the next stable release of Debian it will certainly [1] not include KDE3.4. So my goal would be to verify if your patch fixes the "KDE freezing bug" [2]. If so I can propose Debian's Qt maintainers to include the fix. That way Debian would ship a stabler and more responsive KDE. If you could tell me how to reliably reproduce the bug that would help me a lot. Thanks, *t [1] I am not qualified to state that, but it's an educated guess. Including a new KDE release usualy takes weeks to months and efforts to include it probably won't start until after the official KDE3.4 release. [2] Note that there have been many people seeing the bug in Debian, so this is a real issue. See: http://bugs.debian.org/214514
Sorry, I don't know how to reproduce the problem. After all, it's you who has the problem, not us.
One reliable way to reproduce *a* bug that 0048 fixes: 1. Write 3 different words in a konqueror textarea (like the one in this bug) 2. Double click each in turn. 3. Notice the freeze. This sort of behavior is gone with Mr. Lunak's patch. Hope this helps. PS: Thanks for telling me about -D :-D