Re: [Help-gsl] Memory issues when using GSL ODE solver

[Alex Shevtsov]

> Excellent.  This was with GSL version 1.16?

No, I compiled it all with GSL 1.15 from Ubuntu 12.04 repositories. But
still I see no leaks in the C-version, while there is something in the
Cython/Python version.

>Sometimes scripting environments or shared libraries will "hold
>on" to memory until they exit or until they're asked to let go (e.g.
>Intel MKL and FFTW both do this).

Probably it is the problem of a Python interpreter. It has an automatic
garbage collector, which is probably invoked in the end, when all the loops
are finished. But while they were running, the memory was being consumed. I
never had any problems with it before though.

I have to think how to work-around these difficulties. Any suggestions are
very appreciated.

Thanks.

Best wishes,
Alex


On Mon, Nov 25, 2013 at 6:07 PM, Rhys Ulerich <address@hidden>wrote:

> Hi Alex,
>
> > I ran the example we discussed using C with valgrind and indeed found no
> > leaks.
>
> Excellent.  This was with GSL version 1.16?
>
> > Then I wrote the same thing in Cython and ran the valgrind again with
> > --suppressions=/usr/.../python.supp as suggested here,
> >
> http://kratos-wiki.cimne.upc.edu/index.php/Checking_memory_use_with_Valgrind
> .
> > And the difference looks like this:
> >
> > HEAP SUMMARY:
> > ==7329==     in use at exit: 1,013,593 bytes in 245 blocks
> > ==7329==   total heap usage: 7,559 allocs, 7,314 frees, 6,631,527 bytes
> > allocated
> > ==7329==
> > LEAK SUMMARY:
> > ==7329==    definitely lost: 0 bytes in 0 blocks
> > ==7329==    indirectly lost: 0 bytes in 0 blocks
> > ==7329==      possibly lost: 6,072 bytes in 17 blocks
> > ==7329==    still reachable: 1,007,521 bytes in 228 blocks
> > ==7329==         suppressed: 0 bytes in 0 blocks
> >
> > Does it mean that the problem I am experiencing is because of those 245
> > blocks, which were not deallocated? Could you give me a hint on how to
> fight
> > with the 'still reachable' and 'possibly lost' blocks? I guess you have
> some
> > experience with that.
>
> Likely that's the problem, but I don't know Cython well enough to be
> sure.  Sometimes scripting environments or shared libraries will "hold
> on" to memory until they exit or until they're asked to let go (e.g.
> Intel MKL and FFTW both do this).
>
> I'd ask the Cython folks how to proceed from here.  Sorry to not be
> able to be more help at this stage.
>
> - Rhys
>