[
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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
