#102 eget segfaults when fully qualified URI used for RPC style PV

[Greg White]

[4.4.0-pre2 CPP client, on linux-x86]

Summary:
eget segfaults when fully qualified URI used for RPC style PV.

Best explained by example:
$ eget pva://lcls-dev2.slac.stanford.edu:47257/qm14:twiss?
Segmentation fault

(note, above example is a valid RPC query with no arguments)

Example of RPC query with arguments:
$ eget "pva://lcls-dev2:47257/archiveservice?entity=quad45:bdes/history&starttime=2011-09-16T02.12.00&endtime=2011-09-16T15.23.17"
Segmentation fault

Whereas partial URI form works as expected:
$ eget pva:///qm14:twiss?
non-normative type
structure
double energy 0.22
double psix 20.8572
double alphax 29.3321
... (more output omitted)

$ eget "pva:///archiveservice?entity=quad45:bdes/history&starttime=2011-09-16T02.12.00&endtime=2011-09-16T15.23.17"
sampled time sampled value
Fri Sep 16 02:12:56 PDT 2011 42.2
Fri Sep 16 04:34:03 PDT 2011 2.76
Fri Sep 16 06:08:41 PDT 2011 45.3
Fri Sep 16 08:34:42 PDT 2011 85.3245
Fri Sep 16 10:01:02 PDT 2011 35.234
Fri Sep 16 12:03:42 PDT 2011 4.2345

(the above example is from a test archive service - not the V4 distributed one)

Non URI form also works as expected:
$ eget -s qm14:twiss
non-normative type
structure
double energy 0.22
double psix 20.8572
double alphax 29.3321
...(more output omitted)

[Matej Sekoranja]

URI is parsed successfully in both cases, the problem must be somewhere else.
Can you try running eget with "-d" so that I can see what's going on (I cannot connect to SLAC servers).

[Greg White]

-d gives interesting reading, the connection is being refused!

[greg@lcls-dev2 meme]$ printenv EPICS_PVA_ADDR_LIST
lcls-prod01.slac.stanford.edu mcc-dmz.slac.stanford.edu lcls-dev2.slac.stanford.edu:47257 lcls-dev2.slac.stanford.edu:47259 lcls-dev2.slac.stanford.edu:47258

[greg@lcls-dev2 meme]$ eget -d pva://lcls-dev2.slac.stanford.edu:47257/qm14:twiss? |
tee doutput.tmp

$ more doutput.tmp
Request structure:
epics:nt/NTURI:1.0
string scheme pva
string authority lcls-dev2.slac.stanford.edu:47257
string path qm14:twiss
structure query

2014-11-13T13:53:47.525 Client security plug-in 'ca' installed.
2014-11-13T13:53:47.528 Broadcast address #0: 134.79.151.21:5076.
2014-11-13T13:53:47.528 Broadcast address #1: 134.79.151.11:5076.
2014-11-13T13:53:47.528 Broadcast address #2: 134.79.219.12:47257.
2014-11-13T13:53:47.528 Broadcast address #3: 134.79.219.12:47259.
2014-11-13T13:53:47.528 Broadcast address #4: 134.79.219.12:47258.
2014-11-13T13:53:47.528 Broadcast address #5: 255.255.255.255:5076.
2014-11-13T13:53:47.528 Creating datagram socket to: 0.0.0.0:5076.
2014-11-13T13:53:47.528 Creating datagram socket to: 0.0.0.0:0.
2014-11-13T13:53:47.529 Connecting to PVA server: 134.79.219.12:47257.
2014-11-13T13:53:47.529 Opening socket to PVA server 134.79.219.12:47257, attempt 1.
2014-11-13T13:53:47.529 Socket connect error: Connection refused.
2014-11-13T13:53:47.529 Opening socket to PVA server Connection refused, attempt 2.
2014-11-13T13:53:47.529 Socket connect error: Connection refused.
2014-11-13T13:53:47.529 Opening socket to PVA server Connection refused, attempt 3.
2014-11-13T13:53:47.529 Socket connect error: Connection refused.
2014-11-13T13:53:47.529 Connection to PVA server 134.79.219.12:47257 failed.
...
Above 8 lines then repeat many times.

---

Note the same behavior happens with EPICS_PVA_ADDR_LIST set to empty:

[greg@lcls-dev2 meme]$ export EPICS_PVA_ADDR_LIST=
[greg@lcls-dev2 meme]$ eget -d pva://lcls-dev2.slac.stanford.edu:47257/qm14:twiss? | tee doutput2.tmp
[greg@lcls-dev2 meme]$ more doutput2.tmp
Request structure:
epics:nt/NTURI:1.0
string scheme pva
string authority lcls-dev2.slac.stanford.edu:47257
string path qm14:twiss
structure query

2014-11-13T13:56:30.448 Client security plug-in 'ca' installed.
2014-11-13T13:56:30.448 Broadcast address #0: 255.255.255.255:5076.
2014-11-13T13:56:30.448 Creating datagram socket to: 0.0.0.0:5076.
2014-11-13T13:56:30.448 Creating datagram socket to: 0.0.0.0:0.
2014-11-13T13:56:30.449 Connecting to PVA server: 134.79.219.12:47257.
2014-11-13T13:56:30.449 Opening socket to PVA server 134.79.219.12:47257, attempt 1.
2014-11-13T13:56:30.449 Socket connect error: Connection refused.
2014-11-13T13:56:30.449 Opening socket to PVA server Connection refused, attempt 2.
2014-11-13T13:56:30.449 Socket connect error: Connection refused.
2014-11-13T13:56:30.449 Opening socket to PVA server Connection refused, attempt 3.
2014-11-13T13:56:30.449 Socket connect error: Connection refused.

[Matej Sekoranja]

Hmmm... can you try pvlist (with EPICS_PVA_ENV set and without)?

[Matej Sekoranja]

Reasons for connection refused:

• server not listening at given address (pvlist will reveal this)
• firewall (can also be local)

[Greg White]

What's EPICS_PVA_ENV? What should I set it to (or not)

[Matej Sekoranja]

Surry, I meant EPICS_PVA_ADDR_LIST.

ps using EPICS_PVA_ADDR_LIST pointing to the local computer and running a client and a server locally needs a local multicast done by the client too (not only by the server). This will be implemented by the rc1.

[Greg White]

ps using EPICS_PVA_ADDR_LIST pointing to the local computer and running a client and a server locally needs a local multicast done by the client too (not only by the server).

The bad behavior is the same whether the client is on a different computer or not. I thought of that and tried it, but the client still couldn't connect. Maybe your comment that the configs are wrong can fi it, but I don't know the proper config. Can you help me? Maybe a hangout?

This will be implemented by the rc1.

Hm, thought we were supposed to be in code freeze?

[Matej Sekoranja]

Your configuration/request ports are wrong. Ports that are used in EPICS_PVA_ADDR_LIST (and EPICS_CA_ADDR_LIST) are UDP search ports.
The address (and port) given in URI is a server TCP port. They are different.

[Greg White]

Sorry Matej, I don't know what this means. The configuration I'm using has been fine for a year using 4.3. Can you give me an example?

[Matej Sekoranja]

In addition, can you do a

gcc --version

on machines you cannot access.
Does pvlist find servers you cannot access?

[Greg White]

[Note that the client and the server are the same machine]

In addition, can you do a
gcc --version

[greg@lcls-dev2 script]$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

on machines you cannot access.
Does pvlist find servers you cannot access?

With export EPICS_PVA_ADDR_LIST= [ie empty]
[greg@lcls-dev2 meme]$ pvinfo lcls-dev2.slac.stanford.edu:47257
[lcls-dev2.slac.stanford.edu:47257] connection timeout
[greg@lcls-dev2 meme]$ pvlist
(no output)

Now with non-empty EPICS_PVA_ADDR_LIST
[greg@lcls-dev2 meme]$ export EPICS_PVA_ADDR_LIST='lcls-dev2.slac.stanford.edu:47257'
[greg@lcls-dev2 meme]$ plist
GUID 0xA2A7995D13AD478390D1B60D, version 1: tcp@[134.79.219.12:48356]
[greg@lcls-dev2 meme]$ pvinfo lcls-dev2.slac.stanford.edu:47257
[lcls-dev2.slac.stanford.edu:47257] connection timeout
[greg@lcls-dev2 meme]$ pvinfo 0xA2A7995D13AD478390D1B60D
[0xA2A7995D13AD478390D1B60D] connection timeout

(interesting eh!).

[Matej Sekoranja]

pvinfo expects PV name
pvlist -i <GUID> or <server address> will give server info

[Matej Sekoranja]

The problem was (documented in code) when non-reachable explicit address was given to connect to a channel. The code ran out of stack space. Fixed.