Sending zero length search request causes infinite loop in casDGClient::processDG()
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EPICS Base |
Fix Released
|
Medium
|
Unassigned | ||
3.14 |
Fix Released
|
Medium
|
Ralph Lange | ||
3.15 |
Fix Released
|
Medium
|
Ralph Lange | ||
3.16 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Reported by Shuei YAMADA shuei.yamada_
Last april I posted to tech-talk an problem that cagateway runs away
on rare occasions (https:/
I successfully reproduced the problem by UDP-port scan with nmap.
When I run nmap as following:
nmap -sU -p 5064 -A ip.address.
- all PVs subscribing via cagateway become disconnected,
- cagateway is eating up the CPU,
- no distinguishable log messege, no "zero length PV name in UDP
search request?" either,
- excas shows the same simptom.
There is no way to exiting the the while() loop in
casDGClient:
block with a condition such that:
- this->in.
S_cas_success.
We are using base R3.14.12.3 for production and R3.15.5 for evaluation
at our site and both have the problem. Also R3.14.12.7 and R3.16.1
seem to have the same problem. Please find a naiive fix for this in
the attachment.
Changed in epics-base: | |
assignee: | nobody → Ralph Lange (ralph-lange) |
no longer affects: | epics-base/7.0 |
Changed in epics-base: | |
importance: | Undecided → Medium |
status: | Invalid → In Progress |
tags: | added: cas |
Changed in epics-base: | |
status: | In Progress → Fix Committed |
Changed in epics-base: | |
status: | Fix Committed → Fix Released |
For EPICS 7: fix released in the PCAS module per release 4.13.2 /github. com/epics- modules/ pcas/releases/ tag/v4. 13.2)
(https:/