You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Alan Conway (JIRA)" <ji...@apache.org> on 2016/01/08 22:55:39 UTC
[jira] [Resolved] (PROTON-829) Possible reference counting bug in
pn_clear_tpwork
[ https://issues.apache.org/jira/browse/PROTON-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway resolved PROTON-829.
--------------------------------
Resolution: Fixed
Fix Version/s: 0.12.0
Verified fixed on current master, transport/connection can be freed in any order. Don't know what commits fixed it.
> Possible reference counting bug in pn_clear_tpwork
> --------------------------------------------------
>
> Key: PROTON-829
> URL: https://issues.apache.org/jira/browse/PROTON-829
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.8
> Reporter: Alan Conway
> Assignee: Alan Conway
> Fix For: 0.12.0
>
>
> See QPID-6415 which describes a core dump in the qpid tests that appears when using the current 0.9 proton master. The qpid tests pass OK with proton 0.8.
> The valgrind output in QPID-6415 shows that a connection is deleted while it is being finalized by a call from pn_connection_unbound to pn_clear_tpwork.
> I do not yet understand the details, but removing the following strange code fixes the problem and passes the proton test suite without valgrind errors:
> {noformat}
> --- a/proton-c/src/engine/engine.c
> +++ b/proton-c/src/engine/engine.c
> @@ -690,10 +690,10 @@ void pn_clear_tpwork(pn_delivery_t *delivery)
> {
> LL_REMOVE(connection, tpwork, delivery);
> delivery->tpwork = false;
> - if (pn_refcount(delivery) > 0) {
> - pn_incref(delivery);
> - pn_decref(delivery);
> - }
> }
> }
> {noformat}
> The code is strange because
> a) you should never examine a refcount except for debugging purposes
> b) under normal refcounting semantics incref+decref is a no-op.
> Is removing this code OK?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)