Experimental Physics and
Industrial Control System

Hi Michael,

After putting a lot of debug messages into the code, I found the big difference between vxWorks 6.9.0 on ppc604 and all the other architectures:  signedness of int8 aka char!

As a result, FieldCreate::deserialize takes a different path with the same input (beacon):
    int8 code = buffer->getByte();
On vxWorks 6.7 and Linux, code is -1, but on vxWorks 6.9, code is 255.
Thus, the next line does not work as expected
    if (code == -1)
        return FieldConstPtr();
Instead, an array field is assumed but there is not enough data for that.

The type definitions come from here:
include/pv/pvType.h:typedef int8_t   int8;
$WINDBASE/vxworks-6.9/target/h/stdint.h:typedef char int8_t;

Thus, if char is unsigned, then int8_t is unsigned too and as a consequence int8 as well. This is obviously a bug in vxWorks, as the stdint.h man page says:

"The  typedef  name  int  N _t designates a signed integer type with width N, no padding bits, and a two's-complement representation. Thus, int8_t denotes a  signed integer type with a width of exactly 8 bits."

WindRiver should better have used 'typedef signed char int8_t;' as they had in vxWorks 6.7! (As well as any Linux implementation I checked.)
Can someone please check if they have fixed this in higher vxWorks 6.9 releases?

I have added the compiler flag -fsigned-char to ARCH_DEP_CFLAGS for vxWorks 6.9 and that fixes the problem.

Dirk

> -----Ursprüngliche Nachricht-----
> Von: Core-talk <core-talk-bounces at aps.anl.gov> Im Auftrag von Zimoch Dirk
> (PSI) via Core-talk
> Gesendet: Montag, 22. November 2021 15:35
> 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
>
> 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