Experimental Physics and
Industrial Control System

"Zimoch Dirk \(PSI\) via Core-talk" <core-talk at aps.anl.gov> · Mon, 22 Nov 2021 14:35:18 +0000

Repeating the tests, I found some that fail on vxWorks.
 I think I collect them in a bug tracker issue...

> -----Ursprüngliche Nachricht-----
> Von: Zimoch Dirk (PSI)
> Gesendet: Freitag, 19. November 2021 15:05
> An: 'Michael Davidsaver' <mdavidsaver at gmail.com>
> Cc: 'core-talk at aps.anl.gov' <core-talk at aps.anl.gov>
> Betreff: AW: Strange UDP message on VxWorks 6.9
> 
> I cross-checked with printf and found that the 47 is indeed hex!
> 
> I also found that the FIRST message is:
> Error on UDP RX 172.20.4.26:57620 -> 172.20.255.255:5076 at 71 : no more
> data in UDP packet : 71:71 for 1
> 
> But all the next messages are:
> Error on UDP RX 172.20.2.154:49166 -> 172.20.255.255:5076 at 47 : no more
> data in UDP packet : 71:71 for 1
> 
> The reason is HexDump operator << which switches the output stream to hex
> and leaves it like that.
> 
> 
> 
> I have run tests for libCom, pvData and pvAccess and they succeed.
> BTW: Some other tests harnesses require dbd files like linkTest.dbd that do not
> get installed (even though the *Harness.munch files are installed).
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Zimoch Dirk (PSI)
> > Gesendet: Freitag, 19. November 2021 09:56
> > An: 'Michael Davidsaver' <mdavidsaver at gmail.com>
> > Cc: 'core-talk at aps.anl.gov' <core-talk at aps.anl.gov>
> > Betreff: AW: Strange UDP message on VxWorks 6.9
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Michael Davidsaver <mdavidsaver at gmail.com>
> > > Gesendet: Donnerstag, 18. November 2021 17:30
> > > An: Zimoch Dirk (PSI) <dirk.zimoch at psi.ch>
> > > Cc: 'core-talk at aps.anl.gov' <core-talk at aps.anl.gov>
> > > Betreff: Re: Strange UDP message on VxWorks 6.9
> > >
> > > Dirk,
> > >
> > > Have you run the unit tests for Base, pvDataCPP, and pvAccessCPP?
> >
> > Not on vxWorks.
> >
> > >
> > >
> > > On 11/18/21 6:08 AM, Zimoch Dirk (PSI) via Core-talk wrote:
> > > > Hi everybody
> > > >
> > > > For a while, I have EPICS 7.0.6.1 running on some vxWorks 6.7 IOCs. Now I
> > > upgraded one of them to vxWorks 6.9 and get those strange errors:
> > > >
> > > > Error on UDP RX 172.20.4.25:48599 -> 172.20.255.255:5076 at 47 : no
> more
> > > data in UDP packet : 71:71 for 1
> > > > 0x00 ca024000 27000000 73599561 00000000  ..@. '... sY.a ....
> > > > 0x10 68ab0e1c 00680000 00000000 00000000  h... .h.. .... ....
> > > > 0x20 0000ffff 00000000 3edd0374 6370ff    .... .... >..t cp.
> > > ...
> > > > I found the messages to pvAccess/src/remote/blockingUDPTransport.c,
> but
> > it
> > > is hard to understand what it means or why it appears on vxWorks 6.9 but
> not
> > > vxWorks 6.7.
> > >
> > > I can't explain this.
> > >
> > > This looks like a valid CMD_BEACON packet (see below), which is also
> implied
> > by
> > > silence from other PVA peers which presumably see this broadcast.
> > >
> > > In particular, I don't see how "71" appears.  The message length is 47 bytes
> > > (0x27 body + 8 header).  The fact that 0x47 == 71 is suggestive, but I don't
> > > see where this confusion could be sneaking in.
> > >
> > > It also isn't clear to me if this is simply when printing the message, or when
> > > interpreting the packet.
> > >
> > > The order of formatting is such that "no more data in UDP packet : 71:71 for
> > 1"
> > > is constructed first using a temporary std::ostringstream.  So I have
> confidence
> > > that this stream _should_ be set to base 10.
> > >
> > > The rest of the message is formatted using std::cerr, so it is possible that the
> > > "47" is base 16.
> >
> > I can check that by using printf. Just to be sure.
> > I find it difficult to debug because I do not know which function has originally
> > called the function that throws the exception. Maybe I abort() rather than
> throw
> > and have a look at the call stack.
> >
> > >
> > > I'm afraid I don't have any suggestion beyond ensuring that there isn't any
> > > mixing
> > > of object code compiled for vx6.7 vs 6.9.
> >
> > There isn't. Otherwise this would most probably not be the only problem.
> >
> > >
> > >
> > > > It may be that I configured something wrong on vxWorks 6.9 as I had to
> > > migrate the BSP for the no longer supported architecture from 6.7 to 6.9 and
> > > had difficulties to get networking running initially.
> > > > But networking works now and neither CA nor PVA nor NFS show any
> > > problems.
> > > >
> > > > Any ideas? [Looking in Michael's direction]
> > > >
> > > > Dirk
> > > >
> > >
> > >
> > >
> > > > 0x00 ca024000 27000000
> > >
> > > version=2 CMD_BEACON LSB length=0x27 (39 bytes)
> > > total message length including header is 47 bytes
> > >
> > > https://github.com/epics-base/pvAccessCPP/wiki/Protocol-
> > Messages#message-
> > > header
> > >
> > > https://github.com/epics-base/pvAccessCPP/wiki/Protocol-
> > > Messages#cmd_beacon-0x00
> > >
> > > >    73599561 00000000
> > > > 0x10 68ab0e1c
> > >
> > > GUID 0x735995610000000068ab0e1c
> > > This is consistent w/ pvAccessCPP/Java which use system boot time
> > > as a "unique" ID...
> > > 0x61955973 -> Wed Nov 17 11:35:15 2021 PST
> > >
> > > >    00680000
> > >
> > > flags=0 beaconSequenceId=0x68 changeCount=0
> > >
> > > >    00000000 00000000
> > > > 0x20 0000ffff 00000000
> > >
> > > server adddress is ::ffff:0.0.0.0
> > > which is expected
> > >
> > > >  3edd
> > >
> > > port=56638
> > >
> > > >  0374 6370
> > >
> > > 3 byte string "tcp"
> > >
> > > >  ff
> > >
> > > PVD NULL, which again is allowed

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System