Version: 4:3.4.3-0Ubuntu1 (using KDE KDE 3.4.3) Installed from: Ubuntu Packages OS: Linux First sorry for my english... Now the problem: I configured the server to accept non invited connections and also configured a password. When I go on an other computer (Win32) and start a VNC client to connect to the "server" everything works (Connection + authentication + remote screen apears) but as soon as I move the mouse the client closes almost immediatly. I tried to use realvnc 4.1 and UltraVnc 1.0.1 (On the client side) When I go back to the server ther is a messga telling me that the application closed with the message 6 (SIGABRT) And here are the calls made by the application: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cette pile des appels apparaît être inutilisable. C'est probablement dû au fait que votre paquetage a été construit d'une manière qui empêche de créer des piles d'appels corrects, ou que le cadre de pile a été sérieusement corrompu dans l'incident. (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The install of my Ubuntu 5.10 (French) is a fresh install (using only the official Canonical repositories) Thank you for your help and good luck Novad
I have the same bug with Kubuntu dapper Up 2 date. here is the launchpad report : https://launchpad.net/distros/ubuntu/+source/kdenetwork/+bug/39046
KRFB has been unmaintained for a very long time, and it does not look like anyone wants to take over the job. The future of the program is at this time uncertain.
oki! it's there any qt or open source alternative to run a permanent VNC server with non invite connection on kde/linux?
VNC is really more of a Windows thing. X supports remote logins natively via the DISPLAY variable. You can also look into NX (www.nomachine.com), X11VNC (http://www.karlrunge.com/x11vnc/), and most of the VNC servers out there have directions to plug them into the X server, with better or worse results based on the particular flavor.
If you could provide a proper backtrace of this crash, it'd be possible to track it down. Otherwise, there is nothing we can do.
Sorry about all the noise, my browser is really flakey today.
I'm also seeing this problem; here's the relevent entries from my .xsession-errors in case they're useful: kdecore (KNetwork socket): Deprecated function called:[static int KExtendedSocket::resolve(sockaddr*, ksocklen_t, QString&, QString&, int)] kdesktop: 1156413465 1156414065 kdesktop: DPMSInfo 0 \x01 kdesktop: XScreenSaverQueryInfo 0 3 DCOP: register 'krfb-5277' -> number of clients is now 17 kdeui (KAboutDialog): setPixmap (iconName): krfb kicker: *** Embed 48234745 into 25179719. window=0 kicker: > before reparent: parent=0x119 kicker: > Loop 0: > reparent of 0x2e000f9 into 0x1803647 successful QFile::open: No file name specified kwin: User timestamp, initial:4294967295 kwin: User timestamp, ASN:4294967295 kwin: User timestamp, final:'ID:48234764;WMCLASS:krfb:krfb;Caption:New Connection - Desktop Sharing':1067263952 kwin: Activation, compared:'ID:48234764;WMCLASS:krfb:krfb;Caption:New Connection - Desktop Sharing':1067263952:1067260710:true kdesktop: 1156413470 1156414070 kdesktop: DPMSInfo 0 \x01 kdesktop: XScreenSaverQueryInfo 0 3 QFile::open: No file name specified kdesktop: 1156413475 1156414075 kdesktop: DPMSInfo 0 \x01 kdesktop: XScreenSaverQueryInfo 0 3 krfb: ../nptl/pthread_mutex_lock.c:108: __pthread_mutex_cond_lock: Assertion `mutex->__data.__owner == 0' failed. KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = krfb path = <unknown> pid = 5277 kdeinit: Got EXEC_NEW 'drkonqi' from socket. Could not load library! Trying exec.... DCOP: unregister 'krfb-5277' kdesktop: 1156413480 1156414075 kdesktop: DPMSInfo 0 \x01 kdesktop: XScreenSaverQueryInfo 0 3 kdeinit: PID 5281 terminated. DCOP: register 'anonymous-5282' -> number of clients is now 17 DCOP: 'anonymous-5282' now known as 'drkonqi-5282' kwin: User timestamp, initial:4294967295 kwin: User timestamp, ASN:4294967295 kwin: User timestamp, final:'ID:48234501;WMCLASS:drkonqi:drkonqi;Caption:Desktop Sharing - The KDE Crash Handler':1067277557 kwin: Activation, compared:'ID:48234501;WMCLASS:drkonqi:drkonqi;Caption:Desktop Sharing - The KDE Crash Handler':1067277557:1067260710:true kdesktop: 1156413485 1156414075 kdesktop: DPMSInfo 0 \x01 kdesktop: XScreenSaverQueryInfo 0 3 DCOP: unregister 'drkonqi-5282' X Error: BadWindow (invalid Window parameter) 3 Major opcode: 20 Minor opcode: 0 Resource id: 0x2e00005 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 19 Minor opcode: 0 Resource id: 0x2e00005
Same problem here. Backtrace of KRFB: (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47786091373552 (LWP 7657)] [New Thread 1098918224 (LWP 7660)] [New Thread 1090525520 (LWP 7659)] 0x00002b761014fb9b in __read_nocancel () from /lib/libpthread.so.0 #0 0x00002b761014fb9b in __read_nocancel () from /lib/libpthread.so.0 #1 0x00002b76103a1eb4 in _X11TransGetMyAddr () from /usr/lib64/libX11.so.6 #2 0x00002b76103a4f58 in _XRead () from /usr/lib64/libX11.so.6 #3 0x00002b76103a57d9 in _XReply () from /usr/lib64/libX11.so.6 #4 0x00002b761039a4fd in XQueryPointer () from /usr/lib64/libX11.so.6 #5 0x00002b760e9632f1 in QCursor::pos () from /usr/qt/3/lib64/libqt-mt.so.3 #6 0x0000000000414c20 in ?? () #7 0x000000000041520d in ?? () #8 0x00002b760e9dd1fc in QObject::activate_signal () from /usr/qt/3/lib64/libqt-mt.so.3 #9 0x00002b760e9dd7c9 in QObject::activate_signal () from /usr/qt/3/lib64/libqt-mt.so.3 #10 0x00002b760e9f2ed7 in QTimer::event () from /usr/qt/3/lib64/libqt-mt.so.3 #11 0x00002b760e9a3234 in QApplication::internalNotify () from /usr/qt/3/lib64/libqt-mt.so.3 #12 0x00002b760e9a37d2 in QApplication::notify () from /usr/qt/3/lib64/libqt-mt.so.3 #13 0x00002b760dcbe1c8 in KApplication::notify () from /usr/kde/3.5/lib64/libkdecore.so.4 #14 0x00002b760d70ce10 in QApplication::sendEvent () from /usr/kde/3.5/lib64/libkdeui.so.4 #15 0x00002b760e997413 in QEventLoop::activateTimers () from /usr/qt/3/lib64/libqt-mt.so.3 #16 0x00002b760e968ff7 in QEventLoop::processEvents () from /usr/qt/3/lib64/libqt-mt.so.3 #17 0x00002b760e9ae264 in QEventLoop::enterLoop () from /usr/qt/3/lib64/libqt-mt.so.3 #18 0x00002b760e9ae15d in QEventLoop::exec () from /usr/qt/3/lib64/libqt-mt.so.3 #19 0x0000000000418b0c in QDeepCopy<QString>::QDeepCopy () #20 0x00002b7610df4134 in __libc_start_main () from /lib/libc.so.6 #21 0x0000000000411a69 in ?? () #22 0x00007fffffc9b668 in ?? () #23 0x0000000000000000 in ?? ()
I'm seeing this behaviour too - sometimes it takes a few seconds, but the crash occurs. Client: WinXP fully patched running UltraVNC 1.0.2 Server: KUbuntu 6.0.6 fully patched Here is the backtrace: (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) ... (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1232254496 (LWP 23153)] [New Thread -1257395280 (LWP 23156)] [New Thread -1249002576 (LWP 23155)] (no debugging symbols found) ... (no debugging symbols found) 0xffffe410 in __kernel_vsyscall () #0 0xffffe410 in __kernel_vsyscall () #1 0xb71c456b in __read_nocancel () from /lib/tls/i686/cmov/libpthread.so.0 #2 0xb7225447 in XWriteBitmapFile () from /usr/lib/libX11.so.6 #3 0xb72256d3 in _X11TransRead () from /usr/lib/libX11.so.6 #4 0xb7229196 in _XRead () from /usr/lib/libX11.so.6 #5 0xb722a1d8 in _XReply () from /usr/lib/libX11.so.6 #6 0xb721c1ed in XQueryPointer () from /usr/lib/libX11.so.6 #7 0xb7943da2 in QCursor::pos () from /usr/lib/libqt-mt.so.3 #8 0x08058466 in ?? () #9 0xbfa1ab80 in ?? () #10 0x0000029b in ?? () #11 0x00000149 in ?? () #12 0x08276e40 in ?? () #13 0x000002c6 in ?? () #14 0x0817d908 in ?? () #15 0x0000029b in ?? () #16 0x00000149 in ?? () #17 0x0000029b in ?? () #18 0x00000149 in ?? () #19 0x08080d08 in typeinfo name for QMemArray<char> () #20 0xb7ec2e01 in ?? () from /usr/lib/libqt-mt.so.3 #21 0x00000000 in ?? ()
*** Bug 130919 has been marked as a duplicate of this bug. ***
Same thing for me, Client everything from OS X running Chicken of the VNC to Windows running RealVNC to other Linux boxes, server being a gentoo box on amd64. Here's my backtrace: (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47948211251072 (LWP 4806)] [New Thread 1098918208 (LWP 4813)] [New Thread 1090525504 (LWP 4812)] 0x0000003e7060cd5b in __read_nocancel () from /lib/libpthread.so.0 #0 0x0000003e7060cd5b in __read_nocancel () from /lib/libpthread.so.0 #1 0x0000003e70a46334 in _X11TransGetMyAddr () from /usr/lib64/libX11.so.6 #2 0x0000003e70a3f604 in _XRead () from /usr/lib64/libX11.so.6 #3 0x0000003e70a3fe85 in _XReply () from /usr/lib64/libX11.so.6 #4 0x0000003e70a362ed in XQueryPointer () from /usr/lib64/libX11.so.6 #5 0x000000398a543f8e in QCursor::pos () from /usr/qt/3/lib64/libqt-mt.so.3 #6 0x00007fffda952454 in ?? () #7 0x00007fffda952450 in ?? () #8 0x00007fffda95244c in ?? () #9 0x0000003e70035960 in __after_morecore_hook () from /lib/libc.so.6 #10 0x0000000000000013 in ?? () #11 0x0000000000000013 in ?? () #12 0x0000000000000310 in ?? () #13 0x00000000009c3228 in ?? () #14 0x0000000000000c40 in ?? () #15 0x0000003e6fe6c056 in free () from /lib/libc.so.6 #16 0x00007fffda9524b0 in ?? () #17 0x00007fffda952490 in ?? () #18 0x000000398a9796b5 in QGList::QGList () from /usr/qt/3/lib64/libqt-mt.so.3 #19 0x00007fffda952660 in ?? () #20 0x00007fffda9524b0 in ?? () #21 0x000000000075d4e0 in ?? () #22 0x00000000004160d3 in qstrlen () #23 0x00007fffda952660 in ?? () #24 0x0000000000413c17 in ?? () #25 0x0000000000432d70 in typeinfo for QGList () #26 0x000000398b15b501 in KApplication::notify () from /usr/kde/3.5/lib64/libkdecore.so.4 #27 0x0000000000000000 in ?? ()
This sounds related to bug #102305
not using threads anymore in KDE 4.0
*** Bug 102305 has been marked as a duplicate of this bug. ***
*** Bug 57203 has been marked as a duplicate of this bug. ***
@Jaison Lee: Krfb isn't for remote logins, it's for connecting to local sessions.
now that this bug is mark as resolved is there a patch we can apply to kde 3.5.6 ?
nope, it's only resolved in trunk/KDE4 due to a complete rewrite, can't be easily fixed for 3.5.x
@#18: But that would mean krfb in KDE 3.5 is not and never will be usable with other VNC clients? I have tried TightVNC and RealVNC, both connected and after a few seconds crashed krfb with this krfb: ../nptl/pthread_mutex_lock.c:108: __pthread_mutex_cond_lock: Assertion `mutex->__data.__owner == 0' failed. problem. In that case imho this woeful fact should be mentioned somewhere in the program until it is fixed, because obviously the use case of connecting with a non-KDE VNC client is very common, and it seems to work with none of them. So rather than wasting peoples time, telling them it won't work right away might be a more pragmatic solution. Does anyone understand what exactly happens when this occurs?
The failed assertion in ../nptl/pthread_mutex_lock.c:108 can be fixed with the attached patch. The function pthread_cond_timedwait gets called without prior locking of the mutex. According to pthread_cond_timedwait's manpage, this results in undefined behavior.
Created attachment 21009 [details] Fix for assertion failure in ../nptl/pthread_mutex_lock.c caused by krfb
Yeah cool Michael, the patch works - gooOO00ood bowling ;)
SVN commit 733442 by mueller: fix locking error CCBUG: 124529 M +1 -0 main.c WebSVN link: http://websvn.kde.org/?view=rev&revision=733442