Petr Machata writes:
> We don't actually see a crash, but an AddressSanitizer citation. As I'm
> now trying to reproduce on vanilla branch-2.5, I actually can't either
> (using the NULL trick). All the rule_delete calls end up being
> scheduled before the backer close. In our code, they come l
Jarno Rajahalme writes:
> diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
> index 83dcc9c..5b42b7e 100644
> --- a/ofproto/ofproto-dpif.c
> +++ b/ofproto/ofproto-dpif.c
> @@ -864,7 +864,7 @@ close_dpif_backer(struct dpif_backer *backer)
> free(backer->type);
> free(backer->d
Jarno Rajahalme writes:
> Btw. I don’t see this problem triggered by the testsuite even if I set the
> ‘ofproto->backer' pointer
> to NULL right after the free() call. Do you see this happening on an
> unmodified OVS 2.5? If so,
> could you send the steps to reproduce. Just need to know if this
Btw. I don’t see this problem triggered by the testsuite even if I set the
‘ofproto->backer' pointer to NULL right after the free() call. Do you see this
happening on an unmodified OVS 2.5? If so, could you send the steps to
reproduce. Just need to know if this is a potential crashing bug in OVS
This may not be the cleanest solution, but how about changing the last line of
close_dpif_backer() in ofproto/ofproto-dpif.c like this:
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 83dcc9c..5b42b7e 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -864,7 +8
Hi,
On 2.5, we are seeing the following problem when removing a bridge:
- ofproto_destroy calls ofproto_flush__, which eventually calls
ovsrcu_postpone(remove_rules_rcu)
- ofproto_destroy also calls p->ofproto_class->destruct, which
eventually leads to release of DPIF backer (close_d
