I know we could do RTFM here, but but what are the functions (REAL/Xojo or MBS or Declares) where I can get the 4 memory listings that are in the Activity Monitor in OSX?
Free
Wired
Active
Inactive
[Used]
I did do some looking and is getrusage() part of this whole equation?
[code] dim theDarwin as DarwinVMStatisticsMBS = GetDarwinVMStatisticsMBS
if theDarwin = nil then Return
dim theTaskInfo as new DarwinTaskInfoMBS
if theTaskInfo = nil then Return
dim thePageSize as Double = theDarwin.Pagesize // make a double to avoid integer overflow problems
Thanks Eli and Beatrix; Beatrix, I’ll use this. I have a memory leak in my C++ dylib I’m trying to track, I like going to REAL/Xojo to use certain functions and this seems easier.
I’ve always found it strange that even given 32Gb of memory, it’s easy to “run out” with plenty of RAM to spare. Memory allocation in OS’s certainly isn’t perfect, though I’m sure it’s great for most uses.
Thanks, I think though the client is running 10.9 or 10.10 so it’s 64-bit only. But are you speaking of the REAL/Xojo app? I am. Then it’s running 32-bit which means it only accesses 4GB. Right?
So given that, whats a proper way to interpret the Activity Monitor settings? Just subtract 28GB from the Free totals?
So given that sort of changes my question; Norman, how would you monitor this sort of thing? (Basically at a certain point time after processing many files a memory allocation new() in my C++ dylib fails. I now this isn’t a Xojo-specific quesiton but it is the Xojo app running this dylib and I can use Xojo or Xojo-accessible functions to get this info.
Xojo doesn’t monitor your dylib and its memory usage - I’m not sure it even can
I could very well be wrong on that though
top can monitor your app rather than every process if you invoke it with top -pid and the process id of your running app
you can get the pid usually using the pid command - I think that will work in a shell
or you could declare into the std c library as there is a call there to get the current process pid
or you could use the same top command shown but combine a grep for the specific process name
but you DO want to monitor the PROCESS not the MACHINE since a 32 bit process (a Xojo app) IS limited to 4Gb total
the LEAKS command might be of use tracking this down
Process space yes
But if the dylib isn’t a plugin things like runtime object count etc are’t part of that
A malloc in a dylib isn’t something the runtime can track - its outside the scope of what the runtime knows about
Maybe Apple’s instruments can help you find the bug too. Of course they do not integrate with the Xojo debugger but finding the API method name that caused a leak is often valuable help.
And a late reply on:
Activity monitor gives you the memory usage of each running process, so no need to subtract anything as long as you’re running a 32bit app. The limit on such is indeed 4GB of application RAM.