On Sat, Mar 10, 2018 at 6:08 PM, amon wrote:
>
> Just to re-iterate... most of those tools are of little help.
> I am doing embedded systems that will run for long periods of
> time and may have life-safety implications. The small boxes
> are ARM based linux boxes. No GUI. All work is via an xterm
Just to re-iterate... most of those tools are of little help.
I am doing embedded systems that will run for long periods of
time and may have life-safety implications. The small boxes
are ARM based linux boxes. No GUI. All work is via an xterm
over an ssh with the target host running one or more O
On Fri, Mar 9, 2018, 17:25 amon wrote:
> It may be the case that the malloc scene is confused and lacks
> standards, but the ability to debug leaks with a simple test
> like this has been a long standing and very serious problem
> with Objective C, to
Apple has nice tools to debug ObjC leaks.
> On 9 Mar 2018, at 17:08, amon wrote:
>
> It may be the case that the malloc scene is confused and lacks
> standards, but the ability to debug leaks with a simple test
> like this has been a long standing and very serious problem
> with Objective C, to the point that I have my doubts there is
It may be the case that the malloc scene is confused and lacks
standards, but the ability to debug leaks with a simple test
like this has been a long standing and very serious problem
with Objective C, to the point that I have my doubts there is
any significant size program written in the language
On 8 Mar 2018, at 17:57, amon wrote:
>
> Based on the hint, I found that the current malloc has gained
> some tools that were not there the last time I had to do this,
> and in fact it looks like mallinfo(3) might even be the base
> upon which NSZoneStats() was built. So I might be able to whip
>
I wrote it and got it working this afternoon. If anyone wants
to take a look and perhaps give me some feedback, I have
attached the source.
The format is likely quite different than what you are used to,
but this is our house style.
You probably will have to tweak a path or two since it will not
No, not graphical. This is for down in the nitty gritty debug
level on machines which do not even have a screen.
Based on the hint, I found that the current malloc has gained
some tools that were not there the last time I had to do this,
and in fact it looks like mallinfo(3) might even be the bas
If this is for a graphical application I can recommend the MemoryPanel
(https://github.com/gnustep/libs-gui/blob/master/Source/GSMemoryPanel.m) that
is build into all GNUstep applications. Just open the about panel and click on
the GNUstep icon to open this hidden feature.
This code uses GSDebu
What I want it to run an object in a test harness, say 1000
times, and meter the storage usage each time through so I can
see if there are cases in which objects are leaking storage.
--
+---+
| Dale Amon Immortal Data
FYI, the targets for my code tend to be very small ARM units.
Working mostly with the Mirabox at the moment.
--
+---+
| Dale Amon Immortal Data|
| CEO Midland International Air and Spa
No Mac issues. I only work with Linux, partly *because* of the
way Apple tries to hide things.
So if I read between the lines, would you be saying that the
default zone can be analyzed via malloc and the NSZoneStats()
would work for any other NSZone's?
--
+---
On 8 Mar 2018, at 16:15, amon wrote:
>
> I am trying to get a handle on storage leaks and NSZoneStat()
> would be ideal... except it doesn't work.
The default malloc zone just calls malloc, so you can get the statistics from
your underlying malloc implementation. Most mallocs come with various
> On 8 Mar 2018, at 16:15, amon wrote:
>
> I am trying to get a handle on storage leaks and NSZoneStat()
> would be ideal... except it doesn't work.
>
> NSZone *dftzone = NSDefaultMallocZone();
> NSZone *curzone = NSZoneFromPointer ( (void *) arglist);
> printf ("dft = %lx cur = %lx\n",
>
What you're doing won't work, as far as I can tell.
Header:
/** Deprecated ...
* Obtain statistics about the zone. Implementation emphasis is on
* correctness, not speed. Not defined by OpenStep or OS X.
*/
struct NSZoneStats
NSZoneStats (NSZone *zone);
Implementation:
static struct NSZo
Did you test this on Mac OS X? What results are returned there?
On Thu, Mar 8, 2018 at 11:14 amon wrote:
> I am trying to get a handle on storage leaks and NSZoneStat()
> would be ideal... except it doesn't work.
>
>NSZone *dftzone = NSDefaultMallocZone();
>NSZone *curzone = NSZoneFromP
16 matches
Mail list logo
