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: Michael Davidsaver <mdavidsaver@bnl.gov>
To: tech-talk@aps.anl.gov
Date: Fri, 26 Oct 2012 09:47:14 -0400
Hi Jack,

The following aren't complete answers, but I think it should give a good idea of where to look.

http://bazaar.launchpad.net/~epics-core/epics-base/3.14/view/head:/src/rec/waveformRecord.c

http://bazaar.launchpad.net/~epics-core/epics-base/3.14/view/head:/src/db/dbAccess.c

On 10/25/2012 11:31 PM, Jack Smith wrote:
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?

See cvt_dbaddr() in the record support code and note the presence of SPC_DBADDR in the record's dbd file.

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?

For historical reasons A lot of IOC cleanup is omitted and left to the OS when the process exits.

With the waveformRecord I think this is not strictly speaking a memory leak as the reference to this memory (BPTR) is never lost. Also, memory is only allocated once, so there is no chance of a runaway growth in memory usage which will eventually cause problems.

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?

Have a look at the record support functions cvt_dbaddr() and get_array_info() and put_array_info(). The code which calls these functions is found in dbAccess.c.


References:
waveform record: how its VAL get data? any potential memory leak? ... Jack Smith

Navigate by Date:
Prev: RE: waveform record: how its VAL get data? any potential memory leak? ... Hu, Yong
Next: Re: waveform record: how its VAL get data? any potential memory leak? ... Tim Mooney
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? ... Hu, Yong
Next: Re: waveform record: how its VAL get data? any potential memory leak? ... Tim Mooney
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 ·