KildClient

Thanks your reply. And now I find this problem will be triggered if there is one or more trigger enabled, no matter using a simple string or regex as the pattern. Maybe there is something wrong with the perl's pattern matching on my system?

Please advise. Thanks in advance!

At 2014-04-30 07:39:13,"Eduardo M KALINOWSKI" <eduardo@kalinowski.com.br> wrote:
>On 04/29/2014 11:03 AM, hanpingtian wrote:
>> Hello,
>> I am using kildclient for a while and it's so great! Thanks a lot!
>>
>> But there is a problem: the memory it used always increase more and more
>> and in the end OOM-killer triggered.
>> From KDE's system activity tool, the heap is so large, it can occupy
>> several gigabytes before being
>> killed. And after being killed, looks like all the memory will be
>> released to OS.
>
>Well, I haven't seen this problem, nor has anyone else reported it, but...
>
>> I'm using several plugin written by myself
>> when this problem is seen.
>
>... some plugin could be a cause. You should try to isolate the problem
>by loading one plugin at a time and seeing which causes the memory
>usage. Then it might be possible to discover what is really causing the
>problem.
>
>> I'm using fedora 20 and KDE. kildclient it the latest version of git repo.
>>
>> Could you please take a look at this problem? Thanks in advance!
>>
>> BTW, I have registered a acount 'hpt' on the forum, but cannot recive
>> the verification mail. Could you please also take
>> a look at thist problem?
>
>A see that an email has been delivered to you. Perhaps it was caught in
>your spam filter. You can also request another email from the login page.
>
>
>--
>No woman can call herself free until she can choose consciously whether
>she will or will not be a mother.
> -- Margaret H. Sanger
>
>Eduardo M KALINOWSKI
>eduardo@kalinowski.com.br

Could you show a trigger that causes the problem? Preferably use the "Export" function so that all relevant details are included, try to attach the resulting file, or copy and paste its contents here.

Also, what is the version of libperl that you are using?

ekalin wrote:Could you show a trigger that causes the problem? Preferably use the "Export" function so that all relevant details are included, try to attach the resulting file, or copy and paste its contents here.

Also, what is the version of libperl that you are using?

A trigger like this can trigger this problem:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE kcworld-export SYSTEM "kcworld.dtd">

<kcworld-export>
<triggers>
<trigger name="oom" enabled="1" keepexecuting="0" rewriter="0" ignorecase="0">
<pattern>hello,world</pattern>
<action>look</action>
<highlight enabled="0" target="0" fg="-1" bg="-1" italics="-1" strike="-1" underline="-1"/>
</trigger>
</triggers>
<hooksv2>
</hooksv2>
</kcworld-export>

The libperl's version is perl-libs-5.18.2-289.fc20.x86_64.

I'm playing a game which using gb18030 as the character set. I'm wondering if this is the reason of this problem ...

Thanks.

OK, I have seen memory increasing when there are triggers. However, at least for me the increase is very slow, I could only notice it when sending huge amounts of data to the mud, that was why I couldn't detect it during normal usage. But if there is a great number of triggers, that might cause bigger increases.

The cause of the leak is probably when matching lines, but I haven't investigated it fully yet.

I know its been quite some time since this thread was started I'm experiencing a similar issue. I noticed the issue last night. At the time, kildclient had been running a couple days but resident memory was something like 500-600 MB and virtual had reached 1.2 GB. Its not going to break my system but it seems to be a whole lot more than any telnet client should require, no? This morning, I ran kildclient for a little over two hours ago and it got up to about 81 MB resident and 860 MB virtual. The numbers are quite a bit better but that still seems pretty bulky. To put perspective on the issue, on my system, kildclient starts up at a little over 32 MB resident and 365 MB virtual, growing to 48 MB and 570 MB once connected. So, boiling that down, after about 150 minutes, memory usage nearly doubles. After a few days, it grows about ten fold. Seems like a problem there.

32 to 48 MB seems perfectly reasonable these days (even though it feels huge compared to zMUD back in the day) but after idling for two or three days, half a gig seems pretty resource expensive. Given its relatively specialized job, I feel like even a feature-rich MU* client packed with scripts should stay under 120 MB or so. (Is that a realistic expectation or is that just showing my age?) It definitely shouldn't be expanding to half a gig as it idles.

I should note there is actually very little data being transfered over the connection. I call no actual scripts -- just half a dozen triggers running and two timers with send actions. (The most complicated of which, by far, is something like "^(\w+) looked at you.$"->"look $1".) The only plugin I'm using is kc256. All packages and libraries are current in terms of ubuntu repositories. (For the record, that's kildclient 3.0.0 and libperl 5.22. I did look into updating to kildclient 3.2.0 but, since I didn't see anything in the changelog that suggests a change to memory handling since my version, I didn't think it would be worth having to also upgrade glib, gthread, and gtk+ 3 to compile it. (I would prefer not to get into assuming the responsibility of manually updating and maintaining a bunch of widely-used libraries over this.)


Is anyone else experiencing something similar?
How much memory should kildclient be reserving?
Is there anything to suggest upgrading kildclient to 3.2.0 or upgrading supporting libraries would actually resolve the problem?
Can you offer any other advice for getting a handle on this? Its an older computer and I prefer to minimize resource consumption so I can let kildclient idle in the background.

Version 3.0.0 is somewhat old - it was released in 2014.

I can't remember when was the last time I made some improvements to memory management. It might as well have been before that, but it might be worth to at least check if the behavior still exists in the latest version.

I've noticed this as well, but it's not that big of a problem for me. I'm on the latest version btw.

I did upgrade to the latest version. Unfortunately, I haven't really thought about it after its been running a while to see whether or not the issue is fixed. I'll make a point to do so soon and post what I find.