Re: [Nmh-workers] GCC 8 pre-releases have escaped...

[Bakul Shah]

On Sat, 10 Feb 2018 17:05:37 +0000 Ralph Corderoy <address@hidden> 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.