[
https://issues.apache.org/jira/browse/QPID-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962766#comment-13962766
]
Gordon Sim commented on QPID-2631:
----------------------------------
The bug as described is quite narrow and specific and was fixed by
http://svn.apache.org/viewvc?view=revision&revision=948936. The backtrace above
doesn't imply the same issue. It is to some degree expected that clients may
block at this point (while waiting for existing data to be written to the
socket). However they should not block indefinitely. If you believe you are
getting into an erroneous state, i.e. a wait that never clears, please raise a
new bug and/or describe in more detail what you observe.
> Race in qpid::client::Bounds causes (rare) deadlock
> ---------------------------------------------------
>
> Key: QPID-2631
> URL: https://issues.apache.org/jira/browse/QPID-2631
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.5, 0.6
> Reporter: Gordon Sim
> Assignee: Gordon Sim
> Fix For: 0.7
>
>
> There is a race condition in the use of Bounds in SessionImpl::sendFrame.
> This function sends the frame first, then calls
> Bounds::expand(). But it's possible the network thread calls Bounds::reduce()
> between sending the frame and calling expand. If the Bounds::current value is > 0
> that reduce() is lost. If enough reduce() calls are lost in this way
> eventually we will deadlock.
> In investigating this it also became clear that the connection frames weren't
> correctly accounted for (i.e. the bounds are never expended for connection
> frames, though they are included in the byte count passed in on reduce()).
> Though this shouldn't actually cause any problem it is logically incorrect,
> unintuitive and could mask problems that are hard to diagnose.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
