Hi Rainer Weikusat,

This is what valgrind says:

valgrind --leak-check=full /sbin/ifup eth0
==15914== Memcheck, a memory error detector
==15914== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==15914== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==15914== Command: /sbin/ifup eth0
==15914==
==15914== Invalid read of size 1
==15914==    at 0x405B0B: ??? (in /sbin/ifup)
==15914==    by 0x406A27: ??? (in /sbin/ifup)
==15914==    by 0x402128: ??? (in /sbin/ifup)
==15914==    by 0x4E56B44: (below main) (libc-start.c:287)
==15914==  Address 0x51de46f is 1 bytes before a block of size 80 alloc'd
==15914==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==15914==    by 0x4C2AFCF: realloc (vg_replace_malloc.c:692)
==15914==    by 0x4059F1: ??? (in /sbin/ifup)
==15914==    by 0x406A27: ??? (in /sbin/ifup)
==15914==    by 0x402128: ??? (in /sbin/ifup)
==15914==    by 0x4E56B44: (below main) (libc-start.c:287)
==15914==
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:1e:ec:d9:d9:72
Sending on   LPF/eth0/00:1e:ec:d9:d9:72
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
==15914==
==15914== HEAP SUMMARY:
==15914==     in use at exit: 740 bytes in 34 blocks
==15914==   total heap usage: 88 allocs, 54 frees, 7,481 bytes allocated
==15914==
==15914== 1 bytes in 1 blocks are definitely lost in loss record 1 of 24
==15914==    at 0x4C2AF2E: realloc (vg_replace_malloc.c:692)
==15914==    by 0x4085CB: ??? (in /sbin/ifup)
==15914==    by 0x405694: ??? (in /sbin/ifup)
==15914==    by 0x402E1A: ??? (in /sbin/ifup)
==15914==    by 0x4E56B44: (below main) (libc-start.c:287)
==15914==
==15914== 1 bytes in 1 blocks are definitely lost in loss record 2 of 24
==15914==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==15914==    by 0x4EB69D9: strdup (strdup.c:42)
==15914==    by 0x40547E: ??? (in /sbin/ifup)
==15914==    by 0x4056F2: ??? (in /sbin/ifup)
==15914==    by 0x402E1A: ??? (in /sbin/ifup)
==15914==    by 0x4E56B44: (below main) (libc-start.c:287)
==15914==
==15914== 1 bytes in 1 blocks are definitely lost in loss record 3 of 24
==15914==    at 0x4C2AF2E: realloc (vg_replace_malloc.c:692)
==15914==    by 0x4085CB: ??? (in /sbin/ifup)
==15914==    by 0x40570A: ??? (in /sbin/ifup)
==15914==    by 0x402E1A: ??? (in /sbin/ifup)
==15914==    by 0x4E56B44: (below main) (libc-start.c:287)
==15914==
==15914== 5 bytes in 1 blocks are definitely lost in loss record 6 of 24
==15914==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==15914==    by 0x4EB69D9: strdup (strdup.c:42)
==15914==    by 0x403D1B: ??? (in /sbin/ifup)
==15914==    by 0x402900: ??? (in /sbin/ifup)
==15914==    by 0x4E56B44: (below main) (libc-start.c:287)
==15914==
==15914== 10 bytes in 2 blocks are definitely lost in loss record 8 of 24
==15914==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==15914==    by 0x4EB69D9: strdup (strdup.c:42)
==15914==    by 0x40547E: ??? (in /sbin/ifup)
==15914==    by 0x40567C: ??? (in /sbin/ifup)
==15914==    by 0x402E1A: ??? (in /sbin/ifup)
==15914==    by 0x4E56B44: (below main) (libc-start.c:287)
==15914==
==15914== 17 bytes in 2 blocks are definitely lost in loss record 15 of 24
==15914==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==15914==    by 0x4EB6A29: strndup (strndup.c:45)
==15914==    by 0x40545F: ??? (in /sbin/ifup)
==15914==    by 0x4056F2: ??? (in /sbin/ifup)
==15914==    by 0x402E1A: ??? (in /sbin/ifup)
==15914==    by 0x4E56B44: (below main) (libc-start.c:287)
==15914==
==15914== 21 bytes in 3 blocks are definitely lost in loss record 18 of 24
==15914==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==15914==    by 0x4EB6A29: strndup (strndup.c:45)
==15914==    by 0x40545F: ??? (in /sbin/ifup)
==15914==    by 0x40567C: ??? (in /sbin/ifup)
==15914==    by 0x402E1A: ??? (in /sbin/ifup)
==15914==    by 0x4E56B44: (below main) (libc-start.c:287)
==15914==
==15914== 80 bytes in 1 blocks are definitely lost in loss record 23 of 24
==15914==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==15914==    by 0x4C2AFCF: realloc (vg_replace_malloc.c:692)
==15914==    by 0x4059F1: ??? (in /sbin/ifup)
==15914==    by 0x406A27: ??? (in /sbin/ifup)
==15914==    by 0x402128: ??? (in /sbin/ifup)
==15914==    by 0x4E56B44: (below main) (libc-start.c:287)
==15914==
==15914== LEAK SUMMARY:
==15914==    definitely lost: 136 bytes in 12 blocks
==15914==    indirectly lost: 0 bytes in 0 blocks
==15914==      possibly lost: 0 bytes in 0 blocks
==15914==    still reachable: 604 bytes in 22 blocks
==15914==         suppressed: 0 bytes in 0 blocks
==15914== Reachable blocks (those to which a pointer was found) are not shown.
==15914== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==15914==
==15914== For counts of detected and suppressed errors, rerun with: -v
==15914== ERROR SUMMARY: 12 errors from 9 contexts (suppressed: 0 from 0)

AND:

valgrind --leak-check=full /sbin/ifdown eth0
==16064== Memcheck, a memory error detector
==16064== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==16064== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==16064== Command: /sbin/ifdown eth0
==16064==
==16064== Invalid read of size 1
==16064==    at 0x405B0B: ??? (in /sbin/ifup)
==16064==    by 0x406A27: ??? (in /sbin/ifup)
==16064==    by 0x402128: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==  Address 0x51de46f is 1 bytes before a block of size 80 alloc'd
==16064==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16064==    by 0x4C2AFCF: realloc (vg_replace_malloc.c:692)
==16064==    by 0x4059F1: ??? (in /sbin/ifup)
==16064==    by 0x406A27: ??? (in /sbin/ifup)
==16064==    by 0x402128: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==
Killed old client process
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/00:1e:ec:d9:d9:72
Sending on   LPF/eth0/00:1e:ec:d9:d9:72
Sending on   Socket/fallback
DHCPRELEASE on eth0 to 192.168.1.1 port 67
==16064==
==16064== HEAP SUMMARY:
==16064==     in use at exit: 746 bytes in 35 blocks
==16064==   total heap usage: 90 allocs, 55 frees, 8,056 bytes allocated
==16064==
==16064== 1 bytes in 1 blocks are definitely lost in loss record 1 of 25
==16064==    at 0x4C2AF2E: realloc (vg_replace_malloc.c:692)
==16064==    by 0x4085CB: ??? (in /sbin/ifup)
==16064==    by 0x405694: ??? (in /sbin/ifup)
==16064==    by 0x4029E9: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==
==16064== 1 bytes in 1 blocks are definitely lost in loss record 2 of 25
==16064==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16064==    by 0x4EB69D9: strdup (strdup.c:42)
==16064==    by 0x40547E: ??? (in /sbin/ifup)
==16064==    by 0x4056F2: ??? (in /sbin/ifup)
==16064==    by 0x4029E9: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==
==16064== 1 bytes in 1 blocks are definitely lost in loss record 3 of 25
==16064==    at 0x4C2AF2E: realloc (vg_replace_malloc.c:692)
==16064==    by 0x4085CB: ??? (in /sbin/ifup)
==16064==    by 0x40570A: ??? (in /sbin/ifup)
==16064==    by 0x4029E9: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==
==16064== 5 bytes in 1 blocks are definitely lost in loss record 6 of 25
==16064==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16064==    by 0x4EB69D9: strdup (strdup.c:42)
==16064==    by 0x403D1B: ??? (in /sbin/ifup)
==16064==    by 0x402900: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==
==16064== 5 bytes in 1 blocks are definitely lost in loss record 7 of 25
==16064==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16064==    by 0x4EB69D9: strdup (strdup.c:42)
==16064==    by 0x403D1B: ??? (in /sbin/ifup)
==16064==    by 0x40488E: ??? (in /sbin/ifup)
==16064==    by 0x4049D8: ??? (in /sbin/ifup)
==16064==    by 0x402918: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==
==16064== 10 bytes in 2 blocks are definitely lost in loss record 9 of 25
==16064==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16064==    by 0x4EB69D9: strdup (strdup.c:42)
==16064==    by 0x40547E: ??? (in /sbin/ifup)
==16064==    by 0x40567C: ??? (in /sbin/ifup)
==16064==    by 0x4029E9: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==
==16064== 17 bytes in 2 blocks are definitely lost in loss record 16 of 25
==16064==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16064==    by 0x4EB6A29: strndup (strndup.c:45)
==16064==    by 0x40545F: ??? (in /sbin/ifup)
==16064==    by 0x4056F2: ??? (in /sbin/ifup)
==16064==    by 0x4029E9: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==
==16064== 21 bytes in 3 blocks are definitely lost in loss record 19 of 25
==16064==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16064==    by 0x4EB6A29: strndup (strndup.c:45)
==16064==    by 0x40545F: ??? (in /sbin/ifup)
==16064==    by 0x40567C: ??? (in /sbin/ifup)
==16064==    by 0x4029E9: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==
==16064== 80 bytes in 1 blocks are definitely lost in loss record 24 of 25
==16064==    at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16064==    by 0x4C2AFCF: realloc (vg_replace_malloc.c:692)
==16064==    by 0x4059F1: ??? (in /sbin/ifup)
==16064==    by 0x406A27: ??? (in /sbin/ifup)
==16064==    by 0x402128: ??? (in /sbin/ifup)
==16064==    by 0x4E56B44: (below main) (libc-start.c:287)
==16064==
==16064== LEAK SUMMARY:
==16064==    definitely lost: 141 bytes in 13 blocks
==16064==    indirectly lost: 0 bytes in 0 blocks
==16064==      possibly lost: 0 bytes in 0 blocks
==16064==    still reachable: 605 bytes in 22 blocks
==16064==         suppressed: 0 bytes in 0 blocks
==16064== Reachable blocks (those to which a pointer was found) are not shown.
==16064== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==16064==
==16064== For counts of detected and suppressed errors, rerun with: -v
==16064== ERROR SUMMARY: 13 errors from 10 contexts (suppressed: 0 from 0)

On 23/10/2015, Rainer Weikusat <rainerweikusat@???> wrote:
> Edward Bartolo <edbarx@???> writes:
>> As the backend uses ifup and ifdown, and these leak memory, I should
>> think, it makes sense to try to understand why they leak, and if
>> possible, patch their code.
>>
>> Should I try to find out what is the cause of memory leaks in
>> ifupdown?
>
> Even assuming that both indeed leaked memory (How did you determine
> this?), this wouldn't matter very much because they're just
> short-running commands: A program is said to 'leak' memory when it loses
> track of some memory it allocated (from the heap) because the last
> pointer pointing to it is overwritten without the memory being returned
> to the heap first. After a process existed, its address space is torn
> down and any real memory allocated by the kernel to cover for some used
> virtual memory will be reclaimed.
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>