[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep and valgrind

From: Riccardo Mottola
Subject: Re: GNUstep and valgrind
Date: Wed, 21 Mar 2018 00:37:04 +0100
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2

Hi amon,

amon wrote:
Thanks for all the discussion. Very useful. A few new folks
got involved, so I'll re-iterate that the environment is a
circa 2012 Ubuntu LTS with gcc tool chain on an board intended
for embedded systems which is difficult to upgrade to new
releases and quite brick-able. I may change at some point in
the future when that is feasible but for the moment clang is
out. I went through hell with some issues of installing clang
into some versions of Mint and Ubuntu... there was a serious
compiler issue that I spent a month figuring out and built up
a matrix of OS's. I got it down to a simple test program that
crashed if the system was faulty. Greg can probably tell you
about it. He may remember answering questions as the horror
story developed.

That's one reason why I'm sticking to gcc until our hardware
vendor upgrades to an LTS that is significantly past the
period in which the issue sometimes happened.

Rest assured that you can be perfectly fine with GCC. Enjoy "old style" objective-c and it works.. I never felt the need for Obj-C 2 of which I see an ugly syntax, neither I want ARC or GC, remembering the dark ages when I was a Java programmer! GCC in certain release is a proven compiler, but in other releases it is a mess. For every platform you have the best mix&match.

Of course, Obj-C in GCC would need some care.. sometimes it spits out warnings that are nonsense.. and speed got worse with modern GCCs (but clang is perhaps worse...)

So its a given that for now, I am constrained to gcc.

GNUstep and all the software I work on works on GCC, there are no limits what you can do with it! It is Turing-complete! Of course, if you do old-style memory-handling, you need some extra care, but it will work just fine.

I most probably run GNUstep on systems with less memory than you do.

Generally, GNUstep could need some sort of "slimming down options" but with tests I did with Richard, it does not leak. Or better: there are apps and things that leaks, but it is their fault, gnustep-core is quite decent.

Also, this is not a new program, so I am trying to develop
the least possible change set to fix the storage management
issues... it's about 10,000 lines of operationally tested
code, some of which pre-dates using GNUstep entirely.

It makes life interesting and adds lots of constraints.

Check that they are really "issues". I did check several daemons and apps and with a careful use of ref-count and ARPs, they are not really leaking, although there is some memory waste.
We all like to be memory-savvy, but leaks are a different things.

So again, thank you for the discussion. It has a lot of ideas
percolating in my head as I face the new day of coding. :-)

Of course... look at what I am compiling GNUstep on right now:

NetBSD 7.1 (GENERIC.201703111743Z)
HP9000/715/50 (Scorpio)
real mem = 81920 KB (73728 reserved for PROM, 69768 KB used by NetBSD)
avail mem = 68512 KB
timecounter: Timecounters tick every 10.000 msec
mainbus0 (root) [flex fff80000]
pdc0 at mainbus0
power0 at mainbus0: not available
cpu0 at mainbus0 hpa 0xfffbe000 path 8 irq 31: PA7100 (T-Bird) rev 0
cpu0: PCXT, PA-RISC 1.1b, lev 1, cat A, 50 MHz clk
cpu0: shadows, 64K/64K D/I caches, 120 shared TLB, 16 shared BTLB
cpu0: PCXT (Rolex - CMOS-26B) floating point, rev 1
mem0 at mainbus0 hpa 0xfffbf000 path 9: viper rev 0, ctrl 0x19a10000<lpmc_en> size 80MB

the processor with no stack.. finest for searching memory errors!

Or this:
Mar 20 23:13:34 shadowfax unix: Copyright (c) 1983-2002, Sun Microsystems, Inc.
Mar 20 23:13:34 shadowfax unix: Ethernet address = 8:0:20:93:f3:23
Mar 20 23:13:34 shadowfax unix: mem = 589824K (0x24000000)
Mar 20 23:13:34 shadowfax unix: avail mem = 575381504
Mar 20 23:13:34 shadowfax unix: root nexus = Sun Ultra 1 UPA/SBus (UltraSPARC 167MHz)

the perfect machine to check for invalid struct issues, memory alignment, pointere dereferencing...

PA-RISC and SPARC are among my favourite machines and they uncover so many errors that go undiscovered on intel...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]