Re: waveform record: how its VAL get data? any potential memory leak? ...

[Andrew Johnson <anj@aps.anl.gov>]

Hi Jack,

On 2012-10-30 Jack Smith wrote:
> The dynamic array sizing was introduced in 3.14.12. When I diff the
> waveformRecord.c (.dbd) between 3.14.11 and 3.14.12, I don't see any
> fundamental changes contributing to dynamic array sizing. Questions:
> 
> 1. Which source files in the base were changed/improved to make
> dynamic array sizing work? How can I locate those changes through the
> launchpad repository?

The Channel Access network protocol doesn't implement all the features that 
are available within the IOC, and array sizing was one of those features.  The 
database (in your case the waveform record) kept track of how much data was 
currently stored in the array (NORD field), but the CA server had no way to 
pass that information to the clients along with the data.  We saw that there 
was a way to change the network protocol slightly to pass that data without 
having to make incompatible changes to the CA API, and someone volunteered to 
implement it.

How would you go about finding out what changed?  Well once you know which 
version of Base first provided that feature (3.14.12, from the Release Notes 
entry "Dynamic arrays over CA") you would look at the commit log messages on 
the 3.14 branch before the R3.14.12-rc1 tag.  This is faster if you have 
Bazaar installed and you check out the source from launchpad into a local 
repository.  For big changes like this I would look for merges rather than 
individual commits:

tux$ bzr log --line -r ..R3.14.12-rc1
12195: Janet Anderson 2010-11-15 {R3.14.12-rc1} R3.14.12-rc1
12194: jba 2010-11-15 Set HDEPENDS_METHOD to CMD which was overidden by 
CONFIG.gnuCommon.
12193: jba 2010-11-15 Added and removed include files.
12192: Janet Anderson 2010-11-15 Removed unneeded include line.
12191: Janet Anderson 2010-11-14 Added include lines for host build 
CONFIG_SITE files.

  ... until eventually we get to ...

12112: Andrew Johnson 2010-09-20 [merge] Merged Michael Abbott's dynamic-array 
branch, rebased.

So the changes were developed on a branch which was merged in commit 12112:

tux$ bzr log -v -c 12112
------------------------------------------------------------
revno: 12112 [merge]
committer: Andrew Johnson <anj@aps.anl.gov>
branch nick: 3.14
timestamp: Mon 2010-09-20 16:21:50 -0500
message:
  Merged Michael Abbott's dynamic-array branch, rebased.
  
  I added Perl support, and wrote some release notes.
modified:
  documentation/RELEASE_NOTES.html
  src/ca/CAref.html
  src/ca/caProto.h
  src/ca/db_access.h
  src/ca/nciu.cpp
  src/ca/nciu.h
  src/ca/netIO.h
  src/ca/oldChannelNotify.cpp
  src/ca/tcpiiu.cpp
  src/cap5/CA.pm
  src/cap5/Cap5.xs
  src/cap5/caget.pl
  src/cap5/camonitor.pl
  src/catools/caget.c
  src/catools/camonitor.c
  src/catools/tool_lib.c
  src/catools/tool_lib.h
  src/db/db_access.c
  src/db/db_access_routines.h
  src/rsrv/camessage.c
  src/rsrv/caserverio.c
  src/rsrv/server.h
------------------------------------------------------------
Use --include-merges or -n0 to see merged revisions.

You can look at the diff for that merge using "bzr diff -c 12112" or you can 
look at the individual commits in the branch with "bzr log -n0 -c 12112".  If 
you add a -p flag to the "bzr log" command it will also show you the diffs for 
each commit.

Now I happen to know that there was a bug fixed with this functionality in 
R3.14.12.1 so you should look at commit 12211 as well.

> 2. I tested this new feature under 3.14.12 IOC paired with 3.14.12
> camonitor. I used the classic exampleApp and added one waveform record
> which has NELM greater than 10 and reads data from the compress
> record. As you know, the compress record is a circular buffer with
> data range from 0 to 9. When I camonitor the waveform record, I get
> array data like [0], [0 1], [0 1 2], ..., [0 1 2 ... 9], [1 2 3 ... 9
> 0], [2 3 4 ... 9 0 1] ... For the array data [2 3 4 ... 9 0 1], how
> "dynamic array sizing" knows the '0' is real data, not zero-filling
> ending? i.e. why can I get [2 3 4 ... 9 0 1] rather than [2 3 4 ...
> 9]?

The record keeps track of how many elements the array contains.  In the 
waveform record that is the purpose of the NORD field, and the record's 
get_array_info() routine is called to get that value.  The compress record 
keeps the length in the NUSE field, and its get_array_info() routine 
demonstrates that arrays can also be used as circular buffers as it also 
returns the offset to the start of the buffer.

> I do make a search on tech-talk archive before I post a question. But
> the search usually gives lots of threads or nothing. I hope it's OK
> here to ask any kind of questions, either naive or complicated, either
> new or repeated.

This is exactly the right place to ask these kinds of questions.  Even if you 
find one person answers more often than anyone else it's best to go through 
the list rather than directly to them so that other people have a chance to 
read the response in the future, and if the expert takes some time off someone 
else may reply.

HTH,

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte