Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Jul 2008 08:21:42 -0700
From:      Tim Kientzle <kientzle@freebsd.org>
To:        Anselm Strauss <strauss@freebsd.org>
Cc:        Perforce Change Reviews <perforce@freebsd.org>
Subject:   Re: PERFORCE change 145885 for review
Message-ID:  <4889EF86.4080601@freebsd.org>
In-Reply-To: <4889E8F1.5000006@freebsd.org>
References:  <200807251333.m6PDX06I079276@repoman.freebsd.org> <4889E8F1.5000006@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Tim Kientzle wrote:
> Anselm Strauss wrote:
> 
>> http://perforce.freebsd.org/chv.cgi?CH=145885
>>
>> Change 145885 by strauss@strauss_marvelman on 2008/07/25 13:32:02
>>
>>     Cloning archive entry instead of referencing it for data 
>> descriptors (Tim)
>>
>> Affected files ...
>>
>> .. 
>> //depot/projects/soc2008/strauss_libarchive/libarchive/archive_write_set_format_zip.c#18 
>> edit
>> .. 
>> //depot/projects/soc2008/strauss_libarchive/libarchive/test/test_write_format_zip_no_compression.c#3 
>> edit
>>
>> Differences ...
>>
>> ==== 
>> //depot/projects/soc2008/strauss_libarchive/libarchive/archive_write_set_format_zip.c#18 
>> (text+ko) ====
>>
>> @@ -173,7 +173,7 @@
>>          archive_set_error(&a->archive, ENOMEM, "Can't allocate zip 
>> header data");
>>          return (ARCHIVE_FATAL);
>>      }
>> -    l->entry = entry; /* TODO: Maybe bad idea, do copy or store only 
>> needed fields. */
>> +    l->entry = archive_entry_clone(entry);
>>      l->next = zip->central_directory;
>>      zip->central_directory = l;
> 
> 
> Of course, this also means that the Zip writer now owns
> a copy of the entry and it has to free it with
> archive_entry_free() when it's done with it.
> 
> You should change your zip write test to use
> archive_entry_free() to release the entry before
> you call archive_write_close().
> 
> I'm going to run libarchive_test under a memory
> debugger to see if your zip work is leaking any
> memory.  I'll let you know what I see.
> 
> 

It looks like 'libarchive_test 60' doesn't leak any memory (that's the 
zip_empty test), but 'libarchive_test 61' does leak.  The report from 
dmalloc is below.  The block of 4096 bytes here is from stdio so you 
should ignore that.  The rest is being leaked by either the test code or 
the zip writer.  I suspect most of this is the archive_entry being 
leaked in the test and a clone of it being leaked in the zip writer.  If 
you could fix that, I'll run this test again tomorrow and let you know 
what I find.

1216998946: 20: Dmalloc version '5.4.2' from 'http://dmalloc.com/'
1216998946: 20: flags = 0x4f48d03, logfile '/tmp/dmalloc.log'
1216998946: 20: interval = 0, addr = 0, seen # = 0, limit = 0
1216998946: 20: starting time = 1216998946
1216998946: 20: process pid = 42777
1216998946: 20: Dumping Chunk Statistics:
1216998946: 20: basic-block 4096 bytes, alignment 8 bytes
1216998946: 20: heap address range: 0x28231000 to 0x28245000, 81920 bytes
1216998946: 20:     user blocks: 8 blocks, 28320 bytes (34%)
1216998946: 20:    admin blocks: 12 blocks, 49152 bytes (60%)
1216998946: 20:    total blocks: 20 blocks, 81920 bytes
1216998946: 20: heap checked 21
1216998946: 20: alloc calls: malloc 12, calloc 0, realloc 0, free 8
1216998946: 20: alloc calls: recalloc 0, memalign 0, valloc 0
1216998946: 20: alloc calls: new 0, delete 0
1216998946: 20:   current memory in use: 4928 bytes (6 pnts)
1216998946: 20:  total memory allocated: 6165 bytes (12 pnts)
1216998946: 20:  max in use at one time: 6165 bytes (12 pnts)
1216998946: 20: max alloced with 1 call: 4096 bytes
1216998946: 20: max unused memory space: 5627 bytes (47%)
1216998946: 20: top 10 allocations:
1216998946: 20:  total-size  count in-use-size  count  source
1216998946: 20:        4096      1        4096      1  ra=0x2820c932
1216998946: 20:        1024      1           0      0  ra=0x8059916
1216998946: 20:         376      1         376      1  ra=0x804a97d
1216998946: 20:         376      1         376      1  ra=0x804c15a
1216998946: 20:         160      1           0      0  ra=0x80598ba
1216998946: 20:          64      2          64      2  ra=0x8058ec7
1216998946: 20:          20      1           0      0  ra=0x8062db4
1216998946: 20:          16      1           0      0  ra=0x805d9bb
1216998946: 20:          16      1          16      1  ra=0x8062e98
1216998946: 20:        6165     12        4928      6  Total of 11
1216998946: 20: Dumping Not-Freed Pointers Changed Since Start:
1216998946: 20:  not freed: '0x28231008|s1' (4096 bytes) from 
'ra=0x2820c932'
1216998946: 20:  not freed: '0x2823bf88|s1' (16 bytes) from 'ra=0x8062e98'
1216998946: 20:  not freed: '0x28242c08|s1' (376 bytes) from 'ra=0x804c15a'
1216998946: 20:  not freed: '0x28242e08|s1' (376 bytes) from 'ra=0x804a97d'
1216998946: 20:  not freed: '0x28243f88|s1' (32 bytes) from 'ra=0x8058ec7'
1216998946: 20:  not freed: '0x28243fc8|s1' (32 bytes) from 'ra=0x8058ec7'
1216998946: 20:  total-size  count  source
1216998946: 20:        4096      1  ra=0x2820c932
1216998946: 20:         376      1  ra=0x804a97d
1216998946: 20:         376      1  ra=0x804c15a
1216998946: 20:          64      2  ra=0x8058ec7
1216998946: 20:          16      1  ra=0x8062e98
1216998946: 20:        4928      6  Total of 5
1216998946: 20: ending time = 1216998946, elapsed since start = 0:00:00







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4889EF86.4080601>