mdavidsaver / pvxs Goto Github PK

View Code? Open in Web Editor NEW

19.0 9.0 24.0 2.37 MB

PVA protocol client/server library and utilities.

Home Page: https://mdavidsaver.github.io/pvxs/

License: Other

Makefile 1.33% C++ 95.92% Shell 0.27% C 0.13% CMake 0.19% Python 2.09% Perl 0.06%

epics epics-controls

pvxs's Introduction

PVXS - PVAccess protocol library

VCS - https://github.com/mdavidsaver/pvxs

Documentation - https://mdavidsaver.github.io/pvxs/

pvxs's People

Contributors

Stargazers

Watchers

pvxs's Issues

pvxput doesn't understand NTEnum

Describe the bug

pvxput to an enum record fails with Error St13runtime_error : Unable to assign value from "0".

To Reproduce

Steps to reproduce the behavior:

Have an IOC serving an mbbo record (mine is using QSRV2, but the same happens with QSRV)
Write to it using pvxput $pvname $integer or pvxput $pvname $string
Get error

An example record is:

record(mbbo,"$(P)$(R)$(TRIGGER_NAME)$(TRIGGER_CHAN)Dir-Sel"){
    field(DTYP,"asynInt32")
    field(DESC,"Set trigger direction")
    field(SCAN,"Passive")
    field(NOBT,"1")
    field(ZRVL,"0")
    field(ONVL,"1")
    field(ZRST,"trn")
    field(ONST,"rcv")
    field(OUT,"@asyn($(PORT),$(ADDR))DIR")
    field(PINI,"YES")
}

Assignments using either the integer values or strings work with pvput, including when specifying pvput -p pva

Expected behavior

For the PV put to work.

Information (please complete the following):

PVXS Version or Git commit ID: 1911f2d
EPICS Base Version: 5eff3803a83fbc3ea855b63841f5359c09830ade
libevent Version: 2.1.12
EPICS_HOST_ARCH: linux-x86_64
Host OS: Ubuntu 22.04
Compiler version: Ubuntu clang version 14.0.0-1ubuntu1

Alternately, from a successful build, include the output of pvxinfo -D.

Network configuration

Effective Client config from environment
    EPICS_PVA_ADDR_LIST="10.0.38.40:5076 10.0.38.46:60000 10.0.38.59:60000 10.10.10.126:5076 10.20.26.78:5076 10.20.26.82:5076 10.15.7.255 172.18.255.255 172.17.255.255"
    EPICS_PVA_AUTO_ADDR_LIST=NO
    EPICS_PVA_BROADCAST_PORT=5076
    EPICS_PVA_SERVER_PORT=5075
    EPICS_PVA_CONN_TMO=30

Additional context

The -d output from the command:

2023-05-10T17:52:07.631060588 DEBUG pvxs.iface refresh after 3485439.3 sec
2023-05-10T17:52:07.631296900 DEBUG pvxs.iface Ignoring interface 'lo' address family=17
2023-05-10T17:52:07.631396541 DEBUG pvxs.iface Ignoring interface 'enp0s31f6' address family=17
2023-05-10T17:52:07.631427027 DEBUG pvxs.iface Ignoring interface 'wlp0s20f3' address family=17
2023-05-10T17:52:07.631449595 DEBUG pvxs.iface Ignoring interface 'br-3083ab0b5a5d' address family=17
2023-05-10T17:52:07.631482172 DEBUG pvxs.iface Ignoring interface 'docker0' address family=17
2023-05-10T17:52:07.631497073 DEBUG pvxs.iface Ignoring interface 'veth2909771' address family=17
2023-05-10T17:52:07.631511065 DEBUG pvxs.iface Ignoring interface 'enx806d97457e12' address family=17
2023-05-10T17:52:07.631584120 DEBUG pvxs.iface Found interface 1 "lo" w/ 2 127.0.0.1
2023-05-10T17:52:07.631617732 DEBUG pvxs.iface Found interface 4 "wlp0s20f3" w/ 2 10.15.2.104
2023-05-10T17:52:07.631634951 DEBUG pvxs.iface Found interface 5 "br-3083ab0b5a5d" w/ 2 172.18.0.1
2023-05-10T17:52:07.631653005 DEBUG pvxs.iface Found interface 6 "docker0" w/ 2 172.17.0.1
2023-05-10T17:52:07.631720389 DEBUG pvxs.iface Found interface 1 "lo" w/ 10 [::1]
2023-05-10T17:52:07.631738253 DEBUG pvxs.iface Found interface 4 "wlp0s20f3" w/ 10 [fe80::a681:86d5:977d:76ec]%4
2023-05-10T17:52:07.631823325 DEBUG pvxs.iface Found interface 5 "br-3083ab0b5a5d" w/ 10 [fc00:f853:ccd:e793::1]
2023-05-10T17:52:07.631871921 DEBUG pvxs.iface Found interface 5 "br-3083ab0b5a5d" w/ 10 [fe80::42:6bff:fea0:7ec9]%5
2023-05-10T17:52:07.631910693 DEBUG pvxs.iface Found interface 5 "br-3083ab0b5a5d" w/ 10 [fe80::1]%5
2023-05-10T17:52:07.631939170 DEBUG pvxs.iface Found interface 26 "veth2909771" w/ 10 [fe80::50d3:73ff:fe7b:c450]%26
2023-05-10T17:52:07.632104212 INFO pvxs.loop Enter loop worker for 0x7f9a80000c00 using epoll
2023-05-10T17:52:07.632314107 INFO pvxs.loop Enter loop worker for 0x7f9a84000bb0 using epoll
2023-05-10T17:52:07.632370946 DEBUG pvxs.client.setup Using UDP Rx port 53864
2023-05-10T17:52:07.632426741 INFO pvxs.client.io Searching to 10.0.38.40:5076 unicast
2023-05-10T17:52:07.632451709 INFO pvxs.client.io Searching to 10.0.38.46:60000 unicast
2023-05-10T17:52:07.632475652 INFO pvxs.client.io Searching to 10.0.38.59:60000 unicast
2023-05-10T17:52:07.632502877 INFO pvxs.client.io Searching to 10.10.10.126:5076 unicast
2023-05-10T17:52:07.632516564 INFO pvxs.client.io Searching to 10.20.26.78:5076 unicast
2023-05-10T17:52:07.632530320 INFO pvxs.client.io Searching to 10.20.26.82:5076 unicast
2023-05-10T17:52:07.632566908 INFO pvxs.client.io Searching to 10.15.7.255:5076
2023-05-10T17:52:07.632581847 INFO pvxs.client.io Searching to 172.18.255.255:5076
2023-05-10T17:52:07.632621765 INFO pvxs.client.io Searching to 172.17.255.255:5076
2023-05-10T17:52:07.632693387 INFO pvxs.udp.setup Bound to UDP 0.0.0.0:5076 as lo
2023-05-10T17:52:07.632748838 INFO pvxs.client.io Listening for beacons on 0.0.0.0:5076
2023-05-10T17:52:07.632803686 INFO pvxs.udp.setup Bound to UDP [::]:41869 as lo
2023-05-10T17:52:07.632819323 DEBUG pvxs.udp.setup Start listening for UDP 0.0.0.0:5076
2023-05-10T17:52:07.632828738 DEBUG pvxs.udp.setup Start listening for UDP [::]:41869
2023-05-10T17:52:07.632862117 DEBUG pvxs.client.setup scheduleInitialSearch()
2023-05-10T17:52:07.632879158 DEBUG pvxs.client.setup hurryUp()
2023-05-10T17:52:07.632924491 DEBUG pvxs.client.io Search tick 0
2023-05-10T17:52:07.645068184 DEBUG pvxs.client.io Search tick 1
0000 : CA028003 0000004C 66696E64 80000000
0010 : 00000000 00000000 00000000 00000000
0020 : D2680103 74637000 01123456 78264445
0030 : 2D323353 4C31313A 42532D46 4F464243
...
2023-05-10T17:52:07.645206682 DEBUG pvxs.client.io Search to 10.0.38.40:5076 ucast
0000 : CA028003 0000004C 66696E64 80000000
0010 : 00000000 00000000 00000000 00000000
0020 : D2680103 74637000 01123456 78264445
0030 : 2D323353 4C31313A 42532D46 4F464243
...
2023-05-10T17:52:07.645233673 DEBUG pvxs.client.io Search to 10.0.38.46:60000 ucast
0000 : CA028003 0000004C 66696E64 80000000
0010 : 00000000 00000000 00000000 00000000
0020 : D2680103 74637000 01123456 78264445
0030 : 2D323353 4C31313A 42532D46 4F464243
...
2023-05-10T17:52:07.645247262 DEBUG pvxs.client.io Search to 10.0.38.59:60000 ucast
0000 : CA028003 0000004C 66696E64 80000000
0010 : 00000000 00000000 00000000 00000000
0020 : D2680103 74637000 01123456 78264445
0030 : 2D323353 4C31313A 42532D46 4F464243
...
2023-05-10T17:52:07.645258347 DEBUG pvxs.client.io Search to 10.10.10.126:5076 ucast
errlog: lost 12 messages
0000 : CA028003 0000004C 66696E64 00000000
0010 : 00000000 00000000 00000000 00000000
0020 : D2680103 74637000 01123456 78264445
0030 : 2D323353 4C31313A 42532D46 4F464243
...
2023-05-10T17:52:07.645304019 DEBUG pvxs.client.io Search to 10.15.7.255:5076 bcast
2023-05-10T17:52:07.645314184 DEBUG pvxs.udp.io UDP 0x7f9a84001870 event 2
0000 : CA028003 0000004C 66696E64 00000000
0010 : 00000000 00000000 00000000 00000000
0020 : D2680103 74637000 01123456 78264445
0030 : 2D323353 4C31313A 42532D46 4F464243
...
2023-05-10T17:52:07.645344493 DEBUG pvxs.client.io Search to 172.18.255.255:5076 bcast
0000 : CA028003 0000004C 66696E64 00000000
0010 : 00000000 00000000 00000000 00000000
0020 : D2680103 74637000 01123456 78264445
0030 : 2D323353 4C31313A 42532D46 4F464243
...
2023-05-10T17:52:07.645361820 DEBUG pvxs.client.io Search to 172.17.255.255:5076 bcast
0000 : CA028003 0000004C 66696E64 00000000
0010 : 00000000 00000000 00000000 00000000
0020 : D2680103 74637000 01123456 78264445
0030 : 2D323353 4C31313A 42532D46 4F464243
...
2023-05-10T17:52:07.645370495 DEBUG pvxs.udp.io UDP Rx 84, 10.15.2.104:53864 -> 10.15.7.255:5076 @4 (0.0.0.0:5076)
0000 : CA028003 0000004C 66696E64 00000000
0010 : 00000000 00000000 00000000 00000000
0020 : D2680103 74637000 01123456 78264445
0030 : 2D323353 4C31313A 42532D46 4F464243
...
2023-05-10T17:52:07.645461904 DEBUG pvxs.udp.io UDP Rx 84, 172.18.0.1:53864 -> 172.18.255.255:5076 @5 (0.0.0.0:5076)
0000 : CA028003 0000004C 66696E64 00000000
0010 : 00000000 00000000 00000000 00000000
0020 : D2680103 74637000 01123456 78264445
0030 : 2D323353 4C31313A 42532D46 4F464243
...
2023-05-10T17:52:07.645473590 DEBUG pvxs.udp.io UDP Rx 84, 172.17.0.1:53864 -> 172.17.255.255:5076 @6 (0.0.0.0:5076)
2023-05-10T17:52:07.650553746 DEBUG pvxs.client.io UDP search Rx event 2
0000 : CA02C004 0000002D 71966CD6 22B326E1
0010 : A2960736 66696E64 00000000 00000000
0020 : 0000FFFF 00000000 13D30374 63700100
0030 : 01123456 78  
2023-05-10T17:52:07.650583647 DEBUG pvxs.client.io UDP search Rx 53 from 10.20.26.82:5076
2023-05-10T17:52:07.650605285 DEBUG pvxs.client.io Search reply for DE-23SL11:BS-FOFBCtrl:SYSIDTrigger-Sel
2023-05-10T17:52:07.650714062 DEBUG pvxs.client.io Connecting to 10.20.26.82:5075, RX readahead 262144
0000 : 00000000 0000000D 00000000 00000000
0010 : 000B0040 00000000 FFFFFFFF 0000008E
0020 : CA028003 0000004C 66696E64 80000000
0030 : 4341533A 20446174 61677261 6D207265
...
2023-05-10T17:52:07.650727873 DEBUG pvxs.client.io Ignore UDP message from 10.0.38.59:60000
2023-05-10T17:52:07.650741271 DEBUG pvxs.client.io UDP search processed 2/40
2023-05-10T17:52:07.653186959 DEBUG pvxs.client.io Connected to 10.20.26.82:5075
0000 : CA024102 00000000  
2023-05-10T17:52:07.655481863 DEBUG pvxs.tcp.io Server 10.20.26.82:5075 Receive header
0000 : CA024001 14000000  
2023-05-10T17:52:07.655495388 DEBUG pvxs.tcp.io Server 10.20.26.82:5075 Receive header
2023-05-10T17:52:07.655502000 DEBUG pvxs.client.io Server 10.20.26.82:5075 begins validation handshake
2023-05-10T17:52:07.655511677 DEBUG pvxs.client.io Server 10.20.26.82:5075 selecting auth 'ca'
2023-05-10T17:52:07.655761729 INFO pvxs.client.io Server 10.20.26.82:5075 'ca' auth as erico.rolim@S-SWC03-L
0000 : CA024009 01000000  
2023-05-10T17:52:07.657881555 DEBUG pvxs.tcp.io Server 10.20.26.82:5075 Receive header
2023-05-10T17:52:07.657905209 DEBUG pvxs.client.io Server 10.20.26.82:5075 accepts auth
2023-05-10T17:52:07.657916990 DEBUG pvxs.client.io Server 10.20.26.82:5075 creating channel 'DE-23SL11:BS-FOFBCtrl:SYSIDTrigger-Sel' (305419896)
0000 : CA024007 09000000  
2023-05-10T17:52:07.659967935 DEBUG pvxs.tcp.io Server 10.20.26.82:5075 Receive header
2023-05-10T17:52:07.660017244 DEBUG pvxs.client.io Server 10.20.26.82:5075 active channel to 'DE-23SL11:BS-FOFBCtrl:SYSIDTrigger-Sel' 305419896:117768961
2023-05-10T17:52:07.660037350 DEBUG pvxs.client.io Server 10.20.26.82:5075 channel 'DE-23SL11:BS-FOFBCtrl:SYSIDTrigger-Sel' op0b INIT
0000 : CA02400B B9000000  
2023-05-10T17:52:07.662106812 DEBUG pvxs.tcp.io Server 10.20.26.82:5075 Receive header
0000 : CA02400B 5A000000  
2023-05-10T17:52:07.664332996 DEBUG pvxs.tcp.io Server 10.20.26.82:5075 Receive header
2023-05-10T17:52:07.664399172 DEBUG pvxs.client.io Server 10.20.26.82:5075 channel DE-23SL11:BS-FOFBCtrl:SYSIDTrigger-Sel op0b state 3 -> 4
Error St13runtime_error : Unable to assign value from "0"
2023-05-10T17:52:07.665023558 DEBUG pvxs.client.setup context 0x5611abaa2130 close
2023-05-10T17:52:07.665440051 DEBUG pvxs.client.io Server 10.20.26.82:5075 detach channel 'DE-23SL11:BS-FOFBCtrl:SYSIDTrigger-Sel' to re-search
2023-05-10T17:52:07.665458039 DEBUG pvxs.client.io Cleaning connection to 10.20.26.82:5075
2023-05-10T17:52:07.665601765 DEBUG pvxs.udp.setup Stop listening for UDP 0.0.0.0:5076
2023-05-10T17:52:07.665679541 DEBUG pvxs.udp.setup Stop listening for UDP [::]:41869
2023-05-10T17:52:07.665724280 INFO pvxs.loop Exit loop worker: 0 for 0x7f9a84000bb0
2023-05-10T17:52:07.665827906 INFO pvxs.loop Exit loop worker: 0 for 0x7f9a80000c00

(apparently) spurious compile error with GCC 12

G++ 12 (default w/ debian 12) gives the following error with -O2 -Wall. This appears to be spurious. G++ 11.x and 13.x do not complain.

In file included from ../testshared.cpp:12:
In constructor ‘pvxs::shared_array<E, Enable>::shared_array(size_t, V) [with V = std::nullptr_t; E = std::unique_ptr<unsigned int>; Enable = void]’,
    inlined from ‘void {anonymous}::testComplex()’ at ../testshared.cpp:225:57:
../../src/pvxs/sharedArray.h:288:17: error: pointer used after ‘void operator delete [](void*, std::size_t)’ [-Werror=use-after-free]
  288 |         :base_t(new _E_non_const[c], c)
      |                 ^~~~~~~~~~~~~~~~~~~
In member function ‘void pvxs::detail::sa_default_delete<E>::operator()(E*) const [with E = std::unique_ptr<unsigned int>]’,
    inlined from ‘std::__shared_count<_Lp>::__shared_count(_Ptr, _Deleter, _Alloc) [with _Ptr = std::unique_ptr<unsigned int>*; _Deleter = pvxs::detail::sa_default_delete<std::unique_ptr<unsigned int> >; _Alloc = std::allocator<void>; <template-parameter-2-4> = void; __gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic]’ at /usr/include/c++/12/bits/shared_ptr_base.h:958:11,
    inlined from ‘std::__shared_count<_Lp>::__shared_count(_Ptr, _Deleter) [with _Ptr = std::unique_ptr<unsigned int>*; _Deleter = pvxs::detail::sa_default_delete<std::unique_ptr<unsigned int> >; <template-parameter-2-3> = void; __gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic]’ at /usr/include/c++/12/bits/shared_ptr_base.h:939:57,
    inlined from ‘std::__shared_ptr<_Tp, _Lp>::__shared_ptr(_Yp*, _Deleter) [with _Yp = std::unique_ptr<unsigned int>; _Deleter = pvxs::detail::sa_default_delete<std::unique_ptr<unsigned int> >; <template-parameter-2-3> = void; _Tp = std::unique_ptr<unsigned int>; __gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic]’ at /usr/include/c++/12/bits/shared_ptr_base.h:1478:17,
    inlined from ‘std::shared_ptr<_Tp>::shared_ptr(_Yp*, _Deleter) [with _Yp = std::unique_ptr<unsigned int>; _Deleter = pvxs::detail::sa_default_delete<std::unique_ptr<unsigned int> >; <template-parameter-2-3> = void; _Tp = std::unique_ptr<unsigned int>]’ at /usr/include/c++/12/bits/shared_ptr.h:232:48,
    inlined from ‘pvxs::detail::sa_base<E>::sa_base(A*, size_t) [with A = std::unique_ptr<unsigned int>; E = std::unique_ptr<unsigned int>]’ at ../../src/pvxs/sharedArray.h:136:10,
    inlined from ‘pvxs::shared_array<E, Enable>::shared_array(size_t, V) [with V = std::nullptr_t; E = std::unique_ptr<unsigned int>; Enable = void]’ at ../../src/pvxs/sharedArray.h:288:39,
    inlined from ‘void {anonymous}::testComplex()’ at ../testshared.cpp:225:57:
../../src/pvxs/sharedArray.h:92:35: note: call to ‘void operator delete [](void*, std::size_t)’ here
   92 |     void operator()(E* e) const { delete[] e; }
      |                                   ^~~~~~~~~~

Problem when monitoring NT PV with value field as "any"

I have a test program (IOC) that monitors a set of NT PVs which are made of many structures and a "value" field that is set to "any" (the PVs were created using QSRV info tags). I noticed that when moving from PVXS 1.0.1 to 1.1.3 the monitor event crashed, yielding the following stack trace in the IOC console:

 LabS-ICS:SC-IOC-414:TstGrp Connected to 172.30.4.228:42204
2023-03-28T23:33:36.766608666 CRIT pvxs.tcp.io Server Error while processing cmd 0x0d: No such field
Dumping a stack trace of thread 'PVXCTCP':
[    0x7f844f2ba84b]: /opt/epics-vanilla/base-7.0.7/lib/linux-x86_64/libCom.so.3.22.0(epicsStackTrace+0x4b)
[    0x7f844f5fdf8a]: /opt/epics-vanilla/pvxs-1.1.3/lib/linux-x86_64/libpvxs.so.1.1(_ZN4pvxs6detailL12_log_vprintfEjPKcP13__va_list_tag+0x84)
[    0x7f844f5fe034]: /opt/epics-vanilla/pvxs-1.1.3/lib/linux-x86_64/libpvxs.so.1.1(_ZN4pvxs6detail11_log_printfEjPKcz+0xa3)
[    0x7f844f67fcdb]: /opt/epics-vanilla/pvxs-1.1.3/lib/linux-x86_64/libpvxs.so.1.1(_ZN4pvxs4impl8ConnBase7bevReadEv+0xb11)
[    0x7f844f67fef7]: /opt/epics-vanilla/pvxs-1.1.3/lib/linux-x86_64/libpvxs.so.1.1(_ZN4pvxs4impl8ConnBase8bevReadSEP11buffereventPv+0x51)
[    0x7f844f05ef7c]: /lib64/libevent_core-2.0.so.5(_bufferevent_decref_and_unlock+0x23c)
[    0x7f844f055495]: /lib64/libevent_core-2.0.so.5(event_base_loop+0x865)
[    0x7f844f65894e]: /opt/epics-vanilla/pvxs-1.1.3/lib/linux-x86_64/libpvxs.so.1.1(_ZN4pvxs4impl6evbase3Pvt3runEv+0x354)
[    0x7f844f2af759]: /opt/epics-vanilla/base-7.0.7/lib/linux-x86_64/libCom.so.3.22.0(epicsThreadCallEntryPoint+0x69)
[    0x7f844f2b45ea]: /opt/epics-vanilla/base-7.0.7/lib/linux-x86_64/libCom.so.3.22.0(start_routine+0xda)
[    0x7f844e345ea5]: /lib64/libpthread.so.0(start_thread+0xc5)
[    0x7f844e85bb0d]: /lib64/libc.so.6(clone+0x6d)
LabS-ICS:SC-IOC-414:TstGrp Disconnected

I tested again with PVXS 1.0.1 and everything was OK. Then I started testing with pvxmonitor from PVXS >= 1.0.1 and managed to reproduce the same problem.

To Reproduce
Steps to reproduce the behavior:

Create a simple IOC with a "group" PV, something like the database below:

record(calc, "$(P)$(R)$(NAME)A") {
    field(CALC, "A+1")
    field(INPA, "$(P)$(R)$(NAME)A")
    field(SCAN, ".5 second")

    info(Q:group, {
        "$(P)$(R)$(NAME)Grp": {
            "A": {+type:"any", +channel:"VAL"}
        }
    })
}

record(calc, "$(P)$(R)$(NAME)B") {
    field(CALC, "A+1")
    field(INPA, "$(P)$(R)$(NAME)B")
    field(SCAN, "1 second")

    info(Q:group, {
        "$(P)$(R)$(NAME)Grp": {
            "B": {+type:"any", +channel:"VAL"}
        }
    })

}

Try to monitor the group PV using pvxmonitor from PVXS 1.0.1, 1.1.0 onwards...
PVXS 1.0.1 monitor should result:

FOO:BAR:PVNAME Connected to 192.168.0.1:PORTNUM
FOO:BAR:PVNAME
struct
record struct
record._options struct
record._options.queueSize uint32_t = 0
record._options.atomic bool = false
A any
A-> double = [some number]
B any
B-> double = [some number]

PVXS 1.1.0 monitor breaks with the following error:

CRIT pvxs.tcp.io Server Error while processing cmd 0x0d: No such field

The same happens for PVXS > 1.1.0

Information (please complete the following):

PVXS Version or Git commit ID: tested with all releases from 1.0.1 (until 1.1.3). The problem shows up in 1.1.0
EPICS Base Version: 7.0.7
libevent Version: libevent 2.0.21-stable
EPICS_HOST_ARCH: linux-x86_64
Host OS: CentOS 7
Compiler version: gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)

Additional context
If, in the given example of group PV, we change the info tag of the group member from {+type:"any", +channel:"VAL"} to { +channel:"VAL"}, the problem disappears.

Michael, any guidance on how I can be helpful is appreciated.

Trigger warning behaviour

We have some records we don't want to define +trigger mappings for:

#### test.db

record(waveform, "PANDA:TTLOUT1:PVI_PV")
{
    field(DISP, "1")
    field(FTVL, "CHAR")
    field(NELM, "18")
    field(PINI, "YES")
    info(Q:form, "String")
    info(Q:group, {
        "PANDA:PVI": {
            "pvi.ttlout2.d": {
                "+channel": "VAL",
                "+type": "plain",
                "+trigger": ""
            }
        }
    })
}


record(waveform, "PANDA:TTLOUT2:PVI_PV")
{
    field(DISP, "1")
    field(FTVL, "CHAR")
    field(NELM, "18")
    field(PINI, "YES")
    info(Q:form, "String")
    info(Q:group, {
        "PANDA:PVI": {
            "pvi.ttlout2.d": {
                "+channel": "VAL",
                "+type": "plain",
                "+trigger": ""
            }
        }
    })
}

We run them in a softioc:

from softioc import softioc
from softioc.asyncio_dispatcher import AsyncioDispatcher


x = AsyncioDispatcher()


softioc.dbLoadDatabase("test.db")
softioc.iocInit(x)

We end up with the following warning message:

INFO: PVXS QSRV2 is loaded and ENABLED.
Starting iocInit
############################################################################
## EPICS 7.0.7.0
## Rev. 7.0.7.99.0.2
## Rev. Date 7.0.7.99.0.2
############################################################################
2023-10-17T09:27:12.688066942 WARN pvxs.ioc.group.processor
     Group PANDA:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
iocRun: All initialization complete

We don't want to define "+trigger": "*" for many records in pandablocks-ioc, however this leads to a large number of warnings on ioc start up:

...
2023-10-17T09:37:49.821435534 WARN pvxs.ioc.group.processor
     Group PANDA:TTLOUT10:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
2023-10-17T09:37:49.821448682 WARN pvxs.ioc.group.processor
     Group PANDA:TTLOUT1:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
2023-10-17T09:37:49.821462101 WARN pvxs.ioc.group.processor
     Group PANDA:TTLOUT2:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
2023-10-17T09:37:49.821475511 WARN pvxs.ioc.group.processor
     Group PANDA:TTLOUT3:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
2023-10-17T09:37:49.821488695 WARN pvxs.ioc.group.processor
     Group PANDA:TTLOUT4:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
2023-10-17T09:37:49.821501776 WARN pvxs.ioc.group.processor
     Group PANDA:TTLOUT5:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
2023-10-17T09:37:49.821515507 WARN pvxs.ioc.group.processor
     Group PANDA:TTLOUT6:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
2023-10-17T09:37:49.821528580 WARN pvxs.ioc.group.processor
     Group PANDA:TTLOUT7:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
2023-10-17T09:37:49.821541815 WARN pvxs.ioc.group.processor
     Group PANDA:TTLOUT8:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
2023-10-17T09:37:49.821554507 WARN pvxs.ioc.group.processor
     Group PANDA:TTLOUT9:PVI defines no +trigger mappings.  Default to individual/split monitor updates.
iocRun: All initialization complete
Python 3.10.4 | packaged by conda-forge | (main, Mar 24 2022, 17:38:57) [GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)

Tested with:

pvxslibs==1.2.3
softioc==4.4.0
pvi==0.5

Adding pvlist feature

Are there any plans to add support for using the EPICS pvlist command line tool? I've been able to hack something together using system calls to pvlist within my C++ project to get a list of servers, and then pull down all pvs across all the servers, but it may be more convenient for a similar function to be handled within the pvxs library.

(De)serialization of Value fields

Is there a way to (de)serialize Value fields, or something similar like the example below in pvData?

   epics::pvData::PVStructure::shared_pointer structure_; 
   std::shared_ptr<epics::pvData::ByteBuffer> buffer_;
    ....
    for (size_t i = 0U; i < structure_->getNumberFields(); ++i) {
      //  Request subfield
      const epics::pvData::PVFieldPtr field = structure_->getSubField(i);

      //  If subfield has no children i.e. represents actual value then
      //  serialize it
      if ((field != nullptr) && (field->getNumberFields() == 1)) {
        field->serialize(buffer_.get(), serializable_control_.get());
      }
    }

  // deserialize
  for (size_t i = 0U; i < structure_->getNumberFields(); ++i) {
    const epics::pvData::PVFieldPtr field = structure_->getSubField(i);
    if ((field != nullptr) && (field->getNumberFields() == 1)) {
      field->deserialize(buffer_.get(), deserializable_control_.get());
    }
  }

Incorrect .dbd included in python builds

Since #57 ioc/pvxs7x.dbd needs to be renamed to pvxsIoc.dbd. However, this is not done by the python build.

cf. dls-controls/pythonSoftIOC#146

Build does not respect STATIC_BUILD linker option for bundled libevent

Describe the bug
Building libevent on Linux produces both shared and static libraries. When building with PVXS, the STATIC_BUILD = YES and SHARED_LIBRARIES = NO options are ignored when linking libevent. In other words, the linker will not attempt to use libevent.a when there's a libevent.so.* in the library search path.

As a workaround, I built the bundled libevent with CMAKEFLAGS += -DEVENT__LIBRARY_TYPE=STATIC added to the bundle/Makefile. The output directory bundle/usr/<target>/lib only contains static .a files. When I do this the application will statically link libevent as expected.

To Reproduce
Steps to reproduce the behavior:

Build libevent normally (for me, make -C bundle libevent.linuxRT-x86_64 )
Add SHARED_LIBRARIES=NO and STATIC_BUILD=YES lines to the PVXS configure/CONFIG_SITE
Build normally (make from <TOP>)
Set up a static building EPICS application. makeBaseApp.pl, modify configure/CONFIG_SITE with the static build variables (both STATIC_BUILD=YES and SHARED_LIBRARIES=NO), properly include PVXS per your instructions, etc.)
build normally

objdump -p bin/<target>/<app> | grep NEEDED
...
  NEEDED               libevent_core-2.2.so.1
  NEEDED               libevent_pthreads-2.2.so.1

Expected behavior
I'd expect an application build to respect STATIC_BUILD and link libevent statically. I think this is an issue with the files in cfg/ but I couldn't figure out a hack to make it ignore the shared libraries.

Information (please complete the following):

PVXS Version or Git commit ID: 85783e2
EPICS Base Version: 7.0.3
libevent Version: bundled
EPICS_HOST_ARCH: rhel7-x86_64
EPICS Target Arch. : linuxRT-x86_64
Host OS: RHEL 7
Target OS: SLAC buildroot linuxRT. I've also reproduced this problem with the rhel7 host arch.
Compiler version: 8.3.0 for linuxRT and 4.8.4 and 10.2.1 on rhel 7

Decode error resulting from incorrect TypeStore maintenance

https://epics.anl.gov/core-talk/2022/msg00526.php

2022-12-14T13:14:03.905922950 CRIT pvxs.tcp.io Server Error while processing cmd 0x0a: vector::_M_range_check

Intermittent failure of `testsock`

Description
In local builds on a VM, some tests fail consistently:

testsock.t .....
not ok  5 - Recv'd -1(11) [0, 0, 0, 0]
not ok  6 - src (<>) == send_addr (127.0.0.1:35007)
not ok  8 - Recv'd -1 [0, 0, 0, 0]
not ok  9 - src (<>) == sender_addr (127.0.0.1:52034)
Dubious, test returned 1 (wstat 256, 0x100)
Failed 4/33 subtests

Information:

PVXS Version or Git commit ID: 0.2.1
EPICS Base Version: 7.0.6.1
libevent Version: 2.1.8-5.el8
EPICS_HOST_ARCH: linux-x86_64
Host OS: RHEL 8.4
Compiler version: gcc version 8.4.1 20200928 (Red Hat 8.4.1-1) (GCC)

TypeDef from Value containing Union does not work

Describe the bug
Creating TypeDef from Value containing Union does not work. This is clearly a bug that can be reproduced with the test as follows.

To Reproduce
The bug can be reproduced with following test:

void testGetTypeDefFromValue()
{
    testDiag("%s()", __func__);

    using namespace pvxs::members;
    auto top = TypeDef(TypeCode::Struct, "top_t", {
                       Struct("scalar", {
                           Int32("i32"),
                           UInt32("u32"),
                           Bool("b"),
                           Float64("f64"),
                           String("s"),
                           Any("wildcard"),
                           Union("choice", {
                               Int32("one"),
                               Struct("two", {
                                   Int32("ahalf"),
                               }),
                           }),
                       }),
                       Struct("array", {
                           Int32A("i32"),
                           StringA("s"),
                           AnyA("wildcard"),
                           UnionA("choice", {
                               Int32("one"),
                               Struct("two", {
                                   Int32("ahalf"),
                               }),
                           }),
                           StructA("more", {
                               Int32("one"),
                               Struct("two", {
                                   Int32("ahalf"),
                               }),
                           }),
                       }),
                   }).create();

    TypeDef(top);    // !! INFINITE RECURSION !! //
}

Expected behavior

TypeDef should return (and shouldn’t go into an infinite recursion).

Information (please complete the following):

PVXS Version or Git commit ID: initially fixed on edbcd46, merged and retested with 9c546f0

Host OS: CentOS8.5.2111 (WSL2)

output of pvxinfo -D.

Host: linux-x86_64
Target: linux-x86_64 Linux gcc
Toolchain
    __cplusplus = 201103
    GCC 8.5.0
    _GLIBCXX_USE_CXX11_ABI = 1
    GLIBC 2.28
    __GLIBCXX__ 20210514
Versions
    PVXS 1.1.2 (1.1.2-15-g9c546f0ed448ec9f17d9-dirty)
    EPICS 7.0.6.1-DEV
    libevent 2.1.8-stable
Runtime
    uname() -> Linux PC6107 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64
    epicsThreadGetCPUs() -> 16
    osiLocalAddr() -> 172.27.168.0
    osiSockDiscoverBroadcastAddresses() ->
        172.27.175.255
Effective Client config from environment
    EPICS_PVA_ADDR_LIST="172.27.175.255"
    EPICS_PVA_AUTO_ADDR_LIST=NO
    EPICS_PVA_BROADCAST_PORT=5076
    EPICS_PVA_SERVER_PORT=5075
    EPICS_PVA_CONN_TMO=30
Effective Server config from environment
    EPICS_PVAS_INTF_ADDR_LIST="[::]"
    EPICS_PVAS_BEACON_ADDR_LIST="172.27.175.255"
    EPICS_PVAS_IGNORE_ADDR_LIST=""
    EPICS_PVAS_AUTO_BEACON_ADDR_LIST=NO
    EPICS_PVAS_SERVER_PORT=5075
    EPICS_PVAS_BROADCAST_PORT=5076
    EPICS_PVA_CONN_TMO=30

Additional context
The problem is investigated and a fix proposal is ready. We could support in pushing the upstream and launch a pull-request to review.
Please let us know you preference.

pvxinfo also shows the null value for StoreType::Compound data types like any or union

Describe the bug
The pvxinfo CLI tool also shows the null value for StoreType::Compound data types like any or union.

To Reproduce
Steps to reproduce the behavior:

Start a PVXS server and provide NTNDArray data as follows,

int server() {
    server::SharedPV pv(server::SharedPV::buildMailbox());
    auto def = nt::NTNDArray{}.build();
    auto initial = def.create();
    pv.open(initial);
    server::Server::fromEnv()        // Configure a server using $EPICS_PVAS_* or $EPICS_PVA_*
            .addPV("my:pv:name", pv) // add (and name) one local PV
            .run();                  // run until SIGINT
    return 0;
}

Use pvxinfo to print info for "my:pv:name",

my:pv:name from 10.1.236.131:5075
struct "epics:nt/NTNDArray:1.0" {
    union value        null
    struct "codec_t" {
        string name
        any parameters            null
    } codec
    int64_t compressedSize
    int64_t uncompressedSize
    int32_t uniqueId
    struct "time_t" {
        int64_t secondsPastEpoch
        int32_t nanoseconds
        int32_t userTag
    } dataTimeStamp
    struct "alarm_t" {
        int32_t severity
        int32_t status
        string message
    } alarm
    struct "time_t" {
        int64_t secondsPastEpoch
        int32_t nanoseconds
        int32_t userTag
    } timeStamp
    struct[] dimension
    struct[] attribute
}

Expected behavior
pvxinfo prints info without value.

Information (please complete the following):

PVXS Version: 1.2.0
EPICS Base Version: 7.0.7

From the source code, it looks like null values are always printed no matter what fmt._showValue is,
https://github.com/mdavidsaver/pvxs/blob/master/src/datafmt.cpp

Feature suggestion: pvxget and pvxmonitor could use more output options

Output options for pvxget and pvxmonitor aren't as mature as caget/camonitor, including numeric formatting and more. This request is also being made of pvget/pvmonitor.

CMake support?

Hi, is there any chance that there will be CMake support for pvxs in the future?

I could potentially have a go at adding this if there are no plans to do so.

Status of put operation

I want to create several put operations, store them in some container and when completed (the result lambda is called), remove the corresponding operation from the container.

I can't find any relation between the Result passed to the lambda and the operation returned by exec.
I think I could spawn a thread to iterate the container and call op->wait(0) - if waiting 0 is supported - and check if Timeout is thrown but there must be another way.

Is there a better way to reset the operations stored in a container when completed ?

Build fails against Base 7.0.1

PVXS does not build against Base 7.0.1
Building against 7.0.1 fails with

/usr/bin/g++  -D_GNU_SOURCE -D_DEFAULT_SOURCE         -DUSE_TYPED_RSET -I../../src   -D_X86_64_  -DUNIX  -Dlinux     -O3 -g   -Wall     -std=c++11  -mtune=generic     -m64  -I. -I../O.Common -I. -I. -I.. -I../../include/compiler/gcc -I../../include/os/Linux -I../../include -I/opt/codac-6.0/epics/include/compiler/gcc -I/opt/codac-6.0/epics/include/os/Linux -I/opt/codac-6.0/epics/include       -I/opt/codac-6.0/include   -c ../testget.cpp
/usr/bin/g++  -D_GNU_SOURCE -D_DEFAULT_SOURCE         -DUSE_TYPED_RSET -I../../src   -D_X86_64_  -DUNIX  -Dlinux     -O3 -g   -Wall     -std=c++11  -mtune=generic     -m64  -I. -I../O.Common -I. -I. -I.. -I../../include/compiler/gcc -I../../include/os/Linux -I../../include -I/opt/codac-6.0/epics/include/compiler/gcc -I/opt/codac-6.0/epics/include/os/Linux -I/opt/codac-6.0/epics/include       -I/opt/codac-6.0/include   -c ../testmon.cpp
[WARN] ../testconfig.cpp: In function 'void {anonymous}::testParse()':
[ERROR] ../testconfig.cpp:43:40: error: 'epicsEnvUnset' was not declared in this scope
[WARN] epicsEnvUnset("EPICS_PVA_ADDR_LIST");
[WARN] ^
[WARN] make[2]: *** [testconfig.o] Error 1
[WARN] make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory `/home/DCS/langer/work/CODAC/m-epics-pvxs/target/pvxs-0.0.git20200522/test/O.linux-x86_64'
[WARN] make[1]: *** [install.linux-x86_64] Error 2
make[1]: Leaving directory `/home/DCS/langer/work/CODAC/m-epics-pvxs/target/pvxs-0.0.git20200522/test'
[WARN] make: *** [test.install] Error 2

To Reproduce
Steps to reproduce the behavior:

make
oops

Expected behavior
A working build.

Information:

PVXS Version or Git commit ID: 92ea351
EPICS Base Version: 7.0.1.1
EPICS_HOST_ARCH: linux-x86_64
Host OS: RHEL 7.4

Feature request: `python -m pvxslibs.ioc`

I have monkeypatched this like so:

import ctypes
import os

import pvxslibs.path
from epicscorelibs import ioc
from setuptools_dso.runtime import find_dso

pvxsIoc = ctypes.CDLL(find_dso("pvxslibs.lib.pvxsIoc"), ctypes.RTLD_GLOBAL)
os.environ.setdefault("PVXS_QSRV_ENABLE", "YES")

orig_dbld = ioc.dbLoadDatabase

def dbLoadDatabase(dbd, dbdpath, substitutions):
    if dbd == b"qsrv.dbd":
        orig_dbld(b"pvxsIoc.dbd", pvxslibs.path.dbd_path.encode(), None)
    elif dbd == b"PVAServerRegister.dbd":
        pass
    else:
        orig_dbld(dbd, dbdpath, substitutions)

ioc.dbLoadDatabase = dbLoadDatabase

if __name__ == "__main__":
    ioc.main()

But obviously this is a hack.

Maybe the best way to support this is to pass in a list of tuples of (dbd, dbdpath) to epicscorelibs.ioc.main, defaulting to the existing qsrv.dbd and PVAServerRegister.dbd, and then call it with a different set in pvxslibs.ioc?

Shall I make a PR for this? Or is there a better way?

Seg fault if `PVXS_QSRV_ENABLE` not set

Describe the bug
If PVXS_QSRV_ENABLE env variable is not set, then in some situations the IOC seg faults on exit

To Reproduce
Steps to reproduce the behavior:

Save code from #49 into file
Comment out the env variable set
Run it
Ctrl-D
See it seg fault

Expected behavior
See it not seg fault

Information (please complete the following):

PVXS Version or Git commit ID: a02b6e9
EPICS Base Version: epicscorelibs==7.0.7.99.0.1
libevent Version: Whatever is bundled in the pvxslibs wheel
EPICS_HOST_ARCH: linux-x86_64
Host OS: Ubuntu 22.04

Logger set not working as expected

Not sure if I am using the logger API correctly, but following the documentation and looking in the code I have tried to do a simple test with the logger, as below:

    DEFINE_LOGGER(mylogger, "MyLogger");

    // all fine
    assert(mylogger.test(pvxs::Level::Debug) == false);
    assert(mylogger.test(pvxs::Level::Err) == true);

    // all fine, but logger doesn't exist - not throwing....
    logger_level_set("LoggerDoesNotExist", pvxs::Level::Debug);
    log_debug_printf(mylogger, "Should not show!!\n", 0);
    log_err_printf(mylogger, "Should show!!\n", 0);

    // does not work
    logger_level_set("MyLogger", pvxs::Level::Debug);
    log_debug_printf(mylogger, "Should show but doesn't!!\n", 0);

    // but this works
    assert(mylogger.test(pvxs::Level::Debug) == false);
    mylogger.lvl = pvxs::Level::Debug;
    assert(mylogger.test(pvxs::Level::Debug) == true);
    // awkward that I need to give an argument (0) since I format is not needed here.
    log_debug_printf(mylogger, "From MyLogger!!\n", 0);

My output is then:

2021-03-03T10:43:42.826120700 ERR MyLogger Should show!!
2021-03-03T10:43:42.826637000 DEBUG MyLogger From MyLogger!!

I did not set PVXS_LOG to see how the logger works without any environment variables.

Are there any unit tests for the logger that I can look at?

Any help on how to use the API for the logger would be appreciated.

Intermittent failure of `test1000`

Something I've noticed in recent months. I'm not sure exactly when this started. With some occurances there is an associated evbase self-joining error. I have yet to get a stack trace to see where the extra reference is being held.

   test1000.tap ..... 
  not ok 1001 - Instance leak ServerGPRConnect : 102
  not ok 1002 - Instance leak SharedPVImpl : 997
  not ok 1003 - Instance leak StructTop : 1103
  not ok 1004 - Instance leak UDPListener : 2
  not ok 1005 - Instance leak evbase : 2
  not ok 1006 - Instance leak evbaseRunning : 2

I suspect there is an actual regression behind this.

How to improve PVA put concurrency performance

Copied from epics-base/pvAccessCPP#188

I need to put lots of PV at the same time, which function I used is chan.put.set().exec()， but no matter how I use std::jthread or std::thread to achieve, it looks like always sequential execution at the bottom level. Is there a way to put the value without for waiting timeout?

Stable release

Not really an issue, more of an enquiry.

I've been looking at using pvData and pvAccess but don't want to start adopting something that is expected to be deprecated.
Am I correct in thinking PVXS is expected to supersede pvData and pvAccess in the near future? Can PVXS already be used in production?

Are you able to indicate when the API will become stable with an associated release?

ci-scripts submodule is using non-existing commit

Describe the bug

The commit in use by ci-scripts, https://github.com/mdavidsaver/ci-scripts/tree/a8bffdcfb73e7710662185d77e7cc0662a1deede , has a warning about not belonging to the repository, "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.", because it only exists in the epics-base repo: epics-base/ci-scripts@a8bffdc

Updating https://github.com/mdavidsaver/ci-scripts would be enough, but would it make sense to move to using the epics-base repo directly instead?

I noticed this because my local clone can't fetch the submodule's commit

pvget not returning anything when setting EPICS_PVA_ADDR_LIST and EPICS_PVA_AUTO_ADDR_LIST to NO

Describe the bug

Hi! Not sure if it's a bug, I'm not configuring something properly, or maybe just not implemented yet. But for some context, I'm attempting to update the version of P4P used at SLAC from 3.5.5 to a version 4.X (trying to go straight to 4.1.5 at the moment). When testing the update, we've noticed that existing P4P servers that are serving PVs from a machine just fine with 3.5.5 are no longer able to be communicated with from a different machine, and actually even from the same machine itself. It seems to be an issue with the underlying change to use pvxs, and I've narrowed it down to the simple reproducible case below:

To Reproduce

Steps to reproduce the behavior:

Build the latest pvxs from source using the directions here: https://mdavidsaver.github.io/pvxs/building.html
Set EPICS_PVA_ADDR_LIST to the IP address of the machine it is running on, and EPICS_PVA_AUTO_ADDR_LIST to NO
Run simple server from examples: ./example/O.linux-x86_64/simplesrv
From the same machine, run pvget my:pv:name
Timeout

Expected behavior
pvget should return the PV. (It does return correctly with the same EPICS_PVA_* configuration using P4P 3.5.5 or just the example from pvAccess module from epics-base)

Information (please complete the following):

Output of pvxinfo -D. (This is from RHEL7)


Host: linux-x86_64
Target: linux-x86_64 Linux gcc
Toolchain
    __cplusplus = 201103
    GCC 4.8.5
    GLIBC 2.17
    __GLIBCXX__ 20150623
Versions
    PVXS 1.1.0
    EPICS 7.0.7.1-DEV
    libevent 2.0.21-stable
Runtime
    uname() -> Linux poseidon 3.10.0-1160.71.1.el7.x86_64 #1 SMP Tue Jun 28 15:37:28 UTC 2022 x86_64
    epicsThreadGetCPUs() -> 4
    osiLocalAddr() -> 45.33.109.184
    osiSockDiscoverBroadcastAddresses() ->
        45.33.109.255
        172.17.255.255
        192.168.49.255
Effective Client config from environment
    EPICS_PVA_ADDR_LIST="45.33.109.184:5076"
    EPICS_PVA_AUTO_ADDR_LIST=NO
    EPICS_PVA_BROADCAST_PORT=5076
    EPICS_PVA_SERVER_PORT=5075
    EPICS_PVA_CONN_TMO=30
Effective Server config from environment
    EPICS_PVAS_INTF_ADDR_LIST="[::]"
    EPICS_PVAS_BEACON_ADDR_LIST="45.33.109.184:5076"
    EPICS_PVAS_IGNORE_ADDR_LIST=""
    EPICS_PVAS_AUTO_BEACON_ADDR_LIST=NO
    EPICS_PVAS_SERVER_PORT=5075
    EPICS_PVAS_BROADCAST_PORT=5076
    EPICS_PVA_CONN_TMO=30

Additional context

Running the server with PVXS_LOG=*=DEBUG shows debug output on server startup, but no debug output when a pvget is made. Can include other information and dig further if needed, but wanted to see if this was a known thing first.

Server startup debug output:


2022-12-14T09:21:09.361085154 DEBUG pvxs.iface refresh after 11300007.7 sec
2022-12-14T09:21:09.361684399 DEBUG pvxs.iface Ignoring interface 'lo' address family=17
2022-12-14T09:21:09.361763940 DEBUG pvxs.iface Ignoring interface 'eth0' address family=17
2022-12-14T09:21:09.361799600 DEBUG pvxs.iface Ignoring interface 'docker0' address family=17
2022-12-14T09:21:09.361826160 DEBUG pvxs.iface Ignoring interface 'br-67a3e997d373' address family=17
2022-12-14T09:21:09.361843200 DEBUG pvxs.iface Ignoring interface 'veth9ba2dc7' address family=17
2022-12-14T09:21:09.362425144 DEBUG pvxs.iface Found interface 1 "lo" w/ 2 127.0.0.1
2022-12-14T09:21:09.362503605 DEBUG pvxs.iface Found interface 2 "eth0" w/ 2 45.33.109.184
2022-12-14T09:21:09.362537445 DEBUG pvxs.iface Found interface 101480 "docker0" w/ 2 172.17.0.1
2022-12-14T09:21:09.362570106 DEBUG pvxs.iface Found interface 223161 "br-67a3e997d373" w/ 2 192.168.49.1
2022-12-14T09:21:09.362602936 DEBUG pvxs.iface Found interface 1 "lo" w/ 10 [::1]
2022-12-14T09:21:09.362644146 DEBUG pvxs.iface Found interface 2 "eth0" w/ 10 [2600:3c01::f03c:93ff:fe35:1c56]
2022-12-14T09:21:09.362679036 DEBUG pvxs.iface Found interface 2 "eth0" w/ 10 [fe80::f03c:93ff:fe35:1c56]%2
2022-12-14T09:21:09.362759117 DEBUG pvxs.iface Found interface 101480 "docker0" w/ 10 [fe80::42:3ff:fe99:c51d]%101480
2022-12-14T09:21:09.362797537 DEBUG pvxs.iface Found interface 223161 "br-67a3e997d373" w/ 10 [fe80::42:6dff:fe81:6b2a]%223161
2022-12-14T09:21:09.362831448 DEBUG pvxs.iface Found interface 223167 "veth9ba2dc7" w/ 10 [fe80::78f0:e3ff:fe41:b586]%223167
2022-12-14T09:21:09.364017096 INFO pvxs.loop Enter loop worker for 0x7f88000008f0 using epoll
2022-12-14T09:21:09.364110227 DEBUG pvxs.server.setup Promote 0.0.0.0 -> [::]
2022-12-14T09:21:09.364275378 INFO pvxs.loop Enter loop worker for 0x7f88040008f0 using epoll
2022-12-14T09:21:09.364506020 INFO pvxs.udp.setup Bound to UDP [::]:5076 as lo
2022-12-14T09:21:09.364545040 DEBUG pvxs.udp.setup Listening for SEARCH on [::]:5076
2022-12-14T09:21:09.364850613 DEBUG pvxs.server.setup Will send beacons to 45.33.109.184:5076
2022-12-14T09:21:09.365665459 DEBUG pvxs.server.setup Server Starting
2022-12-14T09:21:09.365721709 DEBUG pvxs.server.setup Server starting
2022-12-14T09:21:09.365757089 DEBUG pvxs.server.setup Server enabled listener on [::]:5075
2022-12-14T09:21:09.365808590 DEBUG pvxs.udp.setup Start listening for UDP [::]:5076
2022-12-14T09:21:09.365860740 DEBUG pvxs.server.setup Server beacon timer expires
2022-12-14T09:21:09.365923521 DEBUG pvxs.server.io Beacon tx to 45.33.109.184:5076
2022-12-14T09:21:09.365947781 DEBUG pvxs.udp.io UDP 0x7f8804001570 event 2
0000 : CA02C000 00000027 A4A02B72 BF7E74A2
0010 : 84B3596B 00000001 00000000 00000000
0020 : 0000FFFF 00000000 13D30374 6370FF
2022-12-14T09:21:09.366042661 DEBUG pvxs.udp.io UDP Rx 47, [::ffff:45.33.109.184]:47377 -> [::ffff:45.33.109.184]:5076 @1 ([::]:5076)

Debian needs libevent-dev instead of libevent2-dev

I couldn't find libevent2-dev [1] in Debian 10. Could you check it again?

[1] https://github.com/mdavidsaver/pvxs/blob/master/documentation/building.rst

ioc: add PVA link support

#37 added the the server part of IOC integration (aka. QSRV 2). The client side PVA link support still needs to be added.

Client Error while processing cmd 0x11

Describe the bug and steps to reproduce
Running ./example/O.linux-x86_64/mailbox topic1 and then running Control System Studio on CODAC 6.2.1. Enter pva://topic1 into PV Formula causes the following stack trace

Effective config
EPICS_PVAS_INTF_ADDR_LIST="0.0.0.0"
EPICS_PVAS_BEACON_ADDR_LIST="10.0.2.255:5076 10.0.2.255 192.168.122.255"
EPICS_PVAS_AUTO_BEACON_ADDR_LIST=NO
EPICS_PVAS_SERVER_PORT=5075
EPICS_PVAS_BROADCAST_PORT=5076
Running
2021-01-11T12:53:03.549084029 CRIT pvxs.tcp.io Client Error while processing cmd 0x11: Error decoding Introspect
Dumping a stack trace of thread 'PVXTCP':
[    0x7f9e16da843b]: /opt/codac-6.2/epics-base/lib/linux-x86_64/libCom.so.3.18.1(epicsStackTrace+0x4b)
[    0x7f9e16ff6b8a]: /opt/codac-6.2/pvxs/lib/linux-x86_64/libpvxs.so.0.1(_ZN4pvxs6detail11_log_printfEjPKcz+0xaa)
[    0x7f9e1704a259]: /opt/codac-6.2/pvxs/lib/linux-x86_64/libpvxs.so.0.1(_ZN4pvxs4impl8ConnBase7bevReadEv+0x769)
[    0x7f9e1705c1a9]: /opt/codac-6.2/pvxs/lib/linux-x86_64/libpvxs.so.0.1(_ZN4pvxs4impl10ServerConn7bevReadEv+0x9)
[    0x7f9e1704a4c1]: /opt/codac-6.2/pvxs/lib/linux-x86_64/libpvxs.so.0.1(_ZN4pvxs4impl8ConnBase8bevReadSEP11buffereventPv+0x21)
[    0x7f9e1626119c]: /opt/codac-6.2/pvxs/bundle/usr/linux-x86_64/lib/libevent_core-2.2.so.1(bufferevent_run_deferred_callbacks_locked+0x7c)
[    0x7f9e1626a0b8]: /opt/codac-6.2/pvxs/bundle/usr/linux-x86_64/lib/libevent_core-2.2.so.1(event_process_active_single_queue.isra.33+0x268)
[    0x7f9e1626a8af]: /opt/codac-6.2/pvxs/bundle/usr/linux-x86_64/lib/libevent_core-2.2.so.1(event_base_loop+0x3ff)
[    0x7f9e1703b739]: /opt/codac-6.2/pvxs/lib/linux-x86_64/libpvxs.so.0.1(_ZN4pvxs4impl6evbase3Pvt3runEv+0x109)
[    0x7f9e16d9c639]: /opt/codac-6.2/epics-base/lib/linux-x86_64/libCom.so.3.18.1(epicsThreadCallEntryPoint+0x69)
[    0x7f9e16da263c]: /opt/codac-6.2/epics-base/lib/linux-x86_64/libCom.so.3.18.1(start_routine+0xdc)
[    0x7f9e15e3ae25]: /lib64/libpthread.so.0(start_thread+0xc5)
[    0x7f9e1657834d]: /lib64/libc.so.6(clone+0x6d)
2021-01-11T12:53:06.631608105 CRIT pvxs.tcp.io Client Error while processing cmd 0x11: Error decoding Introspect
Dumping a stack trace of thread 'PVXTCP':
[    0x7f9e16da843b]: /opt/codac-6.2/epics-base/lib/linux-x86_64/libCom.so.3.18.1(epicsStackTrace+0x4b)
[    0x7f9e16ff6b8a]: /opt/codac-6.2/pvxs/lib/linux-x86_64/libpvxs.so.0.1(_ZN4pvxs6detail11_log_printfEjPKcz+0xaa)
[    0x7f9e1704a259]: /opt/codac-6.2/pvxs/lib/linux-x86_64/libpvxs.so.0.1(_ZN4pvxs4impl8ConnBase7bevReadEv+0x769)
^C[    0x7f9e1705c1a9]: /opt/codac-6.2/pvxs/lib/linux-x86_64/libpvxs.so.0.1(_ZN4pvxs4impl10ServerConn7bevReadEv+0x9)
[    0x7f9e1704a4c1]: /opt/codac-6.2/pvxs/lib/linux-x86_64/libpvxs.so.0.1(_ZN4pvxs4impl8ConnBase8bevReadSEP11buffereventPv+0x21)
[    0x7f9e1626119c]: /opt/codac-6.2/pvxs/bundle/usr/linux-x86_64/lib/libevent_core-2.2.so.1(bufferevent_run_deferred_callbacks_locked+0x7c)
[    0x7f9e1626a0b8]: /opt/codac-6.2/pvxs/bundle/usr/linux-x86_64/lib/libevent_core-2.2.so.1(event_process_active_single_queue.isra.33+0x268)
[    0x7f9e1626a8af]: /opt/codac-6.2/pvxs/bundle/usr/linux-x86_64/lib/libevent_core-2.2.so.1(event_base_loop+0x3ff)
[    0x7f9e1703b739]: /opt/codac-6.2/pvxs/lib/linux-x86_64/libpvxs.so.0.1(_ZN4pvxs4impl6evbase3Pvt3runEv+0x109)
[    0x7f9e16d9c639]: /opt/codac-6.2/epics-base/lib/linux-x86_64/libCom.so.3.18.1(epicsThreadCallEntryPoint+0x69)

Expected behavior
A clear and concise description of what you expected to happen.
No stack trace, get some values to CSS.

Information (please complete the following):

╰─ ./pvxinfo -D
Host: linux-x86_64
Target: linux-x86_64 Linux gcc
Toolchain
    __cplusplus = 201103
    GCC 4.8.5
    GLIBC 2.17
    __GLIBCXX__ 20150623
Versions
    PVXS 0.1.1 (0.1.0-20-g26cf7f00e607b6f5383f-dirty)
    EPICS 7.0.4.1-DEV
    libevent 2.2.0-alpha-dev
Runtime
    uname() -> Linux karlosp.codac-dev 3.10.0-693.2.1.el7.x86_64 #1 SMP Fri Aug 11 04:58:43 EDT 2017 x86_64
    epicsThreadGetCPUs() -> 7
    osiLocalAddr() -> 10.0.2.15
    osiSockDiscoverBroadcastAddresses() ->
        10.0.2.255
        192.168.122.255
Effective Client config from environment
    EPICS_PVA_ADDR_LIST="10.0.2.255:5076 10.0.2.255 192.168.122.255"
    EPICS_PVA_AUTO_ADDR_LIST=NO
    EPICS_PVA_BROADCAST_PORT=5076
Effective Server config from environment
    EPICS_PVAS_INTF_ADDR_LIST="0.0.0.0"
    EPICS_PVAS_BEACON_ADDR_LIST="10.0.2.255:5076 10.0.2.255 192.168.122.255"
    EPICS_PVAS_AUTO_BEACON_ADDR_LIST=NO
    EPICS_PVAS_SERVER_PORT=5075
    EPICS_PVAS_BROADCAST_PORT=5076

PREC from DB isn't reported correctly.

Describe the bug

An ao value in an IOC database doesn't report its precision correctly (or at all?) when using the PVXS server.

To Reproduce
Steps to reproduce the behavior:

Create ao record with field(PREC, 3)
Confirm precision is set correctly with caget -d CTRL_DOUBLE: Precision: 3
Check that display.precision field exists in pvinfo output
Try and get display.precision field with pvget or p4p (for the latter, precision is reported as 0, even)

Care was taken to ensure the access wasn't happening through p4pgw, to eliminate the chance of it causing the issue.

caget -d CTRL_DOUBLE full output:

caget -d CTRL_DOUBLE DE-23SL11:BS-FOFBCtrl:SYSIDUpdateTime-SP
DE-23SL11:BS-FOFBCtrl:SYSIDUpdateTime-SP
    Native data type: DBF_DOUBLE
    Request type:     DBR_CTRL_DOUBLE
    Element count:    1
    Value:            0.001
    Status:           NO_ALARM
    Severity:         NO_ALARM
    Units:            s
    Precision:        3
    Lo disp limit:    0
    Hi disp limit:    0
    Lo alarm limit:   nan
    Lo warn limit:    nan
    Hi warn limit:    nan
    Hi alarm limit:   nan
    Lo ctrl limit:    0.001
    Hi ctrl limit:    100

pvinfo:

EPICS_PVA_ADDR_LIST=de-23rabpm-co-iocsrv EPICS_PVA_AUTO_ADDR_LIST=NO pvinfo DE-23SL11:BS-FOFBCtrl:LAMPUpdateTime-SP            (hla2)
DE-23SL11:BS-FOFBCtrl:LAMPUpdateTime-SP
Server: 10.20.26.110:41676
Type:
    epics:nt/NTScalar:1.0
        double value
        alarm_t alarm
            int severity
            int status
            string message
        time_t timeStamp
            long secondsPastEpoch
            int nanoseconds
            int userTag
        structure display
            double limitLow
            double limitHigh
            string description
            string units
            int precision
            enum_t form
                int index
                string[] choices
        structure control
            double limitLow
            double limitHigh
            double minStep
        structure valueAlarm
            boolean active
            double lowAlarmLimit
            double lowWarningLimit
            double highWarningLimit
            double highAlarmLimit
            int lowAlarmSeverity
            int lowWarningSeverity
            int highWarningSeverity
            int highAlarmSeverity
            double hysteresis

pvget -M raw:

EPICS_PVA_ADDR_LIST=de-23rabpm-co-iocsrv EPICS_PVA_AUTO_ADDR_LIST=NO pvget -M raw DE-23SL11:BS-FOFBCtrl:LAMPUpdateTime-SP      (hla2)
DE-23SL11:BS-FOFBCtrl:LAMPUpdateTime-SP epics:nt/NTScalar:1.0
    double value 0.001
    alarm_t alarm
        int severity 0
        int status 0
        string message
    time_t timeStamp 2023-08-21 12:54:18.502
        long secondsPastEpoch 1692633258
        int nanoseconds 502497987
        int userTag 0
    structure display
        double limitLow 0
        double limitHigh 0
        string description "Set repetitive mode update time"
        string units s
        enum_t form (0) Default
            int index 0
            string[] choices [Default, String, Binary, Decimal, Hex, Exponential, Engineering]
    structure control
        double limitLow 0.001
        double limitHigh 100
    structure valueAlarm
        double lowAlarmLimit nan
        double lowWarningLimit nan
        double highWarningLimit nan
        double highAlarmLimit nan

pvget -M raw -r display.precision:

EPICS_PVA_ADDR_LIST=de-23rabpm-co-iocsrv EPICS_PVA_AUTO_ADDR_LIST=NO pvget -M raw -r display.precision DE-23SL11:BS-FOFBCtrl:LAMPUpdateTime-SP
DE-23SL11:BS-FOFBCtrl:LAMPUpdateTime-SP ⏎

p4p:

In [15]: c = Context(nt=False)

In [16]: m = c.get(name="DE-23SL11:BS-FOFBCtrl:LAMPUpdateTime-SP")

In [17]: m.tolist()
Out[17]:
[('value', 0.001),
 ('alarm', [('severity', 0), ('status', 0), ('message', '')]),
 ('timeStamp',
  [('secondsPastEpoch', 1692633258),
   ('nanoseconds', 502497987),
   ('userTag', 0)]),
 ('display',
  [('limitLow', 0.0),
   ('limitHigh', 0.0),
   ('description', 'Set repetitive mode update time'),
   ('units', 's'),
   ('precision', 0),
   ('form',
    [('index', 0),
     ('choices',
      ['Default',
       'String',
       'Binary',
       'Decimal',
       'Hex',
       'Exponential',
       'Engineering'])])]),
 ('control', [('limitLow', 0.001), ('limitHigh', 100.0), ('minStep', 0.0)]),
 ('valueAlarm',
  [('active', False),
   ('lowAlarmLimit', nan),
   ('lowWarningLimit', nan),
   ('highWarningLimit', nan),
   ('highAlarmLimit', nan),
   ('lowAlarmSeverity', 0),
   ('lowWarningSeverity', 0),
   ('highWarningSeverity', 0),
   ('highAlarmSeverity', 0),
   ('hysteresis', 0.0)])]

Expected behavior
A clear and concise description of what you expected to happen.

Information (please complete the following):

PVXS Version or Git commit ID: 064a1f6
EPICS Base Version: 7.0.7+git (524f81b8bd147bb714c9ea7b7462b8912a134246) + local changes to allow full static linking

Alternately, from a successful build, include the output of pvxinfo -D.

Host: linux-x86_64
Target: linux-x86_64 Linux gcc
Toolchain
    __cplusplus = 201103
    GCC 12.2.0
    _GLIBCXX_USE_CXX11_ABI = 1
    __GLIBCXX__ 20220819
Versions
    PVXS 1.2.2 ()
    EPICS 7.0.7.1-DEV
    libevent 2.1.12-stable
Runtime
    uname() -> Linux S-SWC03-L 5.19.0-50-generic #50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 10 18:24:29 UTC 2023 x86_64
    epicsThreadGetCPUs() -> 8
    osiLocalAddr() -> 10.15.2.110

Additional context

This problem was noticed when using a pydm interface with pva://, where the spinbox controls worked thanks to DRVH and DRVL set in the database, but didn't allow decimal values.

mdavidsaver / pvxs Goto Github PK

pvxs's Introduction

PVXS - PVAccess protocol library

pvxs's People

Contributors

Stargazers

Watchers

Forkers

pvxs's Issues

Recommend Projects

Recommend Topics

Recommend Org