Bug#840754: Memory leak in libmagic and failure in magic_load

2016-12-05 Thread Arnaud Quette
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

Bug#840754: Memory leak in libmagic and failure in magic_load

2016-12-01 Thread 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, according to my tests this was fixed in file/libmagic 5.29-1

Bug#840754: Memory leak in libmagic and failure in magic_load

2016-10-28 Thread Christoph Biedl
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

Bug#840754: Memory leak in libmagic and failure in magic_load

2016-10-21 Thread Arnaud Quette
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. > >> -

Bug#840754: Memory leak in libmagic and failure in magic_load

2016-10-17 Thread 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 solved: > https://bugzilla.redhat.com/show_bug.cgi?id=919466

Bug#840754: Memory leak in libmagic and failure in magic_load

2016-10-14 Thread Arnaud Quette
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