Version: (using KDE KDE 3.1) Installed from: Debian stable Packages OS: Linux The virtual size as shown in 'top' increases steadily with time, suggesting that there is a memory leak. History size is set to 7. I have seen a VSZ for klipper as big as 578304 kb after some work with OpenOffice, so klipper had filled most of my swap.
Subject: Re: New: memory leak in klipper On Sunday 02 March 2003 14:25, you wrote: > The virtual size as shown in 'top' increases steadily with time, suggesting > that there is a memory leak. History size is set to 7. I have seen a VSZ > for klipper as big as 578304 kb after some work with OpenOffice, so > klipper had filled most of my swap. I'm quite sure there is no leak in klipper itself. Could be a problem with QClipboard's interaction with OpenOffice, but I'd be surprised about that, too. Maybe you could install valgrind -- http://freshmeat.net/redir/valgrind/22576/url_homepage/~sewardj and try running klipper as valgrind klipper --nofork to see if it finds anything useful on your machine. Or maybe it's a plain packaging/system problem... Best wishes Carsten Pfeiffer -----BEGIN PGP SIGNATURE----- iQEVAwUBPmM3jKWgYMJuwmZtAQHpeggAlU52pinDSU1e2ngpvAoDJXLKQTJLC8Ro FFhTl9bYS04QSBn5bFu5ItAFYxRDs3e28KHuvpBpmlSLjOk+E35Q1zLeOeL59n8i ciHrHpeEIPhREDLxY5X50T9M0uNHctRtQVWSY5RzEwscjWoqDEsVq/B5ZVDvgQMH 9fbT+Vb+6I5X/HwR5lY1UlRQ6l31dxgun0etHHyDDJ/77NqrOR/LpsG4d+FT0Y8G OkjEFtv2zoaWMFuO3C/Gw0KKfTQW+f8b42Vmf74r6IOxB218IRn6BwBDmtjYqT9w S0rQMDdAMprk5kRMQY3ayfbyuTYUXVMCe6drwVcG6Gfkg2NTxKgnHQ== =UP9O -----END PGP SIGNATURE-----
Subject: Re: memory leak in klipper Using valgrind 1.9.4 and 'valgrind --leak-check=yes klipper --nofork' I get after working for about 8 hours the following report LEAK SUMMARY: definitely lost: 2660729 bytes in 68588 blocks. possibly lost: 202004 bytes in 633 blocks. still reachable: 249892 bytes in 8068 blocks. suppressed: 0 bytes in 0 blocks. During this time I mostly worked with Konsole and XEmacs, so only rather small selections (typically a word or a line) were done. Most of the leakage is in 2659867 bytes in 68554 blocks are definitely lost in loss record 214 of 214 at 0x40167108: malloc (vg_clientfuncs.c:100) by 0x40EDA772: (within /usr/X11R6/lib/libX11.so.6.2) by 0x40EDA9A0: _XmbTextPropertyToTextList (in /usr/X11R6/lib/libX11.so.6.2) by 0x40EB68B4: XmbTextPropertyToTextList (in /usr/X11R6/lib/libX11.so.6.2) In addition there are the following error messages generated by klipper WARNING: KDE detected X Error: BadAtom (invalid Atom parameter) \x05 Major opcode: \x11 QClipboard: Unknown SelectionNotify event received QClipboard::setData: Cannot set X11 selection owner for PRIMARY Hope that helps, Walter -- Walter F.J. M
Can you add also --num-callers=30 to valgrind's arguments, and post the backtrace again? The backtrace for the leak isn't deep enough to show where it's coming from.
Subject: Re: memory leak in klipper Some answers to questions I got and some observations: 1. there is no significant leakage on klipper startup. A short session where klipper is started and immediately terminated shows no problems. 2. I'll rerun valgrind with --num-callers=30 3. I observed that there seems to be a problem between klipper and XEmacs version 21.4. The second or third selection in a XEmacs window produces the message QClipboard::setData: Cannot set X11 selection owner for PRIMARY on stdout. This selection (and usually all following in XEmacs) are not visible in klipper. If one goes back to a non-XEmacs window and does selections there the first few may still get ignored by klipper but after a few it gets back into normal behaviour. A few clicks into XEmacs will again produce said error message and behaviour. 4. I've seen XEmacs even hang when a big selection (many 10 kbyte) was made while klipper was running. That happened reproducibly when klipper was running, but did not occur without klipper being active. From that one might suspect that the interaction between klipper and XEmacs is part of the problem. Walter F.J. Mueller
Subject: Re: memory leak in klipper > Can you add also --num-callers=30 to valgrind's arguments, and post the backtrace again? The > backtrace for the leak isn't deep enough to show where it's coming from. Here the most relevant parts of a two day run with --num-callers=30: 2511329 bytes in 164731 blocks are definitely lost in loss record 214 of 214 at 0x40167108: malloc (vg_clientfuncs.c:100) by 0x40EDA772: (within /usr/X11R6/lib/libX11.so.6.2) by 0x40EDA9A0: _XmbTextPropertyToTextList (in /usr/X11R6/lib/libX11.so.6.2) by 0x40EB68B4: XmbTextPropertyToTextList (in /usr/X11R6/lib/libX11.so.6.2) by 0x409E7EAD: qt_xclb_read_property(_XDisplay *, unsigned long, unsigned long, bool, QMemArray<char> *, int *, unsigned long *, int *, bool) (in /usr/lib/libqt-mt.so.3.1.1) by 0x409E9A7A: QClipboardWatcher::getDataInFormat(unsigned long) const (in /usr/lib/libqt-mt.so.3.1.1) by 0x409E9963: QClipboardWatcher::encodedData(char const *) const (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A39C77: QTextDrag::decode(QMimeSource const *, QString &, QCString &) (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A334EA: QClipboard::text(QCString &, QClipboard::Mode) const (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A335A5: QClipboard::text(QClipboard::Mode) const (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A335FB: QClipboard::text(void) const (in /usr/lib/libqt-mt.so.3.1.1) by 0x40235846: KlipperWidget::clipboardContents(bool *) (in /usr/lib/klipper.so) by 0x40235D10: KlipperWidget::newClipData(void) (in /usr/lib/klipper.so) by 0x402365FA: KlipperWidget::qt_invoke(int, QUObject *) (in /usr/lib/klipper.so) by 0x40236893: Klipper::qt_invoke(int, QUObject *) (in /usr/lib/klipper.so) by 0x40A7FEF8: QObject::activate_signal(QConnectionList *, QUObject *) (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A7FE3D: QObject::activate_signal(int) (in /usr/lib/libqt-mt.so.3.1.1) by 0x40CE2877: QTimer::timeout(void) (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A9A8FA: QTimer::event(QEvent *) (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A2DB52: QApplication::internalNotify(QObject *, QEvent *) (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A2D953: QApplication::notify(QObject *, QEvent *) (in /usr/lib/libqt-mt.so.3.1.1) by 0x406ED489: KApplication::notify(QObject *, QEvent *) (in /usr/lib/libkdecore.so.4.1.0) by 0x40A10382: QEventLoop::activateTimers(void) (in /usr/lib/libqt-mt.so.3.1.1) by 0x409F237B: QEventLoop::processEvents(unsigned int) (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A3F31D: QEventLoop::enterLoop(void) (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A3F27A: QEventLoop::exec(void) (in /usr/lib/libqt-mt.so.3.1.1) by 0x40A2DCA9: QApplication::exec(void) (in /usr/lib/libqt-mt.so.3.1.1) by 0x402328CC: main (in /usr/lib/klipper.so) by 0x4102114E: __libc_start_main (in /lib/libc-2.2.5.so) by 0x8048550: (within /usr/bin/klipper) LEAK SUMMARY: definitely lost: 2512151 bytes in 164760 blocks. possibly lost: 7694 bytes in 416 blocks. still reachable: 249333 bytes in 8078 blocks. suppressed: 0 bytes in 0 blocks. -- Walter F.J. Mueller Mail: W.F.J.Mueller@gsi.de GSI, Abteilung KP3 Phone: +49-6159-71-2766 D-64291 Darmstadt FAX: +49-6159-71-2989 WWW: http://www-kp3.gsi.de/www/kp3/people/mueller.html
Created attachment 1165 [details] Xlib patch
With the help of the backtrace I have identified the memory leak in XFree-4.3's Xlib, and sent a patch fixing it to the XFree developers.