You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "zhangyb (JIRA)" <ji...@apache.org> on 2014/04/08 09:49:15 UTC
[jira] [Comment Edited] (QPID-2631) Race in qpid::client::Bounds
causes (rare) deadlock
[ https://issues.apache.org/jira/browse/QPID-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962676#comment-13962676 ]
zhangyb edited comment on QPID-2631 at 4/8/14 7:47 AM:
-------------------------------------------------------
This bug seems to have been fixed in the o.8 version through the status of the problem.But I still found the bug in the 0.14,why?
#0 0x0000003d55e0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f4610584675 in wait (this=0x1e8a5f0, sizeRequired=1080, block=<value optimized out>)
at ../include/qpid/sys/posix/Condition.h:63
#2 wait (this=0x1e8a5f0, sizeRequired=1080, block=<value optimized out>) at ../include/qpid/sys/Monitor.h:41
#3 wait (this=0x1e8a5f0, sizeRequired=1080, block=<value optimized out>) at ./qpid/sys/Waitable.h:91
#4 qpid::client::Bounds::expand (this=0x1e8a5f0, sizeRequired=1080, block=<value optimized out>) at qpid/client/Bounds.cpp:39
#5 0x00007f46105b05a0 in qpid::client::SessionImpl::sendFrame (this=0x1ec6e60, frame=..., canBlock=true)
at qpid/client/SessionImpl.cpp:514
#6 0x00007f46105b23b7 in qpid::client::SessionImpl::sendContent (this=0x1ec6e60, content=...) at qpid/client/SessionImpl.cpp:429
#7 0x00007f46105b4641 in qpid::client::SessionImpl::sendCommand (this=0x1ec6e60, command=..., content=0x7f45c4031c90)
at qpid/client/SessionImpl.cpp:399
#8 0x00007f46105b4839 in qpid::client::SessionImpl::send (this=<value optimized out>, command=<value optimized out>,
content=<value optimized out>) at qpid/client/SessionImpl.cpp:307
#9 0x00007f4610576d3d in qpid::client::no_keyword::AsyncSession_0_10::messageTransfer (this=0x1ec7da8,
destination=<value optimized out>, acceptMode=<value optimized out>, acquireMode=<value optimized out>, content=...,
sync=false) at ./qpid/client/no_keyword/AsyncSession_0_10.cpp:63
was (Author: zhangyb):
This bug seems to have been fixed in the o.8 version through the status of the problem.But I still found the bug in the 0.14:
#0 0x0000003d55e0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f4610584675 in wait (this=0x1e8a5f0, sizeRequired=1080, block=<value optimized out>)
at ../include/qpid/sys/posix/Condition.h:63
#2 wait (this=0x1e8a5f0, sizeRequired=1080, block=<value optimized out>) at ../include/qpid/sys/Monitor.h:41
#3 wait (this=0x1e8a5f0, sizeRequired=1080, block=<value optimized out>) at ./qpid/sys/Waitable.h:91
#4 qpid::client::Bounds::expand (this=0x1e8a5f0, sizeRequired=1080, block=<value optimized out>) at qpid/client/Bounds.cpp:39
#5 0x00007f46105b05a0 in qpid::client::SessionImpl::sendFrame (this=0x1ec6e60, frame=..., canBlock=true)
at qpid/client/SessionImpl.cpp:514
#6 0x00007f46105b23b7 in qpid::client::SessionImpl::sendContent (this=0x1ec6e60, content=...) at qpid/client/SessionImpl.cpp:429
#7 0x00007f46105b4641 in qpid::client::SessionImpl::sendCommand (this=0x1ec6e60, command=..., content=0x7f45c4031c90)
at qpid/client/SessionImpl.cpp:399
#8 0x00007f46105b4839 in qpid::client::SessionImpl::send (this=<value optimized out>, command=<value optimized out>,
content=<value optimized out>) at qpid/client/SessionImpl.cpp:307
#9 0x00007f4610576d3d in qpid::client::no_keyword::AsyncSession_0_10::messageTransfer (this=0x1ec7da8,
destination=<value optimized out>, acceptMode=<value optimized out>, acquireMode=<value optimized out>, content=...,
sync=false) at ./qpid/client/no_keyword/AsyncSession_0_10.cpp:63
> 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org