Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: waveform record: how its VAL get data? any potential memory leak? ...
From: Jack Smith <jacksmithvent2009@gmail.com>
To: Tim Mooney <mooney@aps.anl.gov>
Cc: tech-talk@aps.anl.gov
Date: Tue, 30 Oct 2012 15:24:33 -0400
Hi Tim, etc.

Thanks for all your detailed and wonderful explanations. More
questions related to waveform record:

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?

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]?

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.

Thanks,

Jack

On Fri, Oct 26, 2012 at 12:06 PM, Tim Mooney <mooney@aps.anl.gov> wrote:
> There have been several good answers, but I think there is still a little uncovered territory:
>
> ----- Original Message -----
>> From: "Jack Smith" <jacksmithvent2009@gmail.com>
>> To: tech-talk@aps.anl.gov
>> Sent: Thursday, October 25, 2012 10:31:22 PM
>> Subject: waveform record: how its VAL get data? any potential memory leak? ...
>> Hello everyone,
>>
>> I'm looking through the source code of the waveform record and trying
>> to understand how the it works. A few questions:
>>
>> 1. How does the BPTR field transfer data to VAL? Why do we have to set
>> NORD in the device support?
>
> BPTR is a pointer to the array, and the record-support routine cvt_dbaddr() converts a
> client's reference to VAL to a reference to BPTR.  When the array is posted, it is
> BPTR, not VAL, that is posted.
>
> Device support has to set NORD because only device support knows how many elements it read.
>
>> 2. During the record initialization, there is memory allocation by
>> callocMustSucceed( ). I remember some programming experts claim that
>> malloc (or new) must be paired with free (or delete) in a program to
>> prevent memory leak. If that is true, how should we deal with this
>> allocated memory in the lower level such as device support or driver
>> support to prevent memory leak? If I type "exit" to kill a Linux IOC,
>> will the memory allocated to the waveform record be released
>> automatically so that there is actually no memory leak problem?
>>
>> 3. When I look at waveformRecord.dbd, the field type of both VAL and
>> BPTR is DBF_NOACCES which I guess means no access to this field from
>> the database outside. It's true that I can't camonitor
>> waveform-record.BPTR, but obviously we can camonitor
>> waveform-record(.VAL). So, why does the DBF_NOACCES affect the VAL
>> field and the BPTR differently? What kind of magic makes VAL
>> accessible while BPTR inaccessble?
>
> It's not essential that the record have two fields associated with the data array.
> In the waveform record, VAL functions only as a redirect to BPTR, but it could also
> have held the array pointer.  Other records that have arrays use only one field.  It
> doesn't matter as long as the field definitions and the cvt_dbaddr() routine are
> consistent with each other.
>
> The VAL and BPTR fields are DBF_NOACCESS for several reasons: because cvt_dbaddr() will
> take over the job of specifying the field type at run time; because the field won't be
> functional until init_record() has allocated memory for it; and because the value of BPTR
> is not the data by the address of the data.  waveformRecord.dbd indicates that cvt_dbaddr()
> will be used to override the field type (and otherwise manage access to the field) by
> specifying "special(SPC_DBADDR)".
>
>> Thanks,
>>
>> J.S.
>
> --
> Tim Mooney (mooney@aps.anl.gov) (630)252-5417
> Software Services Group (www.aps.anl.gov)
> Advanced Photon Source, Argonne National Lab

Replies:
Re: waveform record: how its VAL get data? any potential memory leak? ... Andrew Johnson
References:
waveform record: how its VAL get data? any potential memory leak? ... Jack Smith
Re: waveform record: how its VAL get data? any potential memory leak? ... Tim Mooney

Navigate by Date:
Prev: User Created File Types: FILE TYPE += ABC [EPICS R3-14-12] Ernest L. Williams Jr.
Next: 3.14 v.s. 3.15 vs. v4 Jack Smith
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: waveform record: how its VAL get data? any potential memory leak? ... Tim Mooney
Next: Re: waveform record: how its VAL get data? any potential memory leak? ... Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·