[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-bugs
Subject:    [Bug 144984] Runaway memory leak (gigabytes in a few seconds)
From:       Christopher Layne <clayne () anodized ! com>
Date:       2007-10-29 12:24:03
Message-ID: 20071029122403.13171.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=144984         




------- Additional Comments From clayne anodized com  2007-10-29 13:24 -------
BTW: I'd just like to add that I've also seen this repeatedly on Gentoo AMD64.

However, I wasn't able to quite nail it down, but this is what I observed could \
consistently cause it:

1. rsync a project between two hosts, in my case, from a CentOS 4.x 32-bit TO the \
newer Gentoo AMD64 system.

2. Open said project and just build all.

3. The bottom "updating" progress bar will make it part way and then the process will \
begin consuming as much virtual memory as it can.

4. Kill said kdevelop process, re-open said project and things will then be fine.


Here is my theory - something is being saved to the kdevelop project file on the \
32-bit host that the 64-bit host is not liking. Upon issuing a project build, data is \
resaved or otherwise reconciled for the project file, but kdevelop's idea of things \
is just not right. Both systems are using 3.4.1.

I even managed to dump the entire /proc/<pid> directory when it was happening, btw:

proc status:
Name:   kdevelop
State:  S (sleeping)
SleepAVG:       98%
Tgid:   26414
Pid:    26414
PPid:   26029
TracerPid:      0
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000
FDSize: 64
Groups: 10 1000
VmPeak: 11555916 kB
VmSize: 11282492 kB
VmLck:         0 kB
VmHWM:   2157040 kB
VmRSS:   1817868 kB
VmData: 11108460 kB
VmStk:       120 kB
VmExe:        56 kB
VmLib:     47280 kB
VmPTE:     15268 kB
Threads:        3

proc numa_maps:
2aaab0000000 default anon=452630 dirty=452630 active=233426 N0=452630

proc smaps (snippet):
2aaab0000000-2aad5031d000 rw-p 2aaab0000000 00:00 0
Size:           11013236 kB
Rss:             1810520 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:   1810520 kB
Referenced:       415660 kB


Additionally at the time, I was also able to break into it via gdb and try and see \
what was going on - but due to my own lack of familiarity with the internal design of \
kdevelop didn't really glean much on my own. What I *did* see was what looked like an \
infinite loop repeatedly stuck doing QT-related string parsing.

_______________________________________________
KDevelop-bugs mailing list
KDevelop-bugs@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-bugs


[prev in list] [next in list] [prev in thread] [next in thread]