[SCIP] valgrind issue

[James Cussens]

Thanks Stefan that is very useful information which will save me (and
perhaps others)
much time.

Best wishes,

James

On 12 May 2017 at 17:44, Stefan Vigerske <stefan at math.hu-berlin.de> wrote:

> Hi,
>
> you can usually ignore memory leaks from within dl_init:
> http://stackoverflow.com/questions/30376601/valgrind-memory-
> still-reachable-with-trivial-program-using-iostream
>
> dl_init is related to loading shared libraries. That happens with SCIP or
> other more complex programs, but not with a simple "hello world" program.
>
> Stefan
>
> On 05/12/2017 06:13 PM, James Cussens wrote:
>
>> I am using valgrind to check for memory leaks.
>>
>> valgrind claims that I do one more alloc than free, so I have been trying
>> to track down the problem.
>>
>> Just to be sure I understood what was going on I tried valgrind on the LOP
>> example that comes with SCIP4.0.0
>>
>> Running this:
>> valgrind --leak-check=full --show-leak-kinds=all bin/lop -v
>>
>> (which just prints out version and build options) produces this valgrind
>> output
>>
>> ....
>>
>> ZIMPLOPT=opt
>>   ZLIB=true
>> ==31777==
>> ==31777== HEAP SUMMARY:
>> ==31777==     in use at exit: 72,704 bytes in 1 blocks
>> ==31777==   total heap usage: 14,256 allocs, 14,255 frees, 1,345,646 bytes
>> allocated
>> ==31777==
>> ==31777== 72,704 bytes in 1 blocks are still reachable in loss record 1
>> of 1
>> ==31777==    at 0x4C2DB8F: malloc (in
>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==31777==    by 0x58ACEFF: ??? (in
>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
>> ==31777==    by 0x40104E9: call_init.part.0 (dl-init.c:72)
>> ==31777==    by 0x40105FA: call_init (dl-init.c:30)
>> ==31777==    by 0x40105FA: _dl_init (dl-init.c:120)
>> ==31777==    by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
>> ==31777==    by 0x1: ???
>> ==31777==    by 0xFFEFFFCAA: ???
>> ==31777==    by 0xFFEFFFCB2: ???
>> ==31777==
>> ==31777== LEAK SUMMARY:
>> ==31777==    definitely lost: 0 bytes in 0 blocks
>> ==31777==    indirectly lost: 0 bytes in 0 blocks
>> ==31777==      possibly lost: 0 bytes in 0 blocks
>> ==31777==    still reachable: 72,704 bytes in 1 blocks
>> ==31777==         suppressed: 0 bytes in 0 blocks
>> ==31777==
>> ==31777== For counts of detected and suppressed errors, rerun with: -v
>> ==31777== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>>
>> This 72,704 bytes that is still reachable when running bin/lop is exactly
>> the same number of allegedly still reachable bytes
>> that gets reported when I run my code. So presumably there is a common
>> issue. Anyone know what is going on?
>>
>> It looks like I don't have any memory problems since nothing is "lost"
>> (for
>> me or for LOP) but I would be interested to know what is going on.
>>
>> When running "hello world" (in C, with no linking to SCIP), valgrind, as
>> expected tells me that "All heap blocks were freed -- no leaks are
>> possible", so this is probably
>> not a valgrind issue.
>>
>> James
>>
>>
>>
>> _______________________________________________
>> Scip mailing list
>> Scip at zib.de
>> https://listserv.zib.de/mailman/listinfo/scip
>>
>>
>
> --
> http://www.gams.com/~stefan
>



-- 
James Cussens
Dept of Computer Science &
York Centre for Complex Systems Analysis
Room 326, The Hub, Deramore Lane            Tel    +44 (0)1904 325371
University of York                                        Fax  +44 (0)1904
500159
York YO10 5GE, UK                               http://www.cs.york.ac.uk/~jc
http://www.york.ac.uk/docs/disclaimer/email.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20170515/8373999d/attachment.html>