Bug 55417 - memory leak in klipper
Summary: memory leak in klipper
Status: RESOLVED FIXED
Alias: None
Product: klipper
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Carsten Pfeiffer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-02 14:25 UTC by Walter F. J. Mueller
Modified: 2003-03-13 13:45 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Xlib patch (397 bytes, patch)
2003-03-13 13:21 UTC, Lubos Lunak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Walter F. J. Mueller 2003-03-02 14:25:41 UTC
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.
Comment 1 Carsten Pfeiffer 2003-03-03 12:08:02 UTC
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-----

Comment 2 Walter F. J. Mueller 2003-03-09 13:02:46 UTC
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
Comment 3 Lubos Lunak 2003-03-10 15:37:28 UTC
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. 
 
Comment 4 Walter F. J. Mueller 2003-03-10 21:42:00 UTC
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


Comment 5 Walter F. J. Mueller 2003-03-13 09:27:40 UTC
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

Comment 6 Lubos Lunak 2003-03-13 13:21:41 UTC
Created attachment 1165 [details]
Xlib patch
Comment 7 Lubos Lunak 2003-03-13 13:22:38 UTC
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.