| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: waveform record: how its VAL get data? any potential memory leak? ... |
| From: | Michael Davidsaver <[email protected]> |
| To: | [email protected] |
| 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.