Re: Bus errors accessing VME with base 7.0.6.1 and latest synApps modules

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

> On 5/27/22 06:17, Mark Rivers wrote:
> > Hi Michael,
> >
> > I commented out all lines in recGbl.c that reference the new amsg and namsg fields.  That did not fix the problem.
I take this to mean both db_post_events() and epicsVsnprintf() calls,
which means that both AMSG and NAMSG should always be an empty string.
(aka. char[40] all nils)

https://github.com/epics-base/epics-base/commit/892a361de7002bf2b3f375f24bc5bf61858de2e5

> On 5/27/22 10:33, Mark Rivers wrote:
> > I am now using the unmodified 7.0.6 release.
...
> Before I build in that directory I run
I don't know how difficult it is with vxWorks @APS, but it might be a
good idea to go further and start from fresh git-clone of all modules
(base and synapps and application).  This should rule out build
leftovers entirely.


On 5/27/22 10:33, Mark Rivers wrote:
> What could possibly cause this?
This is a very good question...


As I think about it, adding/removing AMSG+NAMSG would have exposed some
partial rebuild problems with Base and parts of synapps.  The generated
record type headers include a check that the number of fields at load time
is the same as the number at build time.


If not a build/ABI issue, I don't see an easy way forward in troubleshooting.

We've passed the point where I would be trying to setup a (remote) debugger
to inspect the stack of a faulting thread.  This should identify one of the
records involved, and a dump of that record struct may show evidence of corruption.

For that matter, "dbpr <name> 5" could show evidence, if you can find one
of the records.