On 10/29/18 11:11 AM, Kasemir, Kay wrote:
>> Yes, something funny is happening. Below is what 'pvinfo -d' on a machine
>> with two NICs should look like. Note the "Broadcast address #1" which is
>> missing in your case.
>> From the ordering in your log it looks like somehow at attempt is being
>> made to send the GetField message before the TCP connection is created.
>> This smells like a race condition.
>
> When I unset EPICS_PVA_ADDR_LIST and EPICS_PVA_AUTO_ADDR_LIST, I also get two addresses listed, but same end result: pvget works, pvinfo doesn't.
Ok, one mystery solved.
> $ pvget training:ai1
> training:ai1 2018-10-29T14:09:16.942 2 MAJOR DEVICE LOLO
>
> $ pvinfo training:ai1
> training:ai1 Error: channel destroyed
I've a suspicious that what you're seeing is a symptom of an exception
being thrown and swallowed.
Can you do a -debug build?
> cat <<EOF >>configure/CONFIG_SITE.local
> CROSS_COMPILER_TARGET_ARCHS+=\$(EPICS_HOST_ARCH)-debug
> EOF
> make
Then run in gdb:
> gdb --args ./bin/linux-x86_64-debug/pvinfo TST:iq
> b clientContextImpl.cpp:4679
> r
# this break should be reached on success or failure. when it is reached.
> bt
https://github.com/epics-base/pvAccessCPP/blob/b28e33566b4a05cf54a6b3a8526112e5f420cec9/src/remoteClient/clientContextImpl.cpp#L4675
I see this happening on a TCP worker thread, but from the order of the log
messages I expect you will see something else.
> (gdb) bt
> #0 (anonymous namespace)::ChannelGetFieldRequestImpl::notify (this=0x555555849ff0, sts=...,
> field=std::shared_ptr (count 2, weak 1) 0x7fffe4000f90) at ../../src/remoteClient/clientContextImpl.cpp:4679
> #1 0x00007ffff779b07a in (anonymous namespace)::ChannelGetFieldRequestImpl::response (this=0x555555849ff0, transport=
> std::shared_ptr (count 5, weak 1) 0x7fffe8000998, payloadBuffer=0x7fffe80009d8) at ../../src/remoteClient/clientContextImpl.cpp:4749
> #2 0x00007ffff779033f in (anonymous namespace)::ResponseRequestHandler::handleResponse (this=0x555555785a10, responseFrom=0x7fffe8000b4c,
> transport=std::shared_ptr (count 5, weak 1) 0x7fffe8000998, version=1 '\001', command=17 '\021', payloadSize=547,
> payloadBuffer=0x7fffe80009d8) at ../../src/remoteClient/clientContextImpl.cpp:2502
> #3 0x00007ffff77934cb in (anonymous namespace)::ClientResponseHandler::handleResponse (this=0x5555557853e0, responseFrom=0x7fffe8000b4c,
> transport=std::shared_ptr (count 5, weak 1) 0x7fffe8000998, version=1 '\001', command=17 '\021', payloadSize=547,
> payloadBuffer=0x7fffe80009d8) at ../../src/remoteClient/clientContextImpl.cpp:3012
> #4 0x00007ffff77747ba in epics::pvAccess::detail::BlockingTCPTransportCodec::processApplicationMessage (this=0x7fffe8000990)
> at ../../src/remote/pv/codec.h:352
> #5 0x00007ffff776cdb7 in epics::pvAccess::detail::AbstractCodec::processReadNormal (this=0x7fffe8000990) at ../../src/remote/codec.cpp:224
> #6 0x00007ffff776c82a in epics::pvAccess::detail::AbstractCodec::processRead (this=0x7fffe8000990) at ../../src/remote/codec.cpp:128
> #7 0x00007ffff776fc71 in epics::pvAccess::detail::BlockingTCPTransportCodec::receiveThread (this=0x7fffe8000990)
> at ../../src/remote/codec.cpp:1138
> #8 0x00007ffff777cee2 in epics::pvData::detail::MethRunner<epics::pvAccess::detail::BlockingTCPTransportCodec>::run (this=0x7fffe8005200)
> at /home/mdavidsaver/work/epics/pv/pvData/include/pv/thread.h:56
- Replies:
- Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- References:
- pvget -m timeout after first value Kasemir, Kay via Core-talk
- Re: pvget -m timeout after first value Michael Davidsaver
- Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Re: pvget -m timeout after first value Michael Davidsaver
- Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Re: pvget -m timeout after first value Michael Davidsaver
- Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Re: pvget -m timeout after first value Michael Davidsaver
- Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Re: pvget -m timeout after first value Michael Davidsaver
- Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Re: pvget -m timeout after first value Michael Davidsaver
- Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Navigate by Date:
- Prev:
Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Next:
Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Next:
Re: pvget -m timeout after first value Kasemir, Kay via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|