2016-12-02 0:04 GMT+01:00 Christoph Biedl :
> Arnaud Quette wrote...
>
>> $ gcc test.c -lmagic
>> valgrind ./a.out
> (...)
>> ==30967== HEAP SUMMARY:
>> ==30967== in use at exit: 48 bytes in 3 blocks
>> ==30967== total heap usage: 28 allocs, 25 frees, 2,179 bytes allocated
> (...)
>
> Hello,
>
> ac
Arnaud Quette wrote...
> $ gcc test.c -lmagic
> valgrind ./a.out
(...)
> ==30967== HEAP SUMMARY:
> ==30967== in use at exit: 48 bytes in 3 blocks
> ==30967== total heap usage: 28 allocs, 25 frees, 2,179 bytes allocated
(...)
Hello,
according to my tests this was fixed in file/libmagic 5.29-1 (as
Arnaud Quette wrote...
> looking closer at the patch I pointed, it's very probably not suitable.
Now I see a patch. I'll take a close look tomorrow
> IMHO, it's Debian related, though I've not tested on Redhat nor others.
As far as I understand it the leak is caused by the fact Debian uses
a di
Hi Christoph,
2016-10-17 20:21 GMT+02:00 Christoph Biedl :
> tags 840754 confirmed moreinfo
> thanks
>
> Arnaud Quette wrote...
>
>> ==30967== definitely lost: 48 bytes in 1 blocks
>
> Confirmed, can reproduce this from jessie on, not in wheezy though.
>
>> - Redhat has a similar ticket which they
tags 840754 confirmed moreinfo
thanks
Arnaud Quette wrote...
> ==30967== definitely lost: 48 bytes in 1 blocks
Confirmed, can reproduce this from jessie on, not in wheezy though.
> - Redhat has a similar ticket which they solved:
> https://bugzilla.redhat.com/show_bug.cgi?id=919466
Unfortunate
Package: libmagic1
Version: 1:5.22+15-2+deb8u2
Severity: normal
libmagic suffers from a memory leak, apparently due to magic_load()
not satisfying its contract:0
As per man magic_load:
--
The magic_load() function must be used to load the the colon separated
list of database files passed in as fi
6 matches
Mail list logo
