Shakespeer
Shakespeer copied to clipboard
rufuscoder
Memory Leaks
Original author: [email protected] (July 21, 2008 09:11:15)
I do not do anything special, just download and upload files. Shakespeer uses more and more memory. My last time it used 450Mb of RSize.
Original issue: http://code.google.com/p/shakespeer/issues/detail?id=49
From [email protected] on August 11, 2008 21:29:10 We should definitely run ShakesPeer through some instruments looking for leaks, and also try to reduce the memory usage a bit.
From [email protected] on October 04, 2008 08:45:42 Same problem here. I think it has something to do with the time you set the rehashing to ... It does have a memory leak, and it chews up the entire memory if you leave it over the night with couple of uploads and downloads. I've changed the timeout for rehashing to 5 hours ...and I think it kinda "solved" the problem. Not sure because there wasn't any traffic that night, nor upload nor download.
From [email protected] on October 04, 2008 09:31:53 Yep, think so too. Couse it uses near 300Mb RSZIME right after program loading....
From [email protected] on October 04, 2008 10:28:52 Any volunteers to run Shakespeer through MallocDebug or some other method to find out more specifically what it is that grows in memory?
From [email protected] on October 04, 2008 10:32:12 If you give me instruction how to run throught MallocDebug on OS X I will do it.
From [email protected] on October 04, 2008 10:41:49 I can't start ShakesPeer throught MallocDebug, because it crash:
Process: sphubd [10814] Path: /Applications/ShakesPeer.app/Contents/Resources/sphubd Identifier: sphubd Version: ??? (???) Code Type: X86 (Native) Parent Process: launchd [1]
Date/Time: 2008-10-04 14:41:01.908 +0400 OS Version: Mac OS X 10.5.5 (9F33) Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000005555555d Crashed Thread: 0
Thread 0 Crashed: 0 sphubd 0x000200d5 share_scan_event + 1013 1 sphubd 0x00058b6a event_process_active + 282 2 sphubd 0x00058e33 event_base_loop + 407 3 sphubd 0x00058c96 event_loop + 36 4 sphubd 0x00058bac event_dispatch + 18 5 sphubd 0x000155d6 main + 1878 6 sphubd 0x00002062 _start + 216 7 sphubd 0x00001f89 start + 41
Thread 0 crashed with X86 Thread State (32-bit): eax: 0x55555555 ebx: 0x0001fcf4 ecx: 0x00000000 edx: 0x00000000 edi: 0xbffff928 esi: 0x006ab130 ebp: 0xbffff778 esp: 0xbffff680 ss: 0x0000001f efl: 0x00010246 eip: 0x000200d5 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x5555555d
Binary Images:
0x1000 - 0x95fe7 +sphubd ??? (???)
From [email protected] on October 04, 2008 10:45:58 I have tried to start ShakesPeer without sphubd (it work in background) and got another crash
From [email protected] on February 03, 2009 18:12:04 Just an observation of the memory behavior: Left SP running last nite and this morning it was chewing on 700+ MB but as I started using my computer (it was struggling for a while) things started running smoother. One hour later SP is down to a manageable 350MB and still slowly decreasing. So at least I didn't need a relaunch and lose my download queue. 350 is still a lot of memory, but at least it forked over some for me. =]
From [email protected] on March 28, 2009 01:53:59 I ran it through leaks on my system, and found two (apparently different) problems. I'm attaching a patch that fixes one of them, and the log from leaks for the other in case anyone wants to try to track that down.
While troubleshooting this, I came across what seemed like a pointless instance variable (root) in SPFilelistController. It is assigned to, used, and freed in the init method, and then never referenced again. issue49_2.diff makes this a variable in init, and not an ivar. I made it a separate patch because it isn't really related to this issue, and not really anything more than a style concern.
Comments?
From [email protected] on March 28, 2009 13:28:28 Fixed in r482. Thanks for the patch! I'll leave this issue open until the other identified leak has been followed up by someone.
From [email protected] on March 28, 2009 23:42:50 It's unrelated to the one I posted about earlier, but the attached patch fixes a leak in SPSearchWindowController.
From [email protected] on September 27, 2009 10:24:21 I have noticed that when downloading a large file list from someone, at the point where the download completes and the list is displayed, memory use increases at a ridiculous rate.
Watching through activity monitor, memory use went from ~20MB to 2.09GB when opening a file list of someone sharing ~5TB.
From [email protected] on September 27, 2009 10:42:02 I am thinking that maybe we should push out a 0.9.12 release with these fixes, even though nothing else has changed much. It seems to be kind of critical for some users.
From [email protected] on September 27, 2009 11:16:38 I don't think downloading a large file list is related to the fix from r483 though, which only deals with search results.
IIRC, the file list handling in SPFileListController.m (and filelist.c) looks quite heavy. It could be that there are leaks, or it could be that it's just using a lot of memory for huge huge filelists (which wouldn't be all that surprising). It's hard to say without further investigation.
From [email protected] on September 12, 2011 21:49:07 So, here we are to years since the last post. Any progress? I'm one of the larger shares on my campus' hub right now; all I do is upload. When I open Shakespeer, the inactive memory in Activity Monitor climbs until there is only ~30MB free. After quiting, it returns to normal. I just upgraded my RAM today from 4GB to 8GB, but all it does is delay the issue.
From [email protected] on February 11, 2012 13:05:56 Yes, I am also facing the same issue. After half hour, memory usage increases to 1-2 GB. Please help me with this.
This file ShakePeer Leaks.txt contains all leaks. Definitely, the issue is the process sphashd where are repeating two leaks:
Leak: 0x2d31890 size=16 zone: DefaultMallocZone_0x1bf000 length: 5 "16779"
Leak: 0x2d31950 size=16 zone: DefaultMallocZone_0x1bf000 length: 5 "56539"
Leak: 0x2d31dd0 size=16 zone: DefaultMallocZone_0x1bf000 length: 5 "56539"
and
Leak: 0x68e400 size=256 zone: DefaultMallocZone_0x1bf000 length: 107 "GET /~mhe/ip.shtml HTTP/1.1
Connection: close
Host: www.stacken.kth.se
User-Agent: shakespeer/0.9.11
"
