Closed GoogleCodeExporter closed 9 years ago
Hi, I'm on Kubuntu 10.04.3 LTS and I have the same problem.
I get it after a few day's of running and usually after I added a torrent. When
Transgui is open it becomes very unresponsive and the Xorg process takesup a
whole core.
When I manage to close Transgui to the system tray Xorg go's to normal behavior.
When I stop Transgui and start it again, everything is normal again until after
a few day's I get the same problem.
Original comment by r.korv...@gmail.com
on 11 Feb 2012 at 8:22
Hi,
I had the same problem. I've changed nvidia-drivers and this solved the problem
for me. I'm currently using (current version) from ubuntu repository which is
marked as recommended. Previously I was using post-release updates so that was
a root of the problem. Hope this hint help you.
Original comment by kstar...@gmail.com
on 11 Feb 2012 at 8:46
Is changing of nvidia-drivers resolves the problem for everyone?
Original comment by j...@cp-lab.com
on 21 Mar 2012 at 1:19
Don't have nvidia, I have an ati card and use the opensource drivers.
Original comment by r.korv...@gmail.com
on 21 Mar 2012 at 2:07
Issue 501 has been merged into this issue.
Original comment by j...@cp-lab.com
on 23 Mar 2012 at 3:14
Original comment by j...@cp-lab.com
on 23 Mar 2012 at 3:28
In addition:
When xorg takes allot of recourses and i select individual files from a torrent
to flag them as high priority/do not download/normal. Xorg sometimes freezes
completely and I have to restart the display manager.
Original comment by r.korv...@gmail.com
on 23 Mar 2012 at 3:46
I see.
What about the memory consumption of transgui process?
How long transgui should run in order to trigger this bug?
Does changing the refresh interval to smaller value make the bug appearance
time shorter?
Original comment by j...@cp-lab.com
on 23 Mar 2012 at 3:58
I can't say there is an specific amount of time it needs to run to trigger the
bug. It mostly happens after it's been running for a couple of day's and I add
a few new torrents.
Changing the refresh-rate doesn't seem to make bug appear sooner.
I forgot to check the memory consumption, will check it when i get the bug
again.
Original comment by r.korv...@gmail.com
on 29 Mar 2012 at 8:17
The process transgui (with pid 5332) is using approximately 110.9 MB of memory.
It is using 109.3 MB privately, and a further 5.6 MB that is, or could be,
shared with other programs.
Dividing up the shared memory between all the processes sharing that memory we
get a reduced shared memory usage of 1645.0 KB. Adding that to the private
usage, we get the above mentioned total memory footprint of 110.9 MB.
3.3 MB is swapped out to disk, probably due to a low amount of available memory
left.
Library Usage
The memory usage of a process is found by adding up the memory usage of each of
its libraries, plus the process's own heap, stack and any other mappings, plus
the stack of its one other thread.
Private
more
109448 KB [heap]
1796 KB /home/*/transgui-3.2-i386-linux/transgui
240 KB /usr/lib/libgtk-x11-2.0.so.0.2000.1
64 KB [stack]
32 KB /usr/lib/gtk-2.0/2.10.0/engines/libqtcurve.so
Shared
more
1388 KB /usr/lib/libgtk-x11-2.0.so.0.2000.1
768 KB /SYSV00000000 (deleted)
496 KB /lib/tls/i686/cmov/libc-2.11.1.so
436 KB /usr/lib/libgdk-x11-2.0.so.0.2000.1
376 KB /usr/lib/libcairo.so.2.11000.0
Totals
Private 111880 KB (= 2364 KB clean + 109516 KB dirty)
Shared 5700 KB (= 4932 KB clean + 768 KB dirty)
Rss 117580 KB (= Private + Shared)
Pss 113525 KB (= Private + Shared/Number of Processes)
Swap 3336 KB
---------
The process Xorg (with pid 20221) is using approximately 59.8 MB of memory.
It is using 54.7 MB privately, and a further 10.8 MB that is, or could be,
shared with other programs.
Dividing up the shared memory between all the processes sharing that memory we
get a reduced shared memory usage of 5.1 MB. Adding that to the private usage,
we get the above mentioned total memory footprint of 59.8 MB.
4.7 MB is swapped out to disk, probably due to a low amount of available memory
left.
Library Usage
The memory usage of a process is found by adding up the memory usage of each of
its libraries, plus the process's own heap, stack and any other mappings.
Private
more
54000 KB [heap]
1024 KB /usr/bin/Xorg
220 KB /usr/lib/xorg/modules/drivers/radeon_drv.so
136 KB [stack]
84 KB /usr/lib/xorg/modules/libfb.so
Shared
more
10312 KB /SYSV00000000 (deleted)
408 KB /lib/tls/i686/cmov/libc-2.11.1.so
88 KB /usr/lib/libpixman-1.so.0.21.4
60 KB /lib/tls/i686/cmov/libpthread-2.11.1.so
56 KB /lib/ld-2.11.1.so
Totals
Private 56048 KB (= 2444 KB clean + 53604 KB dirty)
Shared 11016 KB (= 11016 KB clean + 0 KB dirty)
Rss 95220 KB (= Private + Shared)
Pss 61249 KB (= Private + Shared/Number of Processes)
Swap 4768 KB
-----------
Just restarted transgui and will post in a hour or so the memory ussage when
the bug isn't triggered
Original comment by r.korv...@gmail.com
on 1 Apr 2012 at 6:51
Process 13730 - transgui
Summary
The process transgui (with pid 13730) is using approximately 18.2 MB of memory.
It is using 16.1 MB privately, and a further 7.8 MB that is, or could be,
shared with other programs.
Dividing up the shared memory between all the processes sharing that memory we
get a reduced shared memory usage of 2.1 MB. Adding that to the private usage,
we get the above mentioned total memory footprint of 18.2 MB.
Library Usage
The memory usage of a process is found by adding up the memory usage of each of
its libraries, plus the process's own heap, stack and any other mappings, plus
the stack of its one other thread.
Private
more
13376 KB [heap]
2312 KB /home/x/transgui-3.2-i386-linux/transgui
204 KB /usr/lib/libgtk-x11-2.0.so.0.2000.1
40 KB [stack]
28 KB /usr/lib/libgdk-x11-2.0.so.0.2000.1
Shared
more
1604 KB /usr/lib/libgtk-x11-2.0.so.0.2000.1
764 KB /SYSV00000000 (deleted)
592 KB /lib/tls/i686/cmov/libc-2.11.1.so
464 KB /usr/lib/libgdk-x11-2.0.so.0.2000.1
444 KB /lib/libglib-2.0.so.0.2400.1
Totals
Private 16464 KB (= 2396 KB clean + 14068 KB dirty)
Shared 7944 KB (= 7180 KB clean + 764 KB dirty)
Rss 24412 KB (= Private + Shared)
Pss 18639 KB (= Private + Shared/Number of Processes)
Swap 0 KB
--------------------
Process 20221 - Xorg
Summary
The process Xorg (with pid 20221) is using approximately 65.2 MB of memory.
It is using 60.1 MB privately, and a further 10.8 MB that is, or could be,
shared with other programs.
Dividing up the shared memory between all the processes sharing that memory we
get a reduced shared memory usage of 5.1 MB. Adding that to the private usage,
we get the above mentioned total memory footprint of 65.2 MB.
4.6 MB is swapped out to disk, probably due to a low amount of available memory
left.
Library Usage
The memory usage of a process is found by adding up the memory usage of each of
its libraries, plus the process's own heap, stack and any other mappings.
Private
more
59512 KB [heap]
1024 KB /usr/bin/Xorg
220 KB /usr/lib/xorg/modules/drivers/radeon_drv.so
136 KB [stack]
84 KB /usr/lib/xorg/modules/libfb.so
Shared
more
10308 KB /SYSV00000000 (deleted)
408 KB /lib/tls/i686/cmov/libc-2.11.1.so
88 KB /usr/lib/libpixman-1.so.0.21.4
60 KB /lib/tls/i686/cmov/libpthread-2.11.1.so
56 KB /lib/ld-2.11.1.so
Totals
Private 61576 KB (= 2464 KB clean + 59112 KB dirty)
Shared 11012 KB (= 11012 KB clean + 0 KB dirty)
Rss 96896 KB (= Private + Shared)
Pss 66775 KB (= Private + Shared/Number of Processes)
Swap 4740 KB
Original comment by r.korv...@gmail.com
on 1 Apr 2012 at 8:21
Thanks for the info. It seems a memory leak causes the problem. I'll try to
investigate.
Original comment by j...@cp-lab.com
on 1 Apr 2012 at 8:38
I have checked the code for memory leaks - none have been found.
I have no idea where to dig...
Original comment by j...@cp-lab.com
on 2 Apr 2012 at 5:37
Original comment by j...@cp-lab.com
on 7 Apr 2012 at 2:39
Original comment by j...@cp-lab.com
on 7 Apr 2012 at 2:40
Please test a binary release of transgui 4.0.1
Original comment by j...@cp-lab.com
on 8 Apr 2012 at 1:36
Now running 4.0.1.
Will get back in a week or sooner when the bug is triggered.
Original comment by r.korv...@gmail.com
on 8 Apr 2012 at 2:29
Didn't get the bug in 4.0.1 or 4.0.2.
Original comment by r.korv...@gmail.com
on 18 Apr 2012 at 10:18
Great, thanks for the testing.
It seems the problem has been fixed in the recent Lazarus version.
I am closing the issue.
Original comment by j...@cp-lab.com
on 18 Apr 2012 at 11:52
Original issue reported on code.google.com by
snigelma...@gmail.com
on 8 Jan 2012 at 11:02