[Swan-dev] leaks and cores

[Andrew Cagney]

Another update: https://testing.libreswan.org/v4.1-500-g08ffea331c-main/
only the following LEAKs remain (there really should be zero leaks):

- intermediate exchange: ikev2-intermediate-02-psk
ikev2-intermediate-01-rsa-sha1

+Jan 19 01:10:47.275481: leak-detective enabled
+Jan 19 01:10:56.329908: leak: IntAuth_*_I, item size: 64
+Jan 19 01:10:56.330122: leak: IntAuth_*_I, item size: 64
+Jan 19 01:10:56.330192: leak: 2 * IntAuth, item size: 64
+Jan 19 01:10:56.330345: leak detective found 6 leaks, total size 448

Perhaps addressing
https://lists.libreswan.org/pipermail/swan-dev/2020-October/004060.html
will make this go away.

- start-stop: algparse-02-fips

+leak-detective enabled
+leak: heap logger, item size: 64
+leak: heap logger prefix, item size: 1
+leak detective found 2 leaks, total size 65

Pluto has been told to stop while addconn is still running (for
instance when addconn hangs), which is something that should be
handled cleanly. Ulgh.

Once all these leaks are gone, I can add running refcnt.awk to the
post mortem - unlike the leak code, it can detect Pluto leaking NSS
objects.



On Tue, 17 Nov 2020 at 17:16, Andrew Cagney <andrew.cagney at gmail.com> wrote:
>
> FYI,
>
> On Mon, 16 Nov 2020 at 09:38, Andrew Cagney <andrew.cagney at gmail.com> wrote:
> >
> > https://testing.libreswan.org/v4.1-178-gf93f336eb1-main
> >
> >       4 IntAuth_*_I
> >       4 IntAuth
>
> These are from intermediate exchange.
>
> >       2 heap logger prefix
> >       2 heap logger
>
> these are from algparse-02-fips where pluto is shutdown before it has
> finished started up (addconn hadn't finished).
>
> >       1 host pair
>
> this, I suspect, is from adding and deleting interfaces
>
> >       1 ikev2_outI1 KE
> >       1 dh
> >
> > and individual tests:
> >
> > algparse-02-fips heap logger
> > algparse-02-fips heap logger prefix
> > dynamic-iface-01 host pair
> > ikev2-43-init-retransmit heap logger
> > ikev2-43-init-retransmit heap logger prefix
> > ikev2-43-init-retransmit ikev2_outI1 KE
> > ikev2-43-init-retransmit dh
> > ikev2-intermediate-01-rsa-sha1 IntAuth
> > ikev2-intermediate-01-rsa-sha1 IntAuth
> > ikev2-intermediate-02-psk IntAuth_*_I
> > ikev2-intermediate-02-psk IntAuth_*_I
> > ikev2-intermediate-02-psk IntAuth
> > ikev2-intermediate-02-psk IntAuth_*_I
> > ikev2-intermediate-02-psk IntAuth_*_I
> > ikev2-intermediate-02-psk IntAuth
> >
> > On Fri, 30 Oct 2020 at 09:12, Andrew Cagney <andrew.cagney at gmail.com> wrote:
> > >
> > > This is an updated list I extracted from
> > > https://testing.libreswan.org/v4.1-92-g55b1068bc1-main/
> > >      42 %s/%s
> > >      17 orphan shunt
> > >      12 bare shunt
> > >       4 IntAuth_*_I_A | IntAuth_*_R
> > >       4 IntAuth_*_I
> > >       4 2 * IntAuth
> > >       2 responder salt
> > >       2 initiator salt
> > >       2 DH secret
> > >       2 host pair
> > >
> > > On Wed, 28 Oct 2020 at 07:59, Andrew Cagney <andrew.cagney at gmail.com> wrote:
> > > >
> > > > (in case you missed the commits)
> > > > The changes to, at the end of every test and regardless of final.sh,
> > > > shutdown pluto then check for leaks and cores have been pushed to
> > > > https://testing.libreswan.org/
> > > > I've also pushed a few memory-leak fixes (one in IKEv1's aggressive
> > > > initiator code seems to go back to at least '07).  While this makes
> > > > some of the contents of final.sh redundant, I'll leave it for the
> > > > moment.
> > > >
> > > > Below are the leaks from a fairly recent test run.   I've trimmed out
> > > > the ones that are likely caused by crypto material being stuck in the
> > > > limbo between helper and main threads (fix pending tm).
> > > > This leaves what to me at least, are potential leaks on the error path:
> > > >
> > > > bare shunt
> > > > host_pair
> > > > IKEv2 fragments buffer
> > > > ikev2_inI1outR1 KE
> > > > initiator salt
> > > > IntAuth
> > > > IntAuth_*_I
> > > > issuer ca
> > > > libevent_malloc
> > > > logger
> > > > message buffer in read_packet()
> > > > orphan shunt
> > > > quick outR1 DH
> > > > read_message
> > > > responder decoding certificates
> > > > responder salt
> > > > %s/%s
> > > > virtual description
> > > > xfrmi name