aMule Forum
English => Multiplatform => Mac OSX => Topic started by: ASTIOBOY on December 04, 2004, 03:33:56 PM
-
Hello, Im'm currently running the latest zip posted in the homepage.
Finally, the GUI is perfectly responsive and does not hang anymore.
It appears the malloc bug is still unfixed, I suspect it's a bug related to
some activity done while connected (transferring, source dropping, dunno...).
It leads amule to increase the amount of Virtual Memory used,
in about 12 hs I have amule occupying 600Mb of Virtual Memory.
Occasionally the application crashes.
Nonetheless the Mac Mule is definitely usable and the best Mac Application for
the edonkey network at the moment.
My greetings to all the developers, specially to Kry.
-
I have also noticed progressive memory leaking from Mac aMule. In addition to top and Activity Monitor indicating a large memory footprint for the process, aMule will thrash for a couple of minutes (showing the spinning beachball cursor) if I try to open the preferences or file details dialog. It doesn't have such problems immediately after launch, only after it's been running for hours. Running sample on aMule while it's thrashing shows lots of memory allocation and deallocation calls on the stack.
I have made some half-assed attempts to identify the source of the leaks, but don't have any definitive information. One can use the leaks command (see "man leaks" for info) to scan an application's memory space for allocated blocks that are no longer referenced anywhere. This is a bit like the first half of a garbage collection routine. After aMule has run for some hours, the report is very, very long with many small allocations having been leaked. If memory serves, I have seen leaks amounting to as much as 70 megabytes in hundreds of thousands of allocations.
The leaks command can report stack traces for the leaked allocations if you run aMule with the environment variable MallocStackLogging set to 1. I have never managed to get such a report because I always forgotten some simple step in the process. (I can be stupid, sometimes.) You want to use a build of aMule that hasn't been stripped of its symbols. You have to let aMule run for a while, but you can't let it run for too long or the stack logging will fill memory and it will crash. I think the leaks are related to GUI events, so you want to be active in the GUI while running the test. I keep meaning to go back and try again.
The leaks report can contain a snippet from the allocated block, especially if it recognizes the type (string, OS primitive, etc.). Often these snippets contain text which I recognize as four-character-codes used by the Mac OS to tag certain kinds of data structures like event records, window records, GUI controls, etc. Some other leaks show their type directly as CFSocket objects and the like. I'm pretty sure wxMac is failing to release or dispose of OS-supplied data structures after it's done with them.
As mentioned in the leaks man page, there is also /Developer/Applications/Performance Tools/MallocDebug.app which performs a similar function in a GUI app. Annoyingly, each program can miss leaks that the other will catch. MallocDebug can attach to an app which was launched with MallocStackLogging set, or it can directly launch an application itself.
-
This is crash data.
I will try to update to latest wxMac / aMule cvs
(though compiling is always a painful thing!).
Host Name:
Date/Time: 2004-12-05 22:40:43 +0100
OS Version: 10.3.6 (Build 7R28)
Report Version: 2
Command: amule
Path: /Applications/aMule.app/Contents/MacOS/amule
Version: 0.1 (2.0.0)
PID: 2659
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
Thread 0 Crashed:
0 <<00000000>> 0xffff8998 __memcpy + 0x1f8
1 com.amule 0x000ea008 Packet::DetachPacket() + 0xb0
2 com.amule 0x0001206c CEMSocket::SendPacket(Packet*, bool, bool) + 0x128
3 com.amule 0x0015d928 CUpDownClient::SendBlockData(float) + 0x60c
4 com.amule 0x001653dc CUploadQueue::Process() + 0x1c8
5 com.amule 0x0016f6b4 CamuleApp::OnCoreTimer(wxTimerEvent&) + 0x4c
6 libwx_base_carbon-2.5.3.dylib 0x01425d40 wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) + 0x9c
7 libwx_base_carbon-2.5.3.dylib 0x014254dc wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) + 0xa0
8 libwx_base_carbon-2.5.3.dylib 0x01425eec wxEvtHandler::ProcessEvent(wxEvent&) + 0xcc
9 libwx_mac_core-2.5.3.dylib 0x0179edec wxTimerBase::Notify() + 0x88
10 com.apple.CoreFoundation 0x90194620 __CFRunLoopDoTimer + 0xf4
11 com.apple.CoreFoundation 0x90191980 __CFRunLoopRun + 0x5c8
12 com.apple.CoreFoundation 0x90195e94 CFRunLoopRunSpecific + 0x148
13 com.apple.HIToolbox 0x927d5f88 RunCurrentEventLoopInMode + 0xac
14 com.apple.HIToolbox 0x927dc6f0 ReceiveNextEventCommon + 0x17c
15 com.apple.HIToolbox 0x9284d7fc ReceiveNextEventInMode + 0x48
16 libwx_mac_core-2.5.3.dylib 0x016db854 wxApp::MacDoOneEvent() + 0x4c
17 libwx_mac_core-2.5.3.dylib 0x016db4e8 wxApp::MainLoop() + 0x24
18 libwx_base_carbon-2.5.3.dylib 0x013ee6c0 wxEntry(int&, char**) + 0x60
19 com.amule 0x0017100c main + 0x18
20 com.amule 0x00001fa4 _start + 0x188 (crt.c:267)
21 com.amule 0x00001e18 start + 0x30
-
ken did a patch for some memleaks in wxMac and they got commited into official cvs. so make sure you get the _very latest_ cvs of wxMac so that those memleaks don't appear to you anymore :)
Greetings!