A short message could underflow, leaving a too old client stuck
in a tar pit. An acceptable outcome, but not intended.
Instead, send back errors to each message.
The DBF_UINT64 case dereferenced the 8-byte field as *(epicsUInt32 *),
reading only its low 32 bits, so large UINT64 values printed wrong
(e.g. 0x1_0000_0000 as "0") and save/restore round-tripping broke. Cast
to epicsUInt64*, matching the adjacent DBF_INT64 case.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The used-bytes count is nextPut - nextGet everywhere else in this file
(epicsRingBytesPut, epicsRingBytesUsedBytes), but
epicsRingBytesResetHighWaterMark computed nextGet - nextPut. For a ring
holding u bytes it therefore stored size-u; since Put only raises the
mark, the high-water mark stayed permanently inflated and wrong.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The bin-search loop in add_count() assumes nelm*wdth == ulim-llim, but
wdth is a rounded quotient so nelm*wdth can be strictly less than
ulim-llim. A SGNL value just below ULIM then leaves the loop with
i == nelm+1, and pdest = bptr + nelm writes one epicsUInt32 past the
nelm-element buffer. This is reachable over Channel Access by putting a
value near ULIM to the SGNL field (special SPC_MOD). Clamp the index to
nelm.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The beacon-period gate in online_notify already rejected a parse
failure and a non-positive value, but epicsScanDouble parses "nan" and
"inf", and maxPeriod<=0.0 is false for both, so a non-finite period
reached the beacon delay loop. A NaN maxdelay makes delay<maxdelay
false forever, pinning the beacon interval at the 0.02 s startup value
- a ~50 Hz beacon flood on every configured interface; an infinite
maxdelay lets the doubling delay grow without bound, silencing beacons
entirely.
Gate on finite() (from epicsMath.h), matching the client-side
EPICS_CA_MAX_SEARCH_PERIOD handling in udpiiu.cpp, and name the actual
problem in the diagnostic instead of "float fetch failed" (the message
already covered the non-positive case, which is not a fetch failure).
INPM..INPU each declared special(SPC_MOD), but calcRecord's special()
only implements SPC_CALC and returns S_db_badChoice for anything else.
Every dbPutField/caput to one of those nine link fields therefore ran
special(after=TRUE), hit the fall-through, and failed with
S_db_badChoice ("bad special value") -- nine documented input links
were unwritable at run time.
The twelve sibling links INPA..INPL carry no special and accept writes,
and calcRecord (unlike calcoutRecord) does no run-time link
re-initialization, so there is no handler for SPC_MOD to reach. Remove
the erroneous attribute from the nine fields so they match INPA..INPL;
special() then runs only for CALC, which is the only field that still
carries a special.
epicsScanDouble accepts "inf" and "nan", so envGetDoubleConfigParam
returns success for them and the parsed value flows into getMaxPeriod's
only range gate, maxPeriod < maxSearchPeriodLowerLimit. That comparison
is false for both inf and NaN, so a non-finite period reaches
getNTimers(), whose static_cast<unsigned> of 1 + log(maxPeriod/...)/log2
is an undefined float->unsigned conversion: inf aborts the client in
malloc via a garbage nTimers allocation, and NaN drives the search-timer
wheel off a NaN period where every deadline comparison is false.
Gate the parsed value on finite() (from epicsMath.h) and positivity
alongside the parse status, and fall back to the default period. A
non-positive period is not a "low" period to be clamped up to the 60 s
lower limit; it takes the same invalid-input path as inf/NaN.
getMaxPeriod() is getNTimers()'s only caller, so this makes the
conversion finite and positive by construction.
A successful parse of EPICS_CA_CONN_TMO stored the value into connTMO
unchecked, so EPICS_CA_CONN_TMO=-5 or =0 left the connection-verify
watchdog deadline permanently in the past. The watchdog then fires
continuously, flooding stderr with "Virtual circuit unresponsive" and
pinning a CPU while updates still arrive. NaN and inf (which
epicsScanDouble also accepts) slip past any ordering comparison: a NaN
period leaves the watchdog deadline arithmetic undefined, and an
infinite period silently disables circuit verification.
Fold the validity check into the existing parse-failure branch, so an
unparsable, non-finite, or non-positive value takes the same path:
warn once and fall back to the 30 s CA_CONN_VERIFY_PERIOD default.
This mirrors the sibling EPICS_CA_MAX_ARRAY_BYTES handling a few lines
below, which already gates a parse failure and an out-of-range value
in one condition, and matches the finite() gate on
EPICS_CA_MAX_SEARCH_PERIOD in udpiiu.cpp.
In the long-string (%ls) branch dbGetLink(DBR_CHAR) / dbLoadLinkLS can
leave n at vspace+1, so pval[n] = 0 writes at pval[vspace+1], one byte
past the sizv-byte VAL buffer (pval + vspace + 1 == prec->val + sizv).
Clamp n to vspace immediately before writing the terminator.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
epicsParseDouble returns 0 on success and non-zero on failure, but the
branches were swapped: a valid delay printed "Invalid 'on error wait'
delay" and the usage text, while an invalid delay was silently accepted
with timeout forced to 5.0. Report the error on parse failure and accept
the value on success.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
putUInt64String used cvtUlongToString, which is cvtUInt32ToString, so the
64-bit source was narrowed to its low 32 bits (e.g. 0x1_0000_0007 printed
as "7"). Use cvtUInt64ToString, matching getUInt64String and every other
width-specific putXxxString.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
get_graphic_double() assigns lower_disp_limit twice and never writes
upper_disp_limit, so a DBR_GR_DOUBLE read of any DLYn field reports
the inverted range lower=10, upper=0. The second assignment was
evidently meant for the upper limit; the 0 in the upper slot is the
zeroed buffer dbAccess.c hands to the RSET, not a chosen value.
Both assignments date from commit 27e80be2e5 which introduced the
DLYn limits, so every release since 3.14.11 reports the inverted
range over both CA (DBR_GR/CTRL) and PVA (display.limitLow/High).
Extend seqTest with a DBR_GR_DOUBLE read of DLY0; the new cases
fail with lower=10, upper=0 before this fix.
The guard used recname[0] = '\0' (assignment) instead of == , which wrote
a NUL into the caller's string, truncating it to "", and evaluated to 0
so recname was left non-NULL pointing at "". Every record then failed
the name comparison and nothing was mapped. Use ==, matching dbjlr.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
get_precision() walks pvalue and plvalue over the A-L and LA-LL fields,
then compares paddr->pfield against &pvalue and &plvalue -- the
addresses of the two local pointer variables, not of the fields they
point at. Those are stack addresses, so neither test has ever matched
and every A-L or LA-LL precision request falls through to
recGblGetPrec(). The line just above gets it right: prec->val is a
field and needs the &, whereas pvalue and plvalue are already pointers.
Both tests date from e87551df24, the commit that added the loop, and
have been dead ever since, so every release since R3.12 has this. They
carried a (void *) cast until 6d85a36397 removed it, which is why the
compiler was never shown a double ** to complain about. That the
fields were meant to be covered is not in doubt: this record's
get_graphic_double() and get_control_double() both name A-L and LA-LL.
This changes what those fields report. recGblGetPrec() substitutes 15
for a DOUBLE precision outside 0 to 15, so today A-L and LA-LL answer
15 for a PREC of 17 while VAL answers 17. They now answer PREC
unclamped, which is what VAL has always done.
Add selTest, reading the precision of VAL, A, L, LA, LL and HIHI from a
record with PREC=17. The four A-L and LA-LL cases report 15 before
this fix; VAL and HIHI pin the two paths either side of them.
errlogBufResize copied the print buffer from &pvt.print->base (the
address of the char* field inside the buffer_t struct) instead of
pvt.print->base (the buffer it points to), reading bufSize bytes from an
~8-byte struct field. Drop the stray & so it reads the actual buffer,
matching the adjacent log-buffer copy.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The ca_repeater function has some failure cases which can cause it to
return. In such a situation, a reference to the current thread's
epicsThreadId is kept in the taskwd, causing an eventual use-after-free
when the taskwd tries to determine the task's status.
We fix this problem by removing the thread from the taskwd if
ca_repeater ever returns.
* Add GDB helper script
Pretty printing of some common argument types
Need to add a line to ~/.gdbinit
> add-auto-load-safe-path /path/to/base/checkout/
afterwards verify at GDB shell with
> info auto-load python-scripts
> info pretty-printer
Tested with GDB 16.3 circa Debian 13
Add $rcast(dbCommon) to up-cast
Add $record("name") to lookup record
Add $elln(ELLLIST,#) to index into list
* configure: fail hard if RPATH ORIGIN requested, but makeRPath errors out
The $(shell ...) construct stores the numeric exit code in
$(.SHELLSTATUS). Map zero to empty string, so that
non-zero values select $(error ...).
../rec/biRecord.c:191:42: warning: argument to ‘sizeof’ in ‘strncpy’
call is the same expression as the source; did you mean to use the
size of the destination? [-Wsizeof-pointer-memaccess]
191 | strncpy(pstring,prec->znam,sizeof(prec->znam));
| ^
Use memcpy instead of snprintf.
STATIC_ASSERT is added to ensure znam and onam are sized enough.
Debugging a problem and looking at the message
recGblDbaddrError: dbPut: Request type is 0 Illegal Database Request Type...
does not help very much: request type 0 is a legal value.
Improve the message to show the field type as well:
recGblDbaddrError: dbPut: dbrType = 0 field_type = DBF_INLIK (14)...
Do the same for both dbPut and dbGet.
Michael Davidsaver
zimoch