[
https://issues.apache.org/jira/browse/RAMPARTC-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022623#comment-13022623
]
David Sanders commented on RAMPARTC-153:
----------------------------------------
I'm not sure if this is the best solution. Eucalyptus System has this line
added to the patched version of Rampart that they use, and when playing with it
earlier, I ended up getting segmentation faults due to this line.
As far as I can tell, the segmentation faults were coming from the fact that
Rampart creates the context in the in handler, then tries to store it for reuse
in the out handler. I'm not positive of the benefits of this, but thats what I
could see in the code. The problem I ran into was when the out handler read
back out the rampart_context, and then went to use a certificate from it to
sign a response, there was a segmentation fault when accessing
rampart_context->key_mgr.
This segmentation fault doesn't occur all the time, otherwise Eucalyptus would
always have segfaults. I'm not sure what brought out the issue in my case, but
its worth noting before applying this patch.
> [PATCH] Memory leak in in_handler
> ---------------------------------
>
> Key: RAMPARTC-153
> URL: https://issues.apache.org/jira/browse/RAMPARTC-153
> Project: Rampart/C
> Issue Type: Bug
> Components: Rampart-core
> Affects Versions: 1.3.0
> Environment: Linux (all distributions)
> Reporter: Garrett Holmstrom
> Assignee: Malinda Kaushalye Kapuruge
> Labels: patch
> Attachments: rampart-trunk-memleak.patch
>
>
> The rampart_in_handler_invoke function leaks memory every time it succeeds
> because it fails to free rampart_context before returning. The attached
> patch makes it call rampart_context_free before returning.
> Ubuntu has been carrying a patch for this for some time, so it would be nice
> to get it upstream if possible.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
