Hi Florian, Just following up.. Did you create a patch and/or bug report for this?
Robert On Wed, 18 Oct 2017 22:41:04 -0400 Robert wrote: RS> On Fri, 22 Sep 2017 08:33:42 +0200 Florian wrote: RS> FF> I noticed that snmp_sess_synch_response() *sometimes* (not RS> FF> always) frees the "netsnmp_pdu *pdu" argument passed to it RS> FF> when returning STAT_ERROR. For example: RS> FF> RS> FF> snmp_sess_session() == NULL -> pdu is not freed RS> FF> snmp_sess_send() == 0 -> pdu is freed RS> FF> RS> FF> The caller therefore has to chose between risk leaking RS> FF> memory and risk a double-free. I assume that given these RS> FF> choices, users opt for the inconvenient leak over a double RS> FF> free. RS> FF> RS> FF> Would you accept a patch that make the behavior RS> FF> deterministic (from the POV of the caller)? I see the RS> FF> following options: RS> FF> RS> FF> * If the return value is STAT_ERROR, *always* free the "pdu" RS> FF> argument. This is likely the less intrusive change, since RS> FF> callers must already assume that this is what happens. RS> FF> -- OR -- RS> FF> * Introduce a new error code. The callers already expect RS> FF> that the argument has been freed when they get a RS> FF> STAT_ERROR, so returning SNMPERR_GENERR in cases where pdu RS> FF> is *not* freed might be a reasonable way forward. RS> RS> I think the first option seems best. RS> RS> Robert
pgpodiFxnBst7.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
