> On Jan 6, 2016, at 1:21 PM, Ben Pfaff wrote:
>
> On Wed, Jan 06, 2016 at 01:14:23PM -0800, Jarno Rajahalme wrote:
>>
>>> On Jan 5, 2016, at 8:24 PM, Ben Pfaff wrote:
>>>
>>> Thanks. That was my experience also.
>>>
>>> I applied this to master and branch-2.5.
On Wed, Jan 06, 2016 at 01:14:23PM -0800, Jarno Rajahalme wrote:
>
> > On Jan 5, 2016, at 8:24 PM, Ben Pfaff wrote:
> >
> > Thanks. That was my experience also.
> >
> > I applied this to master and branch-2.5.
>
> Thanks for fixing this. I reviewed the patch and it seems
> On Jan 5, 2016, at 8:24 PM, Ben Pfaff wrote:
>
> Thanks. That was my experience also.
>
> I applied this to master and branch-2.5.
Thanks for fixing this. I reviewed the patch and it seems correct to me as well.
> I think that branch-2.4 has
> the same bug but the backport
Hi Ben,
These two tests generate the leak:
mpls_xlate
381: MPLS xlate action
ofproto-dpif
852: ofproto-dpif - MPLS handling
==65139==by 0x4E1C83: xmemdup (util.c:134)
==65139==by 0x431044: recirc_state_clone (ofproto-dpif-rid.c:221)
==65139==by 0x431044: recirc_alloc_id__
Looking at the recirculation code in ofproto-dpif-rid.c, I see code to
copy the stack and the actions from one recirc_state to another in
recirc_state_clone(), but I can't find any code that ever frees them.
recirc_run(), for example, just does a plain (postponed) "free" of the
recirc_id_node
I think that recirc_run needs to be modified so that
On Tue, Jan 05, 2016 at 06:40:23PM +, ChengChun Tu wrote:
> Hi Ben,
>
> Yes, Valgrind testcase 381 reports leak and generates the call stack below:
> I tried to debug it for a while but not able to understand it.
Thanks, what's the name
Hi Ben,
Yes, Valgrind testcase 381 reports leak and generates the call stack below:
I tried to debug it for a while but not able to understand it.
fun:malloc
fun:xmalloc
fun:ofpbuf_new
fun:ofpbuf_new_with_headroom
fun:ofpbuf_clone_data_with_headroom
fun:ofpbuf_clone_with_headroom
Thanks. That was my experience also.
I applied this to master and branch-2.5. I think that branch-2.4 has
the same bug but the backport is not trivial and I do not know whether
it is worthwhile.
On Tue, Jan 05, 2016 at 05:22:24PM -0800, William Tu wrote:
> Hi Ben,
>
> The patch works OK. It
Thanks. Would you mind testing this proposed fix?
http://openvswitch.org/pipermail/dev/2016-January/064070.html
On Tue, Jan 05, 2016 at 11:32:48AM -0800, William Tu wrote:
> Hi Ben,
>
> These two tests generate the leak:
> mpls_xlate
> 381: MPLS xlate action
> ofproto-dpif
>
Hi Ben,
Sure, I will test this fix.
Regards,
William
On Tue, Jan 5, 2016 at 4:55 PM, Ben Pfaff wrote:
> Thanks. Would you mind testing this proposed fix?
> http://openvswitch.org/pipermail/dev/2016-January/064070.html
>
> On Tue, Jan 05, 2016 at 11:32:48AM -0800,
Hi Ben,
The patch works OK. It passes "make check" and "make check-valgrind"
without reporting memory leaks.
Thank you
William
On Tue, Jan 5, 2016 at 5:02 PM, William Tu wrote:
> Hi Ben,
>
> Sure, I will test this fix.
>
> Regards,
> William
>
> On Tue, Jan 5, 2016 at 4:55
11 matches
Mail list logo