Re: [sleuthkit-users] Multiple questions

[Joachim M. <joa...@gm...>]

I've also added a fix for a memory leak in the yaffs code for the error
code path. I'm wondering though if a particular member of the yaffs
internal structure chunkMap is freed in the normal code path?
I've not tested it yet with a yaffs test image, but if you do please run a
tool like valgrind on the tsk tools i.c.w. the yaffs test image.


On Thu, Aug 29, 2013 at 7:23 AM, Joachim Metz <joa...@gm...>wrote:

> > I haven't tracked the final number. Is that set by the libtool/LDFLAGS
> version?
>
> This is controlled by:
> libtsk_la_LDFLAGS = -version-info 10:0:0
>
> in: tsk/Makefile.am
>
> > It looks good.  I'll review it later today and merge it in.
> Thanks, but please revisit the code in this file I did not touch.
>
> Also seeing the compiler warnings I expect there are signed/unsigned
> issues in various more places.
>
> > I see Jeff every day at work.  We're waiting to merge that in, but will
> probably do it by end of week. In hindsight, we should probably have made a
> 64-bit branch instead.
>
> Can you maybe add something to the develop guidelines about what to expect
> and which email address to ping for more urgent patches?
>
> http://wiki.sleuthkit.org/index.php?title=Developer_Guidelines
>
>
>
>
>
> On Thu, Aug 29, 2013 at 5:07 AM, Brian Carrier <ca...@sl...>wrote:
>
>> Hey Joachim,
>>
>> On Aug 28, 2013, at 4:57 PM, Joachim Metz wrote:
>>
>> > So I've just add a pull request to github, can anyone tell me what to
>> expect on the response side?
>>
>> It looks good.  I'll review it later today and merge it in.
>>
>> > I see one other recent pull request of 14 days ago where it seems no
>> one from the project has replied.
>>
>> I see Jeff every day at work.  We're waiting to merge that in, but will
>> probably do it by end of week. In hindsight, we should probably have made a
>> 64-bit branch instead.
>>
>> > Note that this pull request is supposed to fix a serious defect causing
>> the current code to segfault. Also at first glance this file needs some
>> serious revisiting.
>> >
>> >
>> > Also what's up with the current so version number, why did it jump from
>> 3 to 9 to 10 !? Also because the API is largely untouched?
>> >
>> > sleuthkit 3.x.x was soname libtsk3.3
>> > sleuthkit 4.0.0 was soname libtsk3.3
>> > sleuthkit 4.0.1 was soname libtsk3.9
>> > sleuthkit 4.0.2 was soname libtsk3.9
>> > sleuthkit 4.1.0 was soname libtsk.10
>>
>> I haven't tracked the final number. Is that set by the libtool/LDFLAGS
>> version?
>>
>> > Also can someone elaborate on the sudden change of hart to rename
>> libtsk3 into libtsk?
>>
>> Because TSK has been version 4 for almost a year and the '3' was for
>> version 3. I dropped the version from the library name (and include paths).
>>
>> brian
>>
>>
>>
>