[ADOL-C] Memory issue with ADOL-C adouble creation

Kshitij Kulshreshtha kshitij at math.upb.de
Mon Oct 28 11:07:50 EDT 2013


Hello,

Sorry for the late reply, could you please try using the ADOL-C svn
trunk from COIN-OR?

If you get the same error again please compile it with an additional
cflag/cxxflag -DADOLC_LOCDEBUG and send the output. (It will be lots of
text).

Regards.
Kshitij

As on 2013-10-16 17:07h, Alex Dowling did write:
> Hello,
> 
> I'm using ADOL-C and adjoint sensitivity equations to provide
> derivatives for a nonlinear optimal control problem. As part of the
> debugging process we ran Valgrind on the code and found some memory
> issues. Running with Valgrind also caused a segmentation fault:
> 
> yajun at hessian:~/svn/psaProject/combined2$ valgrind ./compare
> ==1841== Memcheck, a memory error detector
> ==1841== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==1841== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==1841== Command: ./compare
> ==1841== 
> 
> *Console output from the optimization code removed*
> 
> ==1841== Invalid write of size 8
> ==1841==    at 0x4E3E7C3: adouble::adouble() (adouble.cpp:66)
> ==1841==    by 0x436437: tracerhs(double, double*, double*, double*,
> JACTYPE, bool, int) (tracer_ss.c:34)
> ==1841==    by 0x439363: fQuad(double, _generic_N_Vector*,
> _generic_N_Vector*, _generic_N_Vector*, void*) (ss_adjoint.c:909)
> ==1841==    by 0x45F3D3: CVArhsQ (in
> /home/yajun/svn/psaProject/combined2/compare)
> ==1841==    by 0x44CFF5: cvQuadNls (in
> /home/yajun/svn/psaProject/combined2/compare)
> ==1841==    by 0x44901C: cvStep (in
> /home/yajun/svn/psaProject/combined2/compare)
> ==1841==    by 0x44362B: CVode (in
> /home/yajun/svn/psaProject/combined2/compare)
> ==1841==    by 0x45AE1E: CVodeB (in
> /home/yajun/svn/psaProject/combined2/compare)
> ==1841==    by 0x43ABAC: simCycles_withAdjoints(double*, double*,
> double*, int, Logs, double*, double*, int*, int*) (ss_adjoint.c:348)
> ==1841==    by 0x4148FF: main (perturb.cpp:105)
> ==1841==  Address 0xa73e818 is not stack'd, malloc'd or (recently) free'd
> ==1841== 
> ==1841== 
> ==1841== Process terminating with default action of signal 11 (SIGSEGV)
> ==1841==  Access not within mapped region at address 0xA73E818
> ==1841==    at 0x4E3E7C3: adouble::adouble() (adouble.cpp:66)
> ==1841==    by 0x436437: tracerhs(double, double*, double*, double*,
> JACTYPE, bool, int) (tracer_ss.c:34)
> ==1841==    by 0x439363: fQuad(double, _generic_N_Vector*,
> _generic_N_Vector*, _generic_N_Vector*, void*) (ss_adjoint.c:909)
> ==1841==    by 0x45F3D3: CVArhsQ (in
> /home/yajun/svn/psaProject/combined2/compare)
> ==1841==    by 0x44CFF5: cvQuadNls (in
> /home/yajun/svn/psaProject/combined2/compare)
> ==1841==    by 0x44901C: cvStep (in
> /home/yajun/svn/psaProject/combined2/compare)
> ==1841==    by 0x44362B: CVode (in
> /home/yajun/svn/psaProject/combined2/compare)
> ==1841==    by 0x45AE1E: CVodeB (in
> /home/yajun/svn/psaProject/combined2/compare)
> ==1841==    by 0x43ABAC: simCycles_withAdjoints(double*, double*,
> double*, int, Logs, double*, double*, int*, int*) (ss_adjoint.c:348)
> ==1841==    by 0x4148FF: main (perturb.cpp:105)
> ==1841==  If you believe this happened as a result of a stack
> ==1841==  overflow in your program's main thread (unlikely but
> ==1841==  possible), you can try to increase the size of the
> ==1841==  main thread stack using the --main-stacksize= flag.
> ==1841==  The main thread stack size used in this run was 8388608.
> ==1841== 
> ==1841== HEAP SUMMARY:
> ==1841==     in use at exit: 20,183,646 bytes in 31,127 blocks
> ==1841==   total heap usage: 3,172,497 allocs, 3,141,370 frees,
> 203,707,733 bytes allocated
> ==1841== 
> ==1841== LEAK SUMMARY:
> ==1841==    definitely lost: 0 bytes in 0 blocks
> ==1841==    indirectly lost: 0 bytes in 0 blocks
> ==1841==      possibly lost: 34 bytes in 1 blocks
> ==1841==    still reachable: 20,183,612 bytes in 31,126 blocks
> ==1841==         suppressed: 0 bytes in 0 blocks
> ==1841== Rerun with --leak-check=full to see details of leaked memory
> ==1841== 
> ==1841== For counts of detected and suppressed errors, rerun with: -v
> ==1841== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
> Segmentation fault (core dumped)
> 
> Here is line 34 of tracer_ss.c:
>   adouble *cd = new adouble[NEQ];
> 
> And lines 53 - 70 of adouble.c:
> adouble::adouble() {
>     location = next_loc();
>     ADOLC_OPENMP_THREAD_NUMBER;
>     ADOLC_OPENMP_GET_THREAD_NUMBER;
> 
> #if defined(ADOLC_ADOUBLE_STDCZERO)
>     if (ADOLC_CURRENT_TAPE_INFOS.traceFlag) {
>         put_op(assign_d_zero);
>         ADOLC_PUT_LOCINT(location);   // = res
>     }
>     
>     ++ADOLC_CURRENT_TAPE_INFOS.numTays_Tape;
>     if (ADOLC_CURRENT_TAPE_INFOS.keepTaylors)
>         ADOLC_WRITE_SCAYLOR(ADOLC_GLOBAL_TAPE_VARS.store[location]); //
> Line 66
>     
>     ADOLC_GLOBAL_TAPE_VARS.store[location] = 0.;
> #endif
> }
> 
> Has anyone seen this behavior before? Does it mean the dimensions of cd*
> are violated, or is there a problem with the adouble constructor?
> 
> Versions information: ADOL-C: 2.4.1, ColPack: 1.0.9, CVODES
> (integrator): 2.7.0
> 
> Thanks,
> Alex
> 
> 
> 
> 
> _______________________________________________
> ADOL-C mailing list
> ADOL-C at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/adol-c
> 

-- 
Dr. Kshitij Kulshreshtha

Institut für Mathematik,
Universität Paderborn,
Warburger Straße 100,
33098 Paderborn.

Büro: A3.235

Privatanschrift:
Arnikaweg 62
33100 Paderborn.


More information about the ADOL-C mailing list