Hi Bakul,
I see there are mts/libmta.a and sbr/libmh.a libraries. Corresponding
.c files add up to about 29K lines. uip/*.c is another 44K lines.
That is a lot of code for manual analysis.
A lot of it is duplicate dribble pasted over the decades and it could
probably be halved in size. Along the way, I'm sure many bugs, lack of
error checking, and inconsistencies would be found, and fixed.
And valgrind or gc will only point out those leaks they encounter
during a run
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.
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.
$ inst() { perf stat -e instructions "$@" |&
> awk '/instructions:u/ {print $1}' | tr -d ,; }
$
$ 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.
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.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers