[Ltrace-devel] Some patches for ltrace

[Petr Machata]

Andrey Zonov <zont at FreeBSD.org> writes:
> On 8/27/12 5:35 PM, Petr Machata wrote:
>> Andrey Zonov <zont at FreeBSD.org> writes:
>> 
>>> On 8/27/12 1:30 PM, Petr Machata wrote:
>>>> Andrey Zonov <zont at FreeBSD.org> writes:
>>>>
>>>>> I'm now porting ltrace on FreeBSD
>> 
>> One more nit.  I don't like that the directory is called FreeBSD.  Why
>> not call it "freebsd"?  That's what the triplet name is.
>> 
>
> The project name is FreeBSD, not freebsd, but I will rename directory if
> you have objections.

Yes please.  The gnu-linux back end is likewise for projects called GNU
and Linux.

>> Sending patches to mailing list is important for review anyway.
>
> Attached.

Thank you, that's fine.

The way this is usually done is that the contributor sends each patch in
a separate mail.  I believe git am can do this for you, though I have
always simply massaged the files produced by git am through gnus.  One
example of this can be seen here:

  http://lists.alioth.debian.org/pipermail/ltrace-devel/2010-November/000395.html

>> In any case, I hope you will want to merge your FreeBSD work to
>> official ltrace repository eventually, and it is desirable that it
>> fits the style of the rest of the repo.
>
> It would be great to add FreeBSD support in official tree, but I think
> it should be done after fixing thread support.

OK.  ltrace actually didn't work well with threads until sometime last
year, so there is precedent of this being broken.  But I understand that
you want to get it right.

There is another problem with granting you commit rights, as an owner of
the FreeBSD back end.  Juan Cespedes has been unresponsive for more than
a year now, and nobody else can do the project management.  I keep
pinging him, asking him to include me in the admins group, but he never
replies.

>>>>> a2d199eda1f0e6dd5e3dc38fdef9383dca602993
>>>
>>> This is a using memory after free(3).
>>> $ valgrind ./ltrace -f ./run 1 /bin/sleep 1
>> 
>> OK.  I'll look into this and see if I can come up with a reasonable
>> solution.
>> 
>
> I have an idea to use reference counters instead of doing deep copy, but
> I had no time to implement this.

Yes, this has been in my abstract plan for some time now, as a resource
conservation strategy.  All the processes will likely open the same set
of libraries, and having a separate copy for each is unnecessary.

Thank you,
PM