search

kvirc / KVIrc

The KVIrc IRC Client
http://www.kvirc.net/
GNU General Public License v2.0
244 stars 74 forks source link

latest HEAD (r4257) uses all RAM/SWAP #765

Closed DarthGandalf closed 9 years ago

DarthGandalf commented 9 years ago

Reported by mren on 18 Apr 2010 12:33:38 UTC I installed r4257 with deactivated dcc_video/theora (on Gentoo Linux) but after ~45 minutes KVIrc starts to use all my RAM (4 GB) and SWAP (5 GB). The only possibility I have then is to kill KVIrc or wait for the OOM killer to kill some other tasks and later on also KVIrc.

Build Flags: 
   CMAKE_INSTALL_PREFIX=/usr
   COMPILE_KDE_SUPPORT
   VERBOSE
   Threads=POSIX
   COMPILE_DBUS_SUPPORT
   COMPILE_WEBKIT_SUPPORT
   COMPILE_PHONON_SUPPORT
   COMPILE_OSS_SUPPORT
   COMPILE_AUDIOFILE_SUPPORT
   WITHOUT_GSM
   WITHOUT_DCC_VIDEO
   WITHOUT_OGG_THEORA

Migrated from: https://svn.kvirc.de/kvirc/ticket/765

DarthGandalf commented 9 years ago

Comment by ctrlaltca on 18 Apr 2010 14:09:31 Since i can't reproduce the problem, i ask you to please try at least one of the following:

  1. run kvirc inside valgrind, so that we can catch where the memory leak occurs:
valgrind --track-origins=yes --leak-check=full --show-reachable=yes --log-file=valgrind.txt kvirc -f

This will create a nice (and huge) log file.

  1. run kvirc with the default config, and see if the problem occurs. If not, try to enable all options that matches your current configuration until you see the problem. This could give us an hint on where the problem occus.
  2. Try to downgrade to a previous revision until the problem disappears. This could help us understanding the commit that caused the problem.

Owner: pragmaware → ctrlaltca Status: new → assigned

DarthGandalf commented 9 years ago

Comment by mren on 24 Apr 2010 20:35:00

  1. Valgrind won't start: 
zsh: illegal hardware instruction  valgrind --track-origins=yes --leak-check=full --show-reachable=yes  kvirc4 -f
  1. not tried
  2. this problem seems to be introduced between r4240 and r4245.
DarthGandalf commented 9 years ago

Comment by mren on 24 Apr 2010 20:35:45 Oh, I forgot: restoring the default script didn't changed anything.

DarthGandalf commented 9 years ago

Comment by curan on 07 May 2010 09:15:27 Just for reference: this bug has also been reported to the Debian BTS as [http://bugs.debian.org/580289 #580289]. The version in Debian is r4253, which would indicate, that mren's assumption of when the bug was introduced (see [comment:2 his comment]), is right (the only thing I can say for sure is, it must have been between r4170 and r4253 because that are the two versions that were in Debian and the former didn't have the problem).

DarthGandalf commented 9 years ago

Comment by curan on 07 May 2010 16:04:20 Another piece of information: I can trigger this a lot faster, if I start Kopete alongside KVIrc. And then the first application requesting more RAM (in this case it was [http://packages.debian.org/icedove Icedove]) triggers the OOM-Killer, as can be seen from [attachment:syslog_excerpt the attached excerpt from the syslog]. The downside is, that the oom-killer kills kdeinit4, klauncher and ksmserver before it goes after KVIrc. That causes KDM to restart.

DarthGandalf commented 9 years ago

Comment by curan on 07 May 2010 18:08:30 Ok, now I've an Valgrind log, which is - even when packed with lzma - some KB too large for the upload limit of Trac. I've put it on my server at http://dev.carbon-project.org/debian/kvirc/kvirc_valgrind.txt.lzma, you can fetch it with e.g. wget or curl. I didn't have time to read it, but I think I'll redo it with some more debug packages (Qt) installed.

DarthGandalf commented 9 years ago

Comment by ctrlaltca on 08 May 2010 10:41:02 Many thanks in your effort trying to track down this bug. Unfortunately i still can't understand exactly which part of the code produces the bug. Maybe you can try to use another valgrind tool that checks for heap allocation and post the resulting file?

valgrind --tool=massif kvirc
DarthGandalf commented 9 years ago

Comment by curan on 09 May 2010 21:56:38 I'll do that, in the meantime the reporter of the [http://bugs.debian.org/580289 Debian bug #580289] [http://bugs.debian.org/580289#72 has posted his valgring log], you can find it [http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=72;filename=valgrind.txt.gz;att=1;bug=580289 in the Debian BTS].

DarthGandalf commented 9 years ago

Comment by curan on 10 May 2010 14:34:32 Valgrind's Massif didn't report anything useful, at least not before the [http://linux-mm.org/OOM_Killer OOM Killer] killed Valgrind/Massif/KVIrc. The only logged messages of Massif are:

==3474== Massif, a heap profiler
==3474== Copyright (C) 2003-2009, and GNU GPL'd, by Nicholas Nethercote
==3474== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==3474== Command: kvirc
==3474== Parent PID: 2542
==3474==
==3474== Warning: Malformed stack trace detected.  In Massif's output,
==3474==          the size of an entry's child entries may not sum up
==3474==          to the entry's size as they normally do.
==3474== Warning: Malformed stack trace detected.  In Massif's output,
==3474==          the size of an entry's child entries may not sum up
==3474==          to the entry's size as they normally do.
==3474== Warning: Malformed stack trace detected.  In Massif's output,
==3474==          the size of an entry's child entries may not sum up
==3474==          to the entry's size as they normally do.
==3474==          (And Massif now won't warn about this again.)

If you wish, I can attach the tail of the syslog, but it looks basically like [attachment:syslog_excerpt the already attached syslog excerpt], with the difference, that now Valgrind/Massif is selected as the best to-be-killed process, which in turn kills KVIrc. The OOM Killer jumps in at exactly the point, when kvirc starts consuming all resources and another process requests more RAM. So the missing data from Massif might be due to the fact, that Valgrind gets killed before it can log anything.

DarthGandalf commented 9 years ago

Modified by curan on 10 May 2010 15:35:43

DarthGandalf commented 9 years ago

Comment by ctrlaltca on 10 May 2010 15:40:17 Massif should have created a file called

massif.out.<pid>

, where ‘’ is the process ID of kvirc.

DarthGandalf commented 9 years ago

Comment by curan on 11 May 2010 14:10:53 Didn't happen. I can produce such a file if I quit KVIrc "properly", i.e. without the OOM Killer terminating the KVIrc process. But I'm not sure this would give any useful information. Anyway, is there an option to force Valgrind to constantly write out the snapshots and not collect them and wait for the process termination? I didn't find anything.

If you want me to send you a version produced by a run with a "normal" quit, just let me know. Or should we consider bisecting? Might be faster if we can't get a good log.

DarthGandalf commented 9 years ago

Comment by curan on 11 May 2010 20:08:32 The reporter of [http://bugs.debian.org/580289 Debian bug #580289] [http://bugs.debian.org/580289#93 has posted] his [http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=93;filename=massif.out.12047.zip;att=1;bug=580289 Massif log]. Though he doubts its usefulness due to the fact, that in the short time he had KVIrc running no crash occurred.

In any case: I'm doing a bisect of the commits right now, it just'll take some time as I need to give KVIrc some time to crash, before I can mark a commit as "good".

DarthGandalf commented 9 years ago

Comment by ctrlaltca on 14 May 2010 10:13:09 As far as i can see from the massif analysis, no strange memory allocation has occured during the massif run. Good luck with the bisecting!

DarthGandalf commented 9 years ago

Comment by curan on 18 May 2010 14:35:29 Closed by r4339.

Resolution: none → fixed Status: assigned → closed