On Sat, 10 Feb 2018 17:05:37 +0000 Ralph Corderoy <ralph@inputplus.co.uk> wrote:
Ralph Corderoy writes:
True, but there are static analysis programs that point out leaks. I
did run one on nmh a while ago and it found lots, but they weren't worth
fixing because the code has a myriad of policies over caller v. callee,
and lacks standard routines to help in the common case. I thought
effort would be better spent getting those in place.
Refactoring, code cleanup and fixing memory leaks are worthy goals.
But that can take lots of time and volunteers.
This is why I think it makes sense to a) just use boehm gc
I built nmh git here with gc 7.6.0-1 by `cheating' with Makefile.
AM_CFLAGS = -Dmalloc=GC_malloc -Dfree=GC_free -Drealloc=GC_realloc
AM_LDFLAGS = -lgc
It works! Well, simpler programs work. scan(1) SEGVs, ditto folder(1).
But I could play around a bit, comparing it to the installed nmh-git
1.7+dev.r4298-1 in /bin.
This is promising! Segfaults likely point to genuine bugs.
$ inst() { perf stat -e instructions "$@" |&
> awk '/instructions:u/ {print $1}' | tr -d ,; }
Presumably this counts actual instructions executed? linux documentation....
$
$ for n in {1..10}; do inst /bin/mhparam version; done | stats
length min 25%ile median mean 75%ile max stddev
10 517769 517772 517786 517787 517789 517820 16.98117
$ for n in {1..10}; do inst uip/mhparam version; done | stats
length min 25%ile median mean 75%ile max stddev
10 1123982 1198254 1267038 1248003 1308074 1333808 71002.18
$
$ for n in {1..10}; do inst /bin/mhpath; done | stats
length min 25%ile median mean 75%ile max stddev
10 523751 523752 523768 523765 523769 523797 13.4447
$ for n in {1..10}; do inst uip/mhpath; done | stats
length min 25%ile median mean 75%ile max stddev
10 1213542 1277482 1306410 1314250 1333958 1469626 71638.04
That might not be very fair on gc, perhaps it has a constantish overhead
that would be less as a percentage on a longer-running `scan last:42',
but the population stddev does show how it varies a lot. One of the
nice things when trying to measure improvements now is the instruction
count's consistency.
This is fine in my opinion. GC doesn't come for free.
I see http://www.hboehm.info/gc/gcinterface.html has a GC_MALLOC_ATOMIC
where the caller can state the memory won't need scanning for pointers.
That's useful, and would help, though I guess it can be a new source of
leaks if a struct definition changes over time to have a pointer.
This can be added as needed. Personally I'd be ok with some
slowdown if gc can remove a class of problems. This remains to
be proven though. Besides, your goals may be different.
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers