Hi Martin,
Thanks for your advice, as you suggest I have added a call to peer_cfg->destroy
straight after ike_sa->set_peer_cfg where the peer_cfg reference is
incremented.
I find that during the release of the peer_cfg there is access to the already
freed child_cfg memory (I see this using Valgrind and DUMA).
This is resolved by incrementing the child_cfg reference count during the
building of the connection:
this->peer_cfg->add_child_cfg(this->peer_cfg, child_cfg);
+ child_cfg->get_ref(child_cfg);
Now I do not see any memory errors, but it would be interesting (at least) to
know why this is necessary.
Regards,
Ian.
On 8 Apr 2010, at 12:34, Martin Willi wrote:
> Hi Ian,
>
>> Currently when the IKE SA is destroyed (ike_sa->destroy) I see that the
>> in the call to DESTROY_IF(this->peer_cfg) that the refcount is 2 (as a
>> result of the call to ike_sa->set_peer_cfg) so does not get deleted at
>> this time and is in fact never released.
>
> ike_sa->set_peer_cfg() takes a reference, so you can destroy() it to
> release the reference as soon as you have passed it to set_peer_cfg().
>
> Alternatively, you can use the control wrapper functionality provided by
> controller_t. The initiate() method automatically consumes a reference
> to the passed config.
>
> Regards
> Martin
_______________________________________________
Dev mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/dev
