Known Problems
==============

.. _Known_Problems_2.1.16:

Known Problems in Release 2.1.16
--------------------------------

* Reportedly, there are still situations when building on 64-Bit-Windows
  fails, due to the same missing epicsShareExtern specifier. I recommend to
  just disable building the tests, until I have a proper fix for this. To do
  this, just comment-out the line ::

    DIRS += test

  in the top level Makefile.

* On Windows 8.1 x64 with Visual Studio 2013, the lemon parser generator
  crashes with an access violation. Freddie Akeroyd
  <freddie.akeroyd@stfc.ac.uk> sent a fix for that, see release notes for
  2.2.0.3.

* Tim Mooney <mooney@aps.anl.gov> reported a problem when monitoring large
  arrays. This could lead to assertion failures, causing CAS-client threads
  to be suspended. He also analysed the problem, tracing it back to a code
  snippet in src/pv/pvCa.cc, where a temporary copy of the value from CA is
  made on the stack. This can cause a stack overflow on systems where the
  stack size is statically limited, i.e. VxWorks and RTEMS.

  A proper fix would need a large-scale re-structuring of the PV layer. This
  is not something I am going to do in version 2.1, especially since the PV
  layer is going to be removed (mostly) anyway in the next version.

  The latest snapshot contains a quick and dirty fix. It lets you set ::

    USE_MALLOC_FOR_TEMPORARY_COPY=YES

  in configure/CONFIG_SITE, which will cause malloc/free to be used to
  create the temorary copy. Note that this may cause unwanted side-effects
  like memory fragmentation.

.. _Known_Problems_2.1.15:

Known Problems in Release 2.1.15
--------------------------------

Building fails on Windows due to a missing epicsShareExtern specifier.

The solution is to add epicsShareExtern to the declaration of the variable
seq_sync_timeout in src/seq/seq_if.c.

.. _Known_Problems_2.1.14:

Known Problems in Release 2.1.14
--------------------------------

Janez Golob <janez.golob@cosylab.com> reported a problem where a
pvAssign led to spurious pvVarMonitorOff() failure message. From that
moment on, the affected channels do not receive any monitor updates,
even if the program explicitly calls pvMonitor for them (which is
normally not needed).

A related (but distinct) problem was discovered that might cause similar
problems if pvMonitor or pvStopMonitor is called at the same time a CA
connection or disconnection event arrives.

.. _Known_Problems_2.1.13:

Known Problems in Release 2.1.13
--------------------------------

Building the tests fails with older base releases (e.g. 3.14.8).

It also fails on solaris/sparc. The reason in this case is that the
compiler sometimes generates an empty struct definition (i.e. one with
no members), which the compiler on this architecture doesn't like.

The pvGetComplete and pvPutComplete functions contain a serious bug
that was introduced in release 2.1.13. The effect is that sometimes
these functions return a wrong result: they can return TRUE when in
fact the callback from CA did not yet arrive, which is particularly
bad with pvGetComplete, since it can mean that if the pvGetComplete is
used in a when clause then in the code block that follows the result
is not yet available.

Also note that non-safe mode, this can lead to a race condition
between update from the CA callback and access from the program,
possibly corrupting the variable's content. This has always been true
for monitored variables, but not when using asynchronous pvGet.

(These problems are fixed in 2.1.14.)


.. _Known_Problems_2.1.12:

Known Problems in Release 2.1.12
--------------------------------

If a synchronous pvGet (or pvPut) ever fails to get a callback from
channel access, then all subsequent attempts to do pvGets on that
channel will fail.

Carl Lionberger <calionberger@lbl.gov>, who reported this problem,
also found the reason: the semaphore that makes the state set block
until the CA callback arrives, times out but is never signalled, so
the variable never recovers from the situation.

This problem is probably present in all releases of the 2.1 branch.

The problem has been fixed in version 2.1.13, see
:ref:`Release_Notes_2.1.13`.

.. _Known_Problems_2.1.10:

Known Problems in Release 2.1.10
--------------------------------

In the warning message when a queue is full, the variable name
should be quoted. Here is an example::

  sevr=minor pvPut on queued variable response (anonymous): last queue
  element overwritten (queue is full)

Here "response" is actually the variable name, but this is not apparent.


.. _Known_Problems_2.1.8:

Known Problems in Release 2.1.8
-------------------------------

Build fails on some windows systems due to a stupid bug in
src/snc/Makefile.

.. _Known_Problems_2.1.7:

Known Problems in Release 2.1.7
-------------------------------

* In some cases the parallel build (make -j) fails inside src/snc.
  The rule for generating the parser (using lemon) is executed twice
  in parallel.

* In certain cases the code generated by snc can have a naming
  conflict i.e. different functions get the same name. The
  following code fragment demonstrates this case::

    ss x { state y_z { ... } }
    ss x_y { state z { ... } }

.. _Known_Problems_2.1.6:

Known Problems in Release 2.1.6
-------------------------------

All these are fixed in the latest snapshot and in the next release.

* The (undocumented) snc option -i disables generation of iocsh
  registration code. This option should *not* be used, even if
  the program runs on vxWorks without an iocsh. Furthermore, the ::

    registrar(<programName>Registrar)

  line *must* be included in the dbd file.

  If *no* registrar
  entries exist, global variables are not properly initialized,
  leading to an assertion failure when the first program is started.

  If only some entries exist, seqShow will only display the ones
  that have been registered.

* Sometimes seqShow with no arguments does not display all programs
  and state sets in a table as it is supposed to do. This happens if
  there is (at least) one state set that has not yet been started,
  for instance if not all channels have connected yet. seqShow (with
  no arguments) then acts as if you gave it the name of such a program.

* Build on a Debian Linux system failed due to missing header files.
  It seems this is caused by ``USR_CFLAGS += -I$(TOP)/src/seq`` lines
  in some Makefiles. William Steele reported this and also provided
  the fix, which is to replace these with
  ``USR_INCLUDES += -I$(TOP)/src/seq``.

.. _Known_Problems_2.1.5:

Known Problems in Release 2.1.5
-------------------------------

These are all fixed in the latest snapshot.

* Using pvPutComplete or pvGetComplete inside a when-clause may
  result in a deadlock: the state set forever waits for the
  completion even though the callback arrived.

  Note: this Problem is present at least since 2.0.12.

  Note also: standard CA thread priorities hide this problem, so the
  symptoms do not appear on VxWorks and RTEMS; they appear only if
  epics thread priorities are reversed (or ignored, as is typically
  the case for soft IOCs running in user mode on Linux or Windows).

* In safe mode, if a variable is monitored and sync'ed, it can
  happen that an event is detected with efTestAndClear
  but the underlying variable still has the old value.

  You should avoid using efTestAndClear together with conditions
  that test the value of the underlying variable; this may lead
  to an apparently "lost event", i.e. the event flag gets cleared
  but no state transition happens. Instead use efTest, and
  clear the flag in the action block only after you have actually
  got the new value.

* The asynchronous versions of pvPut and pvGet built-in functions
  do not behave correctly in case of connection loss. Particularly,
  if connection is lost when waiting for completion, the state set
  that issued the command will not be woken, so that it will wait
  for the full timeout (the hard-coded 10 seconds).

  Thanks to Daniel Keating for finding
  this bug and pointing me in the right direction how to fix it.

* The compiler crashes when an assign clause lists more PVs than
  the array contains elements.

* The compiler reports wrong line numbers (and could potentially
  crash, though I did not experience this) when SNL or C code is
  included with an un-escaped preprocessor #include command.

* In safe mode, anonymous PVs deviate from named PVs in the behaviour
  of event flags: Normally, event flags for monitored PVs will be
  set when entering the first state because of the first monitor event
  we get from CA after connecting. This should be emulated for
  anonymous PVs in order to restore the symmetry and so that named
  and anonymous PVs can be interchanged at will (as claimed in the docs).

.. _Known_Problems_2.1.4:

Known Problems in Release 2.1.4
-------------------------------

The builtin procedure pvAssign has several bugs:

* In safe mode, if an initially unassigned variable gets assigned
  at runtime using pvAssign, a subsequent pvGet crashes the program.

* When re-assigning a variable that is already connected to a PV, then
  you get warning messages like
  "sevr=minor XYZ connect event but already connected". It also looks as
  if not all resources associated with teh channel are correctly freed.
