[CppAD] attempt to return memory not in use

[Michael Braun]

Brad and Jey:

Thanks for your suggestions.  What I did was place the thread_alloc::inuse(0) function in the destructor of the object that contains the ADFun<double> object.  From that, I deduced that R does not call the destructor of an object when it is deleted, but when it runs garbage collection.  Forcing a garbage collection run at the beginning of my R code solved the problem.

Michael



On Mar 4, 2012, at 9:33 AM, Brad Bell wrote:

> Try running the case in the debugger. When the error occurs, you should be able to look up the call stack and see which routine is calling return_memory with what return_memory has determined to be an invalid pointer. If it is one of your routines, perhaps it will then be clear what is going on.
> 
> Another place to look for help is the routine
>     http://www.coin-or.org/CppAD/Doc/ta_inuse.xml
> Perhaps at some point in your program you think you have deleted all your CppAD objects, but you have not yet done so. Note that since you are only using one thread, its thread number is zero.
> 
> As a last resort, in
>     cppad/thread_alloc.hpp 
> you can set CPPAD_TRACE_THREAD to 0 and  CPPAD_TRACE_CAPACITY to 972. Then redirect the trace output to a file. Perhaps you can see where the memory has already been freed.
> 
> On 03/01/2012 08:17 AM, Michael Braun wrote:
>> 
>> Hi.
>> 
>> I have a rather complex use case for CppAD that is generating an error.  Unfortunately, I cannot construct a simple, reproducible case, but I am hoping someone can point me in the right direction to diagnose the problem.
>> 
>> I have written a class that includes an ADFun<double> as a member.  I am then exposing my C++ class in R, and then calling the C++ member functions using the Rcpp modules functionality.
>> 
>> If I launch R, run my R script, construct an object from the C++  class, everything works fine.  But then, after I delete the C++ object, unload the dynamic library, and start over again, I get the following error after trying to load in completely unrelated data:
>> 
>> cppad-20120227 error from a known source:
>> return_memory: attempt to return memory not in use
>> v_ptr    = 0x7fa4739037b8
>> thread   = 0
>> capacity = 972
>> See CPPAD_TRACE_THREAD & CPPAD_TRACE_CAPACITY in
>> # include <cppad/thread_alloc.hpp>
>> 
>> Error detected by false result for
>>     false
>> at line 982 in the file 
>>     /opt/cppad/include/cppad/thread_alloc.hpp
>> Assertion failed: (false), function CppAD::ErrorHandler::Default, file /opt/cppad/include/cppad/error_handler.hpp, line 217.
>> 
>> What's interesting is that when I get this error message, the object of the class that uses CppAD should have already been deleted.  And this error pops up long before I call the constructor.  It is only after I restart R that I can run my program again.  So this makes me think that something is going on with how CppAD re-allocates memory.
>> 
>> I am not doing anything special to de-allocate the ADFun or AD objects at all?  Should I?  Also, I am not running any multi-threaded code, so I am not invoking "parallel mode."  I was not able to find an example of using CppAD in parallel mode, even if the application itself is sequential.
>> 
>> Can you offer some suggestions on what to look for, or explain what might might cause CppAD to want to return memory that is not in use?
>> 
>> Thanks,
>> 
>> Michael
>> 
>> 
>> 
>> 
>> 
>> 
>> Michael Braun 
>> MIT Sloan School of Management
>> braunm at mit.edu
>> -------------------------------------------------- 
>> View my research at
>> http://braunm.scripts.mit.edu/
>> 
>> 
>> 
>> _______________________________________________
>> CppAD mailing list
>> CppAD at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/cppad
> 

Michael Braun 
MIT Sloan School of Management
braunm at mit.edu
-------------------------------------------------- 
View my research at
http://braunm.scripts.mit.edu/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cppad/attachments/20120304/5b1a703d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1844 bytes
Desc: not available
URL: <http://list.coin-or.org/pipermail/cppad/attachments/20120304/5b1a703d/attachment.p7s>