<div dir="ltr">Thanks Stefan that is very useful information which will save me (and perhaps others)<div>much time.</div><div><br></div><div>Best wishes,</div><div><br></div><div>James</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 May 2017 at 17:44, Stefan Vigerske <span dir="ltr"><<a href="mailto:stefan@math.hu-berlin.de" target="_blank">stefan@math.hu-berlin.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
you can usually ignore memory leaks from within dl_init:<br>
<a href="http://stackoverflow.com/questions/30376601/valgrind-memory-still-reachable-with-trivial-program-using-iostream" rel="noreferrer" target="_blank">http://stackoverflow.com/quest<wbr>ions/30376601/valgrind-memory-<wbr>still-reachable-with-trivial-<wbr>program-using-iostream</a><br>
<br>
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.<br>
<br>
Stefan<br>
<br>
On 05/12/2017 06:13 PM, James Cussens wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am using valgrind to check for memory leaks.<br>
<br>
valgrind claims that I do one more alloc than free, so I have been trying<br>
to track down the problem.<br>
<br>
Just to be sure I understood what was going on I tried valgrind on the LOP<br>
example that comes with SCIP4.0.0<br>
<br>
Running this:<br>
valgrind --leak-check=full --show-leak-kinds=all bin/lop -v<br>
<br>
(which just prints out version and build options) produces this valgrind<br>
output<br>
<br>
....<br>
<br>
ZIMPLOPT=opt<br>
  ZLIB=true<br>
==31777==<br>
==31777== HEAP SUMMARY:<br>
==31777==     in use at exit: 72,704 bytes in 1 blocks<br>
==31777==   total heap usage: 14,256 allocs, 14,255 frees, 1,345,646 bytes<br>
allocated<br>
==31777==<br>
==31777== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1<br>
==31777==    at 0x4C2DB8F: malloc (in<br>
/usr/lib/valgrind/vgpreload_me<wbr>mcheck-amd64-linux.so)<br>
==31777==    by 0x58ACEFF: ??? (in<br>
/usr/lib/x86_64-linux-gnu/libs<wbr>tdc++.so.6.0.21)<br>
==31777==    by 0x40104E9: call_init.part.0 (dl-init.c:72)<br>
==31777==    by 0x40105FA: call_init (dl-init.c:30)<br>
==31777==    by 0x40105FA: _dl_init (dl-init.c:120)<br>
==31777==    by 0x4000CF9: ??? (in /lib/x86_64-linux-gnu/<a href="http://ld-2.23.so" rel="noreferrer" target="_blank">ld-2.23.<wbr>so</a>)<br>
==31777==    by 0x1: ???<br>
==31777==    by 0xFFEFFFCAA: ???<br>
==31777==    by 0xFFEFFFCB2: ???<br>
==31777==<br>
==31777== LEAK SUMMARY:<br>
==31777==    definitely lost: 0 bytes in 0 blocks<br>
==31777==    indirectly lost: 0 bytes in 0 blocks<br>
==31777==      possibly lost: 0 bytes in 0 blocks<br>
==31777==    still reachable: 72,704 bytes in 1 blocks<br>
==31777==         suppressed: 0 bytes in 0 blocks<br>
==31777==<br>
==31777== For counts of detected and suppressed errors, rerun with: -v<br>
==31777== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)<br>
<br>
This 72,704 bytes that is still reachable when running bin/lop is exactly<br>
the same number of allegedly still reachable bytes<br>
that gets reported when I run my code. So presumably there is a common<br>
issue. Anyone know what is going on?<br>
<br>
It looks like I don't have any memory problems since nothing is "lost" (for<br>
me or for LOP) but I would be interested to know what is going on.<br>
<br>
When running "hello world" (in C, with no linking to SCIP), valgrind, as<br>
expected tells me that "All heap blocks were freed -- no leaks are<br>
possible", so this is probably<br>
not a valgrind issue.<br>
<br>
James<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Scip mailing list<br>
<a href="mailto:Scip@zib.de" target="_blank">Scip@zib.de</a><br>
<a href="https://listserv.zib.de/mailman/listinfo/scip" rel="noreferrer" target="_blank">https://listserv.zib.de/mailma<wbr>n/listinfo/scip</a><br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
<a href="http://www.gams.com/~stefan" rel="noreferrer" target="_blank">http://www.gams.com/~stefan</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">James Cussens<br>Dept of Computer Science &<br>York Centre for Complex Systems Analysis<br>Room 326, The Hub, Deramore Lane            Tel    +44 (0)1904 325371<br>University of York                                        Fax  +44 (0)1904 500159<br>York YO10 5GE, UK                               <a href="http://www.cs.york.ac.uk/~jc" target="_blank">http://www.cs.york.ac.uk/~jc</a><br><a href="http://www.york.ac.uk/docs/disclaimer/email.htm" target="_blank">http://www.york.ac.uk/docs/disclaimer/email.htm</a></div>
</div>